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
<PostConf | Documentation; :
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
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
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