At 05:53 PM 3/8/2005 -0800, Russ Allbery wrote:
David MacQuigg <dmq(_at_)gain(_dot_)com> writes:
> At 02:37 PM 3/8/2005 -0800, Russ Allbery wrote:
>> That sure sounds like a Delivery Status Notification to me. I don't
>> see why it should be treated differently from any other DSN.
> If you send a Spam Bounce the same place you send a DSN, you are most
> likely sending it to a forged Return-path.
Given that spam is not reliably detectable in practice, that's the same
problem that you have with any DSN, which means that one needs to look at
how to handle DSNs on a broader basis. It may be that part of that
solution is to not generate DSNs, or generate DSNs differently, if one
believes the message to be spam, but that doesn't change the fact that
such messages are still DSNs.
The reliability of detecting spam should not be an issue for the mail
handling system. If the recipient thinks it is spam, it should be treated
as spam. It should not be treated the same as a normal DSN and routed as
shown in Fig. 5. It should not be treated as a normal message and sent to
the From or Reply-To address. Simply prohibiting Spam Bounces is an
option, but one that should be discussed with full understanding of the
cost and benefits.
It's more a terminology problem. It makes it sound like there's some new
type of message, when it's just a DSN for a message that one believes has
certain properties. A better term would be "DSN for detected spam" or
something along those lines.
It's definitely a terminology problem. Unfortunately, the terminology
seems to limit what we can discuss. Even when I try to make a clear
distinction between Spam Bounces, and normal DSNs, I still get arguments
like "Spam Bounces should be prohibited, because the Return-path might be
forged." or "You can't change the routing of DSNs. The Return-path is
expected and must be used." As long as we cannot separate the two groups (
Spam Bounces vs DSNs ) we will have these difficulties in communication.
"DSN for detected spam" is a little too verbose. I'll continue using "Spam
Bounce" in my own writing, and just repeat what I mean when there appears
to be some confusion.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *