ietf-smtp
[Top] [All Lists]

Re: draft-crocker-email-arch-03 Users, MDA and administrative domains

2005-03-09 13:42:36

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        *
*************************************************************     *