On 10/9/21 6:54 PM, Bill Cole wrote:
On 2021-10-09 at 11:39:48 UTC-0400 (Sat, 9 Oct 2021 17:39:48 +0200)
Thomas Seilund <t...@netmaster.dk>
is rumored to have said:
Dear All
I see incomming mail that I would imagine that SA should classify as
spam but mail only gets a score of 2
When I run the same mail through spamc from the command line the
score is 11.8.
Why is the score not 11.8 when the mail is handled by Postfix/SA?
Pls. see details below.
Based on those details, I'd say it was a matter of time.
The fact that you're running the message through spamc/spamd in both
cases with spamd running with the options "--nouser-config" and
"--username=vmail" eliminates all the more arcane sources of such
discrepancies.
Mail server is Debian Buster running Postfix and SA 3.4.2.
You should upgrade SA. The current release is 3.4.6 and it includes
significant performance, functionality, and security improvements. You
aren't in severe danger (the security issues have no reported exploits
in the wild) but upgrading would be prudent.
SA is called through a content filter in Postfix file master.cf
I have debug on spamd set up in /etc/default/spamassassin by the line
'OPTIONS="--debug --max-children=5 --username=vmail --nouser-config"'
After adding --debug and restarting SA with `sudo systemctl restart
spamassassin` I see a lot of debug info in /var/log/mail.log
I have run the mail through `spamc` using this command. Command and
output shown below:
sudo cat
/srv/vmail/netmaster.dk/tps/mail/cur/1633788457.M618066P6142.linode2.netmaster.dk,S=5989,W=6185:2,Sc
| spamc -R
11.8/5.0
Spam detection software, running on the system "linode2.netmaster.dk",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: The coolest and comfiest sandals to wear around the
house,
or even at the office Everyone is talking about these colorful
rubber shoes,
designed to ensure maximum comfort and stability. They are non- [...]
Content analysis details: (11.8 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
2.5 URIBL_DBL_SPAM Contains a spam URL listed in the
Spamhaus DBL
blocklist
[URIs: nerveoil.bar]
1.9 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
blocklist
[URIs: nerveoil.bar]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus
SBL-CSS
[2.56.57.119 listed in zen.spamhaus.org]
1.7 URIBL_BLACK Contains an URL listed in the URIBL
blacklist
[URIs: nerveoil.bar]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.0 HTML_MESSAGE BODY: HTML included in message
0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML
tag
1.3 RDNS_NONE Delivered to internal network by a host
with no rDNS
0.1 PLING_QUERY Subject has exclamation mark and question
mark
The mail gets a score of 11.8 points.
But when the mail was first received by Postfix is was only given a
score of 2.
9.7 points of that score are due to various DNSBLs, which by their
nature tend to miss the first few instances of new spam runs.
Why is the score different when Postfix sends mail to SA and when I
do it manually from the command line?
22 minutes of opportunity for the shared spam-control resources of the
world to engage.
I have lines in /var/log/mail.log that shows the two cases. Command
and output below:
[...]
Oct 9 16:07:37 linode2 spamd[1009]: spamd: result: . 2 -
HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,PLING_QUERY,RDNS_NONE,SPF_HELO_PASS
[...]
Oct 9 16:29:20 linode2 spamd[1008]: spamd: result: Y 11 -
HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,PLING_QUERY,RCVD_IN_SBL_CSS,RDNS_NONE,SPF_HELO_PASS,URIBL_ABUSE_SURBL,URIBL_BLACK,URIBL_DBL_SPAM
When run via Postfix on arrival, the source IP was not in the Spamhaus
SBL's CSS sublist, and none of the URLs in the body were listed in the
cited URIBL lists. 22 minutes later, the sources used by those DNSBLs
caught up with that particular spam run, so the second test hit a
bunch of them. I see this all the time. The first of many targets sent
a particular spam are unprotected because the spam is new but as new
instances of the same message come in for other targets they start
showing up in shared reputation systems, hitting various RCVD_IN_* and
URIBL_* rules in SA.
There's intrinsically no good fix for this. Some systems deploy a
tactic called "greylisting" where the first message from an unknown
source is deferred a few minutes (i.e. initially rejected with a "try
again later" response code.) which mostly eliminates the issue, but it
also creates some problems naturally (legitimate mail gets delayed,
which is by design) and others that are due to unpredictable retry
behaviors by legitimate sending systems that result in mail never
being delivered.
Another partial solution with Postfix is to enable its postscreen
component with the greeting delay feature enabled, which bears a
slight resemblance to greylisting, but is safer because it only ever
rejects or defers senders who violate the SMTP protocol. This at least
assures that you will get a few seconds of delay, which can be enough
for the DNSBLs to catch up with the latest spammer.
Hi Bill
Thanks a lot.
I will look into upgrading and the suggestions you put forward.
Regards
Thomas S
