On Tue, Apr 08, 2003 at 11:52:42AM -0400, Kee Hinckley wrote:
At 7:24 AM -0400 4/8/03, Daniel Feenberg wrote:
I think the problem is rather that forged return addresses make people
reluctant to use otherwise attractive methods for spam control. A content
based spam detector that had a 1% false positive rate might be acceptable
if senders were informed that their message had been rejected, but not if
As a counter-point, consider challenge-response systems, which are
happy to send bounces to all senders, assumed spam or not. Part of
the difference might be that individuals probably don't have a big
problem with bounces, but an ISP doing bounces is basically an
indiscriminate weapon. That's a good argument for a bulk bounce
protocol.
Strictly speaking, a challenge/response tool does not send a "bounce" or
error message. It sends a challenge, which is a new piece of mail, and
does not indicate the earlier message failed. A proper c/r tool is holding
the mail in a spool, to be delivered once the response comes. A "bounce"
means delivery failed, and the user may need to try again, or give up.
A C/R system MUST NOT challenge mailing list mail, for example, but a MTA
SHOULD send bounces/error reports on mailing list mail.
Challenges go to the author of the mail, as per the From/Reply-to, while
Bounces go to the envelope-from sender of the messages.
Now, one could define a set of practices for challenge/response, so that
the processing of challenges at the recipient end can be streamlined.
Though in most cases not automated of course as that would defeat the point
of some challnge systems, though "stamp" based systems would actually wish
to automate the response, especially if it were a CPU based stamp.
However, the key realization in all this discussion of bouncing is that
any anti-spam nature will cause some mail to be blocked, and since spam is
now over half of all mail, in fact it will cause _most_ mail to be blocked.
As such it is a very difficult task not to include some legit mail in that
pool
Though in most cases not automated of course as that would defeat the point
of some challnge systems, though "stamp" based systems would actually wish
to automate the response, especially if it were a CPU based stamp.
However, the key realization in all this discussion of bouncing is that
any anti-spam nature will cause some mail to be blocked, and since spam is
now over half of all mail, in fact it will cause _most_ mail to be blocked.
As such it is a very difficult task not to include some legit mail in that
blocked set. Perhaps impossible.
Thus good error reporting on spam blockage is a MUST. The current all too
common
practice of dropping legitimate mail on the floor with nobody aware of it
is really not an acceptable design.
The people most likley to feel the pinch are mailing list operators, though
their pain per lost messages is less than that for person to person messages.
However, they will feel most of the brunt because they send the most legit
mail and their activites are technically very similar to spam, the only
difference being that people want to be on their lists.
It occurs to me that improved and more efficient error reporting lets us track
where our anti-spam solutions are failing us.
I would even think outside the box on error reporting. For example, I could
imagine defining an errors-to style header which allows the specification of
a URL for http/https POST of error reports. (An E-mail bounce to be sent
if the POST fails for whatever reason.)
This would actually be more efficient than using SMTP for this, and makes a
annoyance attack almost impossible since you can use a reserved word in the URL
to
assure only people who wanted to get email errors get them. (People can
still forge messages to get people unsubscribed however.)
I can also imagine big mail providers using this. AOL for example could then
collect most bounces on messages sent by AOL members at an HTTP address, and
collate the so the user can, with a web interface, see their latest mail
failures
at any time. (Any new mail failure after the last browsing would normally
cause an E-mail indicating "there are new mail failures", but the volume in
the mailbox would be reduced for ones that come in bunches)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg