On 10/11/2018 01:35 AM, Matus UHLAR - fantomas wrote:
note that spamassassin can run at MTA level, refusing mail when it's found to be sure spam and tagging when it's not.
Yes.That's how and why I recommend that people run SpamAssassin if they have the choice to do so.
I for example run spamass-milter with -r 10 (rejects score over 10) at one machine, and amavisd-milter with "spam_kill_level_maps => 10", along with postscreen.This way mail gets refused when listed in DNSBLs, while not when DNSWL (but still when DNSBL score is higher than DNSWL) and also when SA detects it's score is over 10.
Agreed on all accounts.But that's doing the RBL checks in SpamAssassin, not directly in the MTA. Read: It's not the MTA making the choice based on the RBL data. Rather it's the MTA making a choice based on the data from SpamAssassin, which is partially making a choice based on RBL data.
...clients from internal networks run SA as content_filter (post-queue) so they don't complain sending mail (SA scanning at MTA level) taked too long.
That's why I tended to have different email hygiene configurations on the MSA and MTA(s). Ideally the client submits to the MSA with minimal checks, after all we know who the message originated from based on authentication. The MSA will then smart host the message through the MTA, which does more hygiene checking.
I originally migrated to this configuration when I had clients on dial up connections run into timeouts whens s l o w l y sending attachments. So they can take as long as they need to (or not) to send to the MSA, which can then quickly send to the MTA with filtering.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
