Re: Mail Server best practices - was: Pandora's Box of new TLDs
Rich Kulawiec wrote:
notification is essential in order to provide a heads-up about problems (and that once problems are noticed, cooperation is essential in order to fix them). But mail should never be discarded without notice
In practice we've found that (notification) is the core issue. Reject v discard is a non-issue by comparison. The format of those notifications does not have to be a spam folder, as many seem to assume. A summary report serves the purpose far better than tagging and delivery with far less overhead. 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. This is more or less identical to the issue ISP's like Comcast face when implementing QOS or other filtering, when they fail to notify end-users. Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted. Roger Marquis
On Sun, Jun 29, 2008 at 07:55:07AM -0700, Roger Marquis 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.
Two comments: First, it is impossible to avoid false positives (unless you turn all spam filtering off) or false negatives (unless you block everything). The discussion thus shouldn't focus on 0% FP, 0% FN, but on how to minimize both simultaneously such that the percentages are acceptable to the receiving organization. (Note as well that FP and FN are always defined on recipient side, never the sender side.) Second, while in principle this isn't a bad approach, in reality it tends not to work well. It requires that users weed through the daily reports (which they won't) and determine what's spam/not-spam (which they'll get wrong) and it requires accepting and storing considerable volumes of mail which are likely spam/phish/virus/etc. It also 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 folder. I find it's much better to reject outright with a very clear error message (that provides recourse for senders who believe it to be in error) and then address the resulting issues at the postmaster level (since in most environments such issues are likely to effect more than one user). ---Rsk
On Sun, Jun 29, 2008 at 07:55:07AM -0700, Roger Marquis wrote:
Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted.
A fine point that I don't see mentioned much is that REJECT-ON-SMTP-DATA has the nice side effect that if it's real mail, the *sender's* MTA will generate their bounce for them, and if it's a spammer, they'll ignore it. So you get the best of both worlds, which seems an excellent reason to go through the effort of setting it up that way. Cheers, - jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)
participants (3)
-
Jay R. Ashworth -
Rich Kulawiec -
Roger Marquis