Mail Server best practices - was: Pandora's Box of new TLDs

Rich Kulawiec wrote:

Quoting <> :

  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
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.

Roger Marquis