Filtering Email

[Matthew Seaman]

On 05/01/2017 01:46, Doug Hardie wrote:
> I have a local mail server (postfix, dovecot LDA) that receives mail
> that is forwarded from my main account's mail server. Virtually all
> mail is forwarded so the received from address is the same for all.
> For a number of years we have used drive-by mail blocking on the main
> MTA.  Basically it sends a TEMP_FAIL to the first email from an
> unknown sender and then if they later retry, it is accepted. This
> blocked over 90% of the spam a few years ago as spammers didn't
> bother to pay for retries. However, the environment has changed and
> it appears that the spammer's MTAs now do retry so a lot of spam is
> getting through.

Yeah -- greylisting is now a lot less effective than it was, as the
spammers have learned to forward e-mails through real MTAs, and those
will retry after a tempfail.

> I am looking to be able to filter mail on the local MTA (either
> postfix or dovecot) so that I can have a table of IP addresses/names
> that if any appear in any Received header the email is filtered to the
> bit bucket. It appears that is possible in dovecot pigeonhole (I am
> using that). However, it is not table driven. You have to write a rule
> for each name/IP. I don't see anyway to have it refer to a table. Is
> such possible?

postfix is the right place to set up your blacklist.  Indeed, postfix
can read the blacklisted addresses from a file or from numerous types of
database.

See: http://www.postfix.org/header_checks.5.html (for filtering based on
Received: headers)

Otherwise, any spam filtering tool will be able to handle blacklisting a
list of senders.  Check out rspamd and rmilter in ports.

There's a potential problem with rejecting email from your local server
-- backscatter.  If your upstream MTA has accepted a message for
delivery and then your local MTA later decides to bounce it, there is no
choice other than to send the bounce to the sender address in the mail
headers, and spammers nowadays forge that address, so you end up
resending the spam to some (possibly innocent) third party.  It's better
to just /dev/null the messages in such circumstances.

	Cheers,

	Matthew





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20170105/0e316ff2/attachment.sig>