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