[Top] [All Lists]

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

2005-03-07 17:26:38

At 10:13 PM 3/7/2005 +0000, willemien(_at_)amidatrust(_dot_)com wrote:

Maybe it is better to create a seperate section on messages with subsections for
- Delivery Status Notification
- Message Disposition Notification
- Message Filtering (SIEVE)

I would suggest to break section 4 services in to 2 sections
one for messages  and one for services (or agents)
Messages are things that are transfrered.
Services are the things that allow that things to happen.

the structure becomes then

4 messages
4.1 message components
4.1.1 Envelope
4.1.2 Message Header Fields
4.1.3 Body
4.1.4 Identity References in a Message
 (but this section should use the names used in the section on services)

4.2 Special messages
4.2.1 Delivery Status Notification
4.2.2 Message Disposition Notification
4.2.3 Message Filtering (SIEVE)

We need to treat a "Spam Bounce" as a separate kind of special message, to be handled differently than either DSNs or MDNs. We had great confusion in a recent discussion on [spf-discuss], because I was trying to define "Bounce" as something separate from DSN, but most think of the terms as synonymous. So I'm not sure what to call it, but "Spam Bounce" seems reasonably descriptive and unambiguous.

A Spam Bounce could be generated by the rMUA or the MDA and passed up through the same MTAs by which it came. Or it could be dropped at some MTA, depending on local policy and agreement between the two MTAs. It should never go the path of DSNs or MDNs because at that point we have reason to believe that the headers are forged, and the "Originator" will consider it more spam. There should be some easy way to identify Spam Bounces, like the Return-Path <null> on a DSN, to avoid interfering with normal mail and regular DSNs.

Until we have some common language, it is hard to even discuss these ideas.

-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *