Posted Jan 7, 2010 12:46 UTC (Thu) by anselm (subscriber, #2796)
[Link]
By way of clarification, I think the upstream comment meant »once the mail
has entered the local queue«.
It is possible to reject a message while it is being submitted, but once
the local MTA has accepted responsibility for it it can only be bounced,
which as has been noted will in most cases inconvenience those people
whose addresses the spam claims it is being sent from.
To reject spam rather than bounce it, one needs to run anti-spam software
while the message is still in the process of being read, where the more
common setup is to run the anti-spam software after the message has
been accepted locally but before it is delivered to the addressee's
mailbox. Depending on the checks the anti-spam software performs
(especially ones that access the network), pre-queue checking may be a
resource-intensive process, so it requires careful configuration.
Spam folders considered harmful
Posted Jan 7, 2010 13:07 UTC (Thu) by jschrod (subscriber, #1646)
[Link]
Posted Jan 7, 2010 13:19 UTC (Thu) by dwmw2 (subscriber, #2063)
[Link]
Well, with the exception that it seems to be suggesting that people use backscatterer.org. It does admit that that list includes servers which only do sender verification callouts and don't actually send bounces, but then in the very next sentence says "That list can be used to reject just unwanted NDNs.", which is obviously false.
Backscatterer.org is definitely best avoided, because it deliberately includes these false positives.
Besides, there are much better ways (PRVS/BATV/etc.) to avoid unwanted bounces.
My setup for that is documented here, although it can be done more simply now that Exim has built-in PRVS support. In short, the way it works is that I never send MAIL FROM:<dwmw2@infradead.org> and thus I never accept bounces to that address. And anyone who does sender verification callouts doesn't accept mail that's faked from my address either.
But we digress...
Spam folders considered harmful
Posted Jan 7, 2010 14:23 UTC (Thu) by jschrod (subscriber, #1646)
[Link]
I didn't want to imply that backscatter handling is described there best, but that the reasons why (a) one shall reject spam, not bounce it, and (b) that spam rejection after DATA is explicitely allowed by RFC 5321, contrary to the statement by fluke571.