Pat Traynor wrote:
> I've pastbin'd the first part of one of the spams here:
> http://pastebin.com/Feete78K
The IP address of the message appears to me to be 185.45.193.123 out
of Dubai. It is not listed in most of the DNSBLs that I checked. It
is listed in dnsbl.sorbs.net however. That would be how it would get
through the first line of defense. If the IP address doesn't trigger
anything then there is only the content left.
The spamassassin header says:
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,SPF_HELO_PASS
autolearn=ham
version=3.3.1
I am hoping that pulls some comments from others on the list. The
Bayes classifies it as non-spam. The points are so low that it is
triggers an autolearn as non-spam. This indicates to me that the
Bayes engine is not receiving enough feedback. It needs to be trained
on error to be effective. I think from your description that these
errors are not being corrected. No feedback exists. Therefore Bayes
can't learn from its mistakes. Without being able to learn from
mistakes, train on error, it will be poor at classifying mail.
Unfortunately I don't know what to suggest to you on correcting this
problem since you are in the middle and without easy access to the
humans who can train the Bayes on error. I can only note that it
needs training. And since this appears to be at the global MTA stage
in a milter that it will always be less effective globally than an
individualized Bayes database.
> btw - if it helps any, here is my postfix main.cf file, with the
> comments stripped:
>
> http://pastebin.com/kpJehe3Z
This is more of a matter of style but a long time ago a posting by Jim
Seymour taught me this.
http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
You'll observe that all of my anti-UCE checks are under
smtpd_recipient_restrictions, instead of having a separate
smtpd_client_restrictions, etc. This is because, unless you have set
smtpd_delay_reject = no (default is "yes"), no rejecting takes place
until after RCPT TO anyway. It's easier, cleaner and more
predictable when all of the anti-UCE stuff is under recipient
restrictions. (Except for reject_unauth_pipelining under Postfix
2.x. See FAQ Q16/A16. There are also possible performance issues
doing things this way. See "Understanding The Order In Which
Restrictions Are Applied" for more info.)
Please search down into the document for the excellent section
"Understanding The Order In Which SMTPD Restrictions Are Applied"
which explains this in greater detail. The entire article is packed
with useful information.
And so I now put all of my restrictions under the one check
smtpd_recipient_restrictions and avoid the duplication of having
multiple checks. Both are okay. A matter of style. But I like
having everything in smtpd_recipient_restrictions because then it is
simpler and harder to leave something out.
Also reject_unauth_pipelining needs to be a data restriction.
You have a long list of DNSBLs listed.
reject_rbl_client dsn.rfc-ignorant.org,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client combined.rbl.msrbl.net,
reject_rbl_client rabl.nuclearelephant.com,
That is quite a few. I think that can be trimmed down. I try to use
the smallest number of DNS lookups possible for the least load on all
of the servers. The Spamhaus ZEN list includes the XBL (exploits)
list which includes the sbl-xbl.spamhaus.org and cbl.abuseat.org lists
for example. And ZEN includes dul.dnsbl.sorbs.net. And
dsn.rfc-ignorant.org is dead now. I am not familiar with the others.
Perhaps someone on the mailing list will review the DNSBLs and make a
suggestion. Otherwise I pretty much feel exactly the same as the top
voted up answer from Justin Scott here.
http://serverfault.com/questions/13670/which-anti-spam-dns-blacklists-should-used
I hope you have configured a local caching nameserver in order to
cache the DNS queries?
You also have at least one obsolete feature. Remove it. It is
replaced by the "reject_rbl_client bl.spamcop.net" above.
maps_rbl_domains = bl.spamcop.net
I am not personally using reject_non_fqdn_helo_hostname nor using
reject_invalid_helo_hostname. Perhaps I should look into those. I do
have a custom check_helo_access map. I will leave them in my example
below without comment since you already had them.
Using your pastebin list as a starting point I think this following
might be okay. Just my comments and suggestion. Additionally I have
custom map rules similar those those suggested by Jim Seymour's fine
article. Really something like this is better for discussion on the
postfix-users list. I contribute it in the hope that it will be
useful and may serve as a template to start looking at things.
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rbl_client zen.spamhaus.org,
permit
Hope that helps and good luck!
Bob
