Clarification:
----- Original Message -----
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
To: <willemien(_at_)amidatrust(_dot_)com>
Cc: "IETF-SMTP" <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, March 30, 2005 8:32 AM
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Finally, Dave brought up the question, what about DSN and MDN.
Same basic issues. It should be pointed out they are not requirements to
be
part of the IEF. But DSN and MDN are more well defined, very easy,
generalized structural issues that fit cleanly into the automated and
generalize framework.
More to my points:
DSN is based on a generalized bounce requirement that is a natural part of
the IEF. DSN is an optional and specific standard implementation of the
requirement.
MDN is based on a RFC 2822 header existence. Also a natural part of a IEF.
On the other hand:
Sieve is based on a Mail Filtering concept that is _not_ a requirement to be
part of the IEF process. You can pull the "SIEVE" box, the message
filtering concept, out from figure 5 and you still have a generalized IEF
process that is widely in place. You can not do the same with Bounce (DSN)
or return receipt (MDN) concepts without breaking the framework.
Suggestion:
- Change the Sieve box to MFA (Mail Filtering Agent).
- Reference Sieve parentheically in the document, such like others are (i,e.
POP, IMAP, etc).
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)