[COLUG] another anti-spam link

[Duane]

Rob Funk wrote:
> Duane wrote:
>> Rob Funk wrote:
>>> If I can reject before accepting I will, but I'm not going to drop a
>>> message on the floor if it may have been legitimate.  My users get
>>> upset when their mail doesn't get through.
>> Yet others get upset at all the bounce spam :P
> 
> Which is why I fully intend to move amavis processing up in the chain a 
> bit, so all spam rejections happen during the SMTP connection.
> 
> But that doesn't remove the need for bounces to get through.  Bounces 
> still happen for reasons other than "we think your message is spam".

I can only think of one legit situation where bouncing would still be
suitable, that is accepting and acting as a relay either the whole
domain or just mail aliases where the remote end is down/rejecting your
 MTA from sending etc, everything else should be rejected at the
pre-queue/pre-disconnection stage.

Postfix can check the following things pre-queue either directly or via
milters/proxies/etc:

* Sending and receiving domain is legit
* Remote system isn't trying to fake being the local mail server
* Helo/RCPT/FROM isn't obviously bogus, and conforms to RFCs.
* Incoming IP/Helo has valid PTR and A records
* Receiving email address/alias/etc is legit
* Incorrect sending, such as not waiting for the MTA to reply to
responses sent, trying to do unauthorised pipelining.
* SMTP authentication as well as IPs allowed to send, or POP/IMAP before
SMTP authentication.
* Custom black/white lists
* Reducing the default amount of allowed recipients below the 100 RFCs
suggest, while this goes against RFCs I know of only one customer that
tripped up on this legitimately and we set them up with a proper
opt-in/out mailing list afterwards which they were much happier with.

>From there we can check with:

* Greylisting
* Suitable blacklists if you must.

Then still before the mail has been accepted and if it passes all that
we can dump to Amavis which can:

* DCC checking
* MIME/file extension blocking, this prevents most stuff that clam would
have flagged, you need to have the unrar and unzip apps, if not others,
so archives can be scanned as well
* Do Anti-Spam (about a dozen or so diff options, including Clam-AV)
* Spamassassin checks: DKIM, SPF, Locales, ASN (informational mostly for
helping Bayes), Bayes, RBL, various body and header evaluations such as
relay headers and such, URI evaluations and differences between the link
text and the link, FuzzyOCR for image spam.
* DSPAM which does statistically flagging, though with everything else I
dumped this as it never picked anything up and was a waste of CPU
cycles, although I've also heard that it doesn't work as well as
spamassassin except for new types of attacks spamassassin doesn't have
code for, and it's bayes filter hasn't learnt yet.

If the mail makes it through all that and is spam, I dump it in an IMAP
folder so spamassassin's bayes filter can learn from it, and once a week
or so I dump copies of legit mail to a ham folder.

I found it useful to set the spamassassin kill threshold globally a
little higher then spamassassin default, it reduces the complaints, but
those wanting to crack down can go into squirrelmail where I loaded the
spamassassin SQL plugin and they can tweak their personal preferences up
or down etc.

Ummmm so yea, normally there shouldn't be any bounces generated, I
recently found out postfix could be set to try sending bounces once, the
deferred mail queue is way down as a result.

-- 

Best regards,
 Duane

http://www.freeauth.org - Enterprise Two Factor Authentication
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."