HDD temperature reached in LaCie Cloudbox, safe temp?

[Jocko]

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

At least, you can decrease the spam score for the invalid date (1.9). indeed, there is an old error in the line

Code: Select all

echo Date:`/bin/date +'%a, %d %b %y %T %z GMT'`

(I forgot to remove GMT string) So replace it by

Code: Select all

echo Date:`/bin/date -R`

[Cubytus]

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).

Is it a standard to counter-check FQDN with IP? Because using a DDNS would mean that the FQDN always matches the IP.

Other parts of the email are pointed out. I modified the date generation, and there's no alert anymore about that part.

See:

Header:

Code: Select all

Content analysis details:   (9.3 points, 5.5 required)
pts rule name              description ---- ---------------------- -------------------------------------------------- 0.7
DNS_FROM_AHBL_RHSBL    RBL: Envelope sender listed in dnsbl.ahbl.org 3.5
BAYES_99               BODY: Bayesian spam probability is 99 to 100% [score: 0.9983] 0.0
MISSING_MID            Missing Message-Id: header 1.9
TVD_RCVD_IP            TVD_RCVD_IP 0.1
RDNS_DYNAMIC           Delivered to trusted network by host with dynamic-looking rDNS 3.1
AWL                    AWL: From: address is in the auto white-list

Code: Select all

DNS_FROM_AHBL_RHSBL    RBL: Envelope sender listed in dnsbl.ahbl.org 3.5

This seems to be the rising part of the score because of repeated trials. I'll ignore it for this test, but it should be tackled because a very busy, multi-disk NAS may send many different alerts in a short timeframe. Maybe not send an individual alert, but "pool" them in the same email? For example if three or an arbitrary number of alerts are in the pool, or if the alerts have waited for more than x number hours, then generate an email and send it? That would reduce the likelihood of being marked as a flooder/spammer.

Code: Select all

MISSING_MID            Missing Message-Id: header 1.9

With DDNS hostname;

Code: Select all

MISSING_MID            Missing Message-Id: header 4.3

With public hostname or direct, enclosed IP.
This would be an easy one for developers to solve ;) It seems to rise and fall pretty fast, but its influence is far from negligible. Some common business / institutional email servers are set to discard emails at just 3, and I could understand a user who may want to receive really urgent alerts where he works.

Code: Select all

RDNS_DYNAMIC           Delivered to trusted network by host with dynamic-looking rDNS 3.1

I guess we can't do much about this one, and it also varies widely from one alert to another. This was done using the DDNS hostname.

Not using the DDNS hostname but the public hostname:

Code: Select all

HELO_DYNAMIC_HCC       Relay HELO'd using suspicious hostname (HCC) 4.4

So very special care should be used when generating the Message-ID and retrieving the hostname. Both of these variables seem to have the most influence on SpamAssassin's behaviour. Other tests with different setups would be required to know which EHLO gives consistently good scores.

[Jocko]

Thank Cubytus for your additional tests.

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).

Sorry, I made a typo error, you should read: note it is not the case with your provider as it accepts a fake FQDN.

Is it a standard to counter-check FQDN with IP? Because using a DDNS would mean that the FQDN always matches the IP.

No if the sender uses another host to send the message (so maybe a spammer), FQDN won't match the IP

This seems to be the rising part of the score because of repeated trials. I'll ignore it for this test, but it should be tackled because a very busy, multi-disk NAS may send many different alerts in a short timeframe. Maybe not send an individual alert, but "pool" them in the same email? For example if three or an arbitrary number of alerts are in the pool, or if the alerts have waited for more than x number hours, then generate an email and send it? That would reduce the likelihood of being marked as a flooder/spammer.

I don't believe it. Read the related help of Notification menu. The events handled by the feature can not send many alerts in a short period.

Code: Select all

MISSING_MID            Missing Message-Id: header 1.9

With DDNS hostname;

Code: Select all

MISSING_MID            Missing Message-Id: header 4.3

With public hostname or direct, enclosed IP.
This would be an easy one for developers to solve ;) It seems to rise and fall pretty fast, but its influence is far from negligible. Some common business / institutional email servers are set to discard emails at just 3, and I could understand a user who may want to receive really urgent alerts where he works.

So at least use the ddns is better. What I don't understand, is why you don't have this header. On my side, I can find it in any sent email by the nas:

Code: Select all

Message-ID: <96090d7f2b6db3b08889e03aa83a7217@xxxxxxxxxxx.xxxxxxxxxxxxxxx.net>
Date: Tue, 12 May 15 23:53:42 +0200
To: <xxxxxxxxxxxxxxx>
From: <xxxxxxxxxxxxxx>
Subject: NAS(Acrab), test22 send

[Cubytus]

Some events can be quite frequent: NAS standby, wake up, over temperature (this will be solved in the next version as I understood), especially in summer or running the HDD with its cover

The help file is still titled "RSync server" by the way.

No if the sender uses another host to send the message (so maybe a spammer), FQDN won't match the IP

Is that process part of the standard? Does the public hostname count as a FQDN?

So at least use the ddns is better. What I don't understand, is why you don't have this header. On my side, I can find it in any sent email by the nas:

Code: Select all

Message-ID: <96090d7f2b6db3b08889e03aa83a7217@xxxxxxxxxxx.xxxxxxxxxxxxxxx.net>
Date: Tue, 12 May 15 23:53:42 +0200
To: <xxxxxxxxxxxxxxx>
From: <xxxxxxxxxxxxxx>
Subject: NAS(Acrab), test22 send

Oops. Big mistake I made. While looking at the same email using Thunderbird, I mistakenly misaligned the scores.

Code: Select all

pts rule name              description
   ---- ---------------------- --------------------------------------------------
   0.7 DNS_FROM_AHBL_RHSBL    RBL: Envelope sender listed in dnsbl.ahbl.org
   3.5 BAYES_99               BODY: Bayesian spam probability is 99 to 100%
   [score: 0.9983]
   0.0 MISSING_MID            Missing Message-Id: header
   1.9 TVD_RCVD_IP            TVD_RCVD_IP
   0.1 RDNS_DYNAMIC           Delivered to trusted network by host with
   dynamic-looking rDNS
   3.1 AWL                    AWL: From: address is in the auto white-list

I don't know why the missing MID is even recorded at 0.0. I don't have a message-ID on alerts, though I get a proper ID when receiving emails to the same address from other sources. Is the Message-ID set by the originating client?
The Bayesian filter gives a weight of 3.5 for "probability". Wild guess: would it work better if the message was more specific to the matter on hand? Very short messages with no context could be considered as spam. Spammers often try to pass as people we know, writing messages with less formality. The filter points the body of the message as the trigger.
Other reference: https://wiki.apache.org/spamassassin/Rules/BAYES_99
It also seems triggered by previous messages being marked as spam, coming from the same DNSBL. What I don't get is my IP appears unlisted in any blacklist. My SMTP provider is also whitelisted.
For the TVD_RCVD_IP: can't be eliminated altogether. See: https://wiki.apache.org/spamassassin/Rules/TVD_RCVD_IP
AWL: I don't know why such a high weight is given to an auto-whitelisted address. See https://wiki.apache.org/spamassassin/AutoWhitelist

[Jocko]

Some events can be quite frequent: NAS standby, wake up, over temperature (this will be solved in the next version as I understood), especially in summer or running the HDD with its cover

Sorry but I don't think that the frequency used by the smtp server is large and so I still believe it is not an issue. Please to note that the disk temperature events already work.

The help file is still titled "RSync server" by the way.

Thank and it is already fixed in the next version.

Is that process part of the standard? Does the public hostname count as a FQDN?

No, only some ISP check it in this way and yes a public hostname is a FQDN: xxx(---x).yyy(---y).zzz

Oops. Big mistake I made. While looking at the same email using Thunderbird, I mistakenly misaligned the scores.... Is the Message-ID set by the originating client?

Yes the Message-ID is set on the client side. I checked my ISP: it is added only if it is missing by my provider.
Even if it does not increase your spam score, the mail script set now a message-id. So replace the lines

Code: Select all

   echo DATA
   sleep 1
   echo Date:`/bin/date -R`

by

Code: Select all

   echo DATA
   sleep 1
   key=`date +%s`.$to.$subject
   echo Message-ID:\<`echo $key|busybox sha256sum|head -c 32`@mail.fvdw-sl.net\>
   echo Date:`/bin/date -R`

(---be careful--- I edited the new command lines as sha256sum is not directly available on your nas)

For the TVD_RCVD_IP: can't be eliminated altogether. See: https://wiki.apache.org/spamassassin/Rules/TVD_RCVD_IP

This is an header handled by the smtp server. So we can do nothing except with the EHLO command as we already did.

The Bayesian filter gives a weight of 3.5 for "probability". Wild guess: would it work better if the message was more specific to the matter on hand? Very short messages with no context could be considered as spam. Spammers often try to pass as people we know, writing messages with less formality. The filter points the body of the message as the trigger.

You can try to enlarge the message body in the shell command as specified in the help.

[Cubytus]

No, only some ISP check it in this way and yes a public hostname is a FQDN: xxx(---x).yyy(---y).zzz

What would be best to use in order to avoid triggering spam rules, then? Public hostname, or DDNS name?

Yes the Message-ID is set on the client side. I checked my ISP: it is added only if it is missing by my provider.
Even if it does not increase your spam score, the mail script set now a message-id. So replace the lines

Code: Select all

   echo DATA
   sleep 1
   echo Date:`/bin/date -R`

by

Code: Select all

   echo DATA
   sleep 1
   key=`date +%s`.$to.$subject
   echo Message-ID:\<`echo $key|busybox sha256sum|head -c 32`@mail.fvdw-sl.net\>
   echo Date:`/bin/date -R`

(---be careful--- I edited the new command lines as sha256sum is not directly available on your nas)

Is sha256sum part of BusyBox? Sorry I never quite understood exactly what role was filled by BusyBox.

I edited the /usr/bin/mail file. Now it gets an explicit message ID. I now get two different IDs: one at sending time

Code: Select all

id 1Yt9Iw-0004LZ-EK

Another generated by the script

Code: Select all

Message-ID:<7f3bcbdd86bbaec1a68be0a1c84e0ad8@mail.fvdw-sl.net>

As for the spam marking, though, maybe the previous, automatic rules set by SpamAssassin have been cleared since they don't come on even when reverting the changes. Replacing the DDNS in the EHLO by [$ippub], it still doesn't trigger spam marking. :hammerhead

It seems your ISP is rather permissive on emails sent from non-perfect clients. It probably relies more on originating IP (within its own network), assuming what comes from inside mustn't be spam. I should test that with my ISP's own SMTP server.

You can try to enlarge the message body in the shell command as specified in the help.

I did so as well, but unsure of its real influence since I couldn't trigger the spam marking in 5 or 6 trials. It's clear here that we are dealing with multiple variables, and that the only reliable one is the RFC standard.

[Jocko]

Hi Cubytus,

For your information, I also made a test with another smtp server with spamAssasin and I got a very low spam score: -1.9 (-2 is a fully clean email)!

What would be best to use in order to avoid triggering spam rules, then? Public hostname, or DDNS name?

You have already answered yourself!

Replacing the DDNS in the EHLO by [$ippub], it still doesn't trigger spam marking.

So for your smtp server, use public IP is the best as if you use your DDNS you get an high spam score.

I edited the /usr/bin/mail file. Now it gets an explicit message ID. I now get two different IDs: one at sending time

id is not message-id! Please to note that your id don't have the specific format

Message-ID is a unique identifier for a digital message, most commonly a globally unique identifier used in email and Usenet newsgroups.
Message-IDs are required to have a specific format which is a subset of an email address (though Microsoft Outlook is known to generate invalid IDs with three parts) and to be globally unique. That is, no two different messages must ever have the same Message-ID. A common technique used by many message systems is to use a time and date stamp along with the local host's domain name, e.g., 950124.162336@example.com.

Is sha256sum part of BusyBox? Sorry I never quite understood exactly what role was filled by BusyBox.

BusyBox provides tiny versions of many common UNIX utilities into a single small executable.

[Cubytus]

Hi there,

sorry to pull an old topic, but the overheating still isn't solved.

The Cloudbox is currently running without its white cover, and has been for a month now. However, during higher usage such as downloading with Transmission, it takes just an hour to reach over 55 degrees with an ambient temperature of 33 degrees. I set it up to spin down when this temperature is reached so as to avoid stressing the disk.

Will the 16.1 version of fvdw include a way to tweak this trigger temperature, or a mode that would suspend all disk activity but without shutting down the CPU so as to allow for automatic restart after a pre-set time, and not wait for a WoL magic packet?

[fvdw]

I will make for you a program that will shut it down and wait for a certain time and then reboot, will be back later

[fvdw]

Hi Cybutus

I have a program that you can test.
It is a new wol-fvdw-sl binary.
You have to replace the existing one in /usr/sbin by this one

The new daemon has besides the wake up capability after receiving magic packet an option that it wakes up the nas automatically after a certain time period is expired (suspend time).

The idea is to let the tempguard daemon activate the WOL standby mode and set the suspend time.

To let the temp-guard daemon use it you need to modify the temp-alert.sh file to something like this

Code: Select all

#!/bin/sh
/usr/bin/php /etc/api/nasapi.php mrvlNotify 5 55 0 0 0
touch /etc/wolenable
echo yy  > /etc/time-suspend.txt
/bin/sync
/sbin/rebootd-spd

Replace yy behind echo with a number, it will be the suspend time in minutes after the nas will wake up automatically from WOL mode. You can wake it up earlier by sending a magic packet or pressing the power button.

You need to modify the temp-alert.sh file after you have started the temp-guard daemon as otherwise it will be overwritten by the web gui when you activate the temp-guard.

If you edit it be sure that you use an editor that can make unix like files so only use <LF> (line feed) ot the end of a line. If you use editors like standard notepad it will use <CR><LF> at the end of a line and this will cause the command script to fail when running.

In the next firmware upgrade (16.1) this feature will be integrated in the web interface