Mail Filtering Best Practices

[Heather Stern]

> 	tail -F /var/log/maillog.0 | egrep '(reject=|did not issue)'
> 
> just so I could be aware of collateral damage from that change.
> 
> When I did not receive the confirmation within a couple of minutes, I
> looked at the message log.  Sure enough:
> 
> 
> Feb 16 18:17:30 janus sm-mta[60727]: h1H2HUi9060727: ruleset=check_eoh, arg1=5, arg2=406, relay=listserv.NoDak.edu [134.129.111.8], reject=553 5.0.0 Do not expect me to track your messages for you
> Feb 16 18:17:31 janus sm-mta[60727]: h1H2HUi9060727: from=<LISTSERV at LISTSERV.NODAK.EDU>, size=1570, class=0, nrcpts=1, msgid=<200302170217.h1H2HUi9060727 at janus.catwhisker.org>, bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=listserv.NoDak.edu [134.129.111.8]
> Feb 16 18:17:31 janus sm-mta[60727]: h1H2HUi9060727: to=<david at CATWHISKER.ORG>, delay=00:00:01, pri=30406, stat=Do not expect me to track your messages for you
> 
> 
> Nuts.  Since I really did want to subscribe to the list, I put an
> exemption in for that machine.  :-(
> 
> A day later, I sent a query off to postmaster at listserv.nodak.edu, asking
> if there actually was a reason they sent out messages without Message-Id
> headers.  No response to date; I'm not holding my breath.  (OK; I confess
> that I strongly suspect that the term "LISTSERV" explains a great deal
> of the misconfiguration that I perceive.)

Hmm.  One of my clients has had fairly happy succes with dropping mails
with malformed Message ID fields in the spambait trap.  Of course his 
whitelist goes first.   

But no message IDs at all?   <dubious glance in their direction>

> Oh -- I'll gladly receive suggestions for improving the message.  :-}
> 
> And if folks think such a check ought to be implemented for baylisa.org,
> I'm willing to discuss it, and possibly even do it.  :-}

In the handful of R2CH threads I've been in - more in recent months it
seems - it all comes down to policy.

If the list owners do *not* have a preference where the traffic is to
stay - public or private - then leaving reply-to alone seems fair
enough.  The most common cries on the pro-header side (either end) are
that people are too dumb to do the right thing when it's needed.

We're the email version of a room full of sysadmins.  I think we're 
bright enough to check headers if we explicitly want something taken
private.   But I note that if mail starts on a list, and becomes
private, you'd be wise to *mention* it, if you want it to stay there
rather than just be a quiet stray comment amid the hubbub.   For my own
inbox, asides to seek out my consulting services, are, of course, always
welcome.

Filtering methods used here include:
	whitelisting known pals and mailing lists
		Also sorts them out into logical groups so I can focus
		better

	checks on wild charsets -- the ones I don't read, mainly
		I may have to relax this soon for japanese; not 
		because I'm learning it, but because I may have contacts
		at a conference who use that chara=set, and may not be
		able to whitelist them all at once.

	messages which consist of an attachment and nothing else
		usually spam trying to avoid internal-text based
		checking, but sometimes someone may send an attachment
		"loose" after a couple of messages that are supposed
		to be heads-up for it.

	lame header effects check
		nessage ID, a few types of glitches that seem to 
		indicate injected mail.

	egregious words check
		not too bright, but that's what scoring is for

	a few "victimized" recipient accounts for me go after the
	spam checks rather than before.

	items flagging no special known qualities go in a greylisted
	mailbox.  spam that gets there I refile rather than delete
	so I can improve the scanning tricks.

The charsets and attachments nailed a lot more of the total than I would
have expected.

None of these require DNS hits.  That's what the MTA is for.

 Heather Stern - star at starshine.org -*- Starshine Technical Services
        Sysadmin Support & Training -*- consulting at starshine.org