HDD temperature reached in LaCie Cloudbox, safe temp?

[Jocko]

:hammerhead
more and more amazing...

Just to confirm this point, try this new version (same command to install it).

If it still doesn't work, edit again the file /usr/bin/mail: replace the line 70

Code: Select all

echo "EHLO $ippub"

by

Code: Select all

echo "EHLO yourDDNS"

where yourDDNS is your dynamic domain name

[Cubytus]

I changed the line 70 in /usr/bin/mail, applied the patch, and now it seems to connect correctly. I didn't knew there was a link between the DDNS address and the mailing system. But it's true that most email providers automatically reject emails when they don't come from a valid hostname, i.e. most home subscriptions, which is why I am always doubtful about hosting a mail server at home.

This is also different from the ISP blocking port 25. I still don't know how the NAS connection to the SMTP is different from a connection originating from the computer. It is also interesting to note that the NAS mailer didn't send an alert about the self-signed certificate sent by the SMTP server.

On the other hand, the reported success may be a false positive, in the sense that I also use that same originating IP address when sending and receiving regular emails. It may not have worked properly if the NAS were on a different connection.

Since there is no single setting that would work on first try, maybe an option should be added in the notification center so as to specify which hostname to send to the SMTP server? Or use the internal SMTP server, if there's any, when the ISP doesn't block port 25?

[Jocko]

Hi Cubytus,

I am sorry but it is not clear for me.

I changed the line 70 in /usr/bin/mail, applied the patch

Did you try first my last version (v2) of mail script without editing nothing ? If no, please to try it because EHLO command must accept either a public IP or a valid dns and it would be amazing that your ISP accepts only a dns.

I didn't knew there was a link between the DDNS address and the mailing system. But it's true that most email providers automatically reject emails when they don't come from a valid hostname, i.e. most home subscriptions, which is why I am always doubtful about hosting a mail server at home.

This is also different from the ISP blocking port 25. I still don't know how the NAS connection to the SMTP is different from a connection originating from the computer. It is also interesting to note that the NAS mailer didn't send an alert about the self-signed certificate sent by the SMTP server.

So it seems that you uses smtp protocol over port 25 which it is well known as an handy way to send spam because it allows to email without authentication . This may explain why your ISP has drastic rules. Usually ISP blocks now this port. Can you search if your ISP provides another settings (port 465, ...)


Note: what is your isp ?

[Cubytus]

I tried to reverse the modification as you suggested: the email is sent when I use the DDNS name, but blocked when I use $ippub. All connections are made over TLS port and protocol, so 587. Maybe the difference comes from this setting?

I sent a support request to my ISP to know the current politic about ports, all pages I can find are a few years old, but they famously bragged about not blocking any port. What is strange however, is I understand the fvdw firmware connects to an external SMTP server, and thus won't be subject to port 25 blocking.

[Jocko]

Ok. So your ISP has drastic rules... Currently, you are the first member with this issue (it is why I asked what is your ISP? teksavvy ?)

Just for testing, if you put a fake FQDN instead of your ddns (eg. me.example.com), can you receive the test email?

All connections are made over TLS port and protocol, so 587. Maybe the difference comes from this setting?

No, I use this kind of settings without issue: EHLO can use either keyword localhost, or my public IP or my DDNS.

What is strange however, is I understand the fvdw firmware connects to an external SMTP server, and thus won't be subject to port 25 blocking.

You misunderstand on this point. As any email client, fvdw-sl tries to connect directly to your smtp server with the options set in the notification menu.

[Jocko]

Anyhow I changed in the next version how the mail script handles the helo command...
In the version 16.1, you will be able to set a dynamic domain name in Notification menu.

[Cubytus]

Update: since some of my ISP's customer don't properly protect their machines, the ISP had to block ports 25 and 53 since last November.

What is still surprising, though, is that fvdw firmware acts as an email client, and thus shouldn't be subject to any port block. I can send emails without a problem from my computer, why not the NAS? Can it detect that I am using a dynamic IP range and refuse the connection on that basis? Because the issue is not from the SMTP: computers can send emails to the SMTP.

Strangely it also works using a fictive FQDN.

From RFC2821 4.1.1.1, I read the following:

In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system

And in the 4.1.3 section:

4.1.3 Address Literals

Sometimes a host is not known to the domain name system and
communication (and, in particular, communication to report and repair
the error) is blocked. To bypass this barrier a special literal form
of the address is allowed as an alternative to a domain name. For
IPv4 addresses, this form uses four small decimal integers separated
by dots and enclosed by brackets such as [123.255.37.2]

The question would be, is icanhazip.com raw IP address returned properly enclosed in brackets? As I understand it, it will be refused if no brackets are provided. So I used my external IP put in brackets, and it works! The problem is that the $ippub variable is not properly enclosed as the standards require. On receiving the email, though, the email is marked as spam with a very high score of 8.3, according to SpamAssassin. So although it works when the variable is corrected, the correct way to do it on common home connections would be to use a DDNS name.

[Jocko]

The question would be, is icanhazip.com raw IP address returned properly enclosed in brackets? As I understand it, it will be refused if no brackets are provided.

No, $ippub contains only the IP value.

To valid your suggestion, restore the line 70 with this code

Code: Select all

echo "EHLO [$ippub]"

Note with my provider no bracket is required

[Cubytus]

To valid your suggestion, restore the line 70 with this code

Code: Select all

echo "EHLO [$ippub]"

Note with my provider no bracket is required

That may mean you ISP's SMTP server is not set up to standards, or that it accepts any email coming from one of their subscribers. I have used a completely independent SMTP from my website host.

I modified with [$ippub], and it technically works, but the spam score is even worse at 11.5. Note that it may be due to the repeated trials I have made. I would still advise against such a risky script modification. Most email providers silently discard emails with high spam scores.

Email header that may be helpful in understanding the spam score:

Code: Select all

X-Spam-Report:    Spam detection software, running on the system "XXX", has identified this incoming email as possible spam.  The original message has been attached to this so you can view it (if it isn't spam) or label similar future email.  If you have any questions, see the administrator of that system for details. Content preview:  Mailer settings are DDNS !. [...]  Content analysis details:   (11.5 points, 5.5 required) pts rule name              description ---- ---------------------- -------------------------------------------------- 0.7 DNS_FROM_AHBL_RHSBL    RBL: Envelope sender listed in dnsbl.ahbl.org 0.0 MISSING_MID            Missing Message-Id: header 4.3 HELO_DYNAMIC_HCC       Relay HELO'd using suspicious hostname (HCC) 4.4 HELO_DYNAMIC_IPADDR2   Relay HELO'd using suspicious hostname (IP addr 2) 0.0 FH_HELO_EQ_D_D_D_D     Helo is d-d-d-d 1.2 INVALID_DATE           Invalid Date: header (not RFC 2822) 1.9 TVD_RCVD_IP            TVD_RCVD_IP 2.0 BAYES_80               BODY: Bayesian spam probability is 80 to 95% [score: 0.8237] 0.1 RDNS_DYNAMIC           Delivered to trusted network by host with dynamic-looking rDNS -3.2 AWL                    AWL: From: address is in the auto white-list

[Jocko]

That may mean you ISP's SMTP server is not set up to standards, or that it accepts any email coming from one of their subscribers.

Maybe you are right.

So for version 16.1, I go to add brackets with the EHLO command.

However, with some Internet searches, I read that some smtp server check the FQDN with the sender's IP. If FQDN doesn't match the IP, the server doesn't send the email. (note it is the case with your provider as it accepts a fake FQDN).
For these smtp server, give the DDNS stays useful (So my last change is not useless)

the spam score is even worse at 11.5. Note that it may be due to the repeated trials I have made. I would still advise against such a risky script modification. Most email providers silently discard emails with high spam scores.

Maybe so wait a time before sending again an email.