Enabled Postscreen - #55
Conversation
c6529dc to
bd00800
Compare
|
Looks good - I look forward to seeing this feature integrated. Only one hint: you could amend setting |
|
@chrisblech this was on hold as I’m not sure we need to full RSpamD or SpamAssasin stack. Maybe we should have a clear mission statement. I’m happy to merge this if that proves useful though. |
|
@springcomp I see postscreen as filter on networking/protocol level, whereas RSpamD or SpamAssasin focuses on higher level filtering (content, SPF, DKIM). However, after enabling postscreen, I found that a relatively large number of emails were delivered with significant delays (sometimes up to 20 hours later). I am also not sure if any emails might have been lost entirely. As a first step, I therefore persisted the postscreen cache directory (so the cache wouldn't need to be rebuilt after every container restart) and enabled DNSBL as whitelisting for major senders. Despite this, I continued to observe significant delivery delays. Consequently, I have now disabled the "greylisting" feature entirely, so that postscreen only filters protocol violations. (All of this is included and commented in the latest commits of my PR #57 and #59) |
This PR adds pre-SMTP checks using Postscreen(8).
Note this PR deliberately does not implement DSNBL checks as these makes the configuration more complex. Those checks would be moved downstream to RSpamd or SpamAssasin milters anyway.