Mail Server best practices - was: Pandora's Box of new TLDs
marquis at roble.com
Sun Jun 29 15:49:18 CDT 2008
Rich Kulawiec wrote:
>> Quoting <http://www.postconf.com/docs/spamrep/> :
>> The only reliable way to avoid false-positives is by monitoring
>> the email server or gateway logs and allowing end-users to receive
>> a daily report of email sent to their account that was identified
>> as spam and filtered.
> First, it is impossible to avoid false positives (unless you turn all
> spam filtering off) or false negatives
A bit of a Red Herring as nobody expects 100%.
> Second, while in principle this isn't a bad approach, in reality it
> tends not to work well.
Judging by user acceptance, over a decade's use and several thousand users,
it works better than any other method, certainly better than silently
rejecting and discarding spam on the one hand, or tagging and delivering it
on the other.
Not that any ISP delivers everything (since ~1996). The ones that try
learn a hard lesson in DOS or they lose customers (remember netcom.com).
The issue isn't delivery, it's reporting, and only ISPs that inform users
about _every_ rejected or discarded email are capable of effectively
minimizing false positives.
> It requires that users weed through the daily reports
Looks like you haven't looked at the reports. Nothing in them is more
difficult to parse than a large spam folder. I'm guessing you also don't
intend to imply that users look in their spam folder?
> and it requires accepting and storing considerable volumes of
> mail which are likely spam/phish/virus/etc.
You must be talking about some other system. Volumes of mail stored in
spam folders are what reports _avoid_. Simple text reports take almost no
disk and, for most users, a year's worth of searchable daily reports takes
just a few MBs.
> can make FP detection difficult, since senders do not get a
> reject (mail was accepted, after all; why should they?) and thus
> may be unaware that their message was dropped in a probable-spam
You really should read the URL cited above, and have a look at the sample
Whether spam is rejected outright or discarded after delivery is not
relevant since good reports list both. Users don't make a distinction
either, as long as they know what was filtered.
Whether to A) reject or B) accept and discard is also a bit of a red
herring. Most spam will get reject by RBLs but you still _must_ run
everything else through Spamassassin and AV, and there's no way to do those
checks pre-queue without SMTP timeouts and DOS.
More information about the NANOG