Henrik Levkowetz <henrik(_at_)levkowetz(_dot_)com> wrote:
On 9 Mar 2003 02:41:20 "Mark Delany" <tcrcn-6ugsc(_at_)qmda(_dot_)emu(_dot_)st>
wrote:
<snip>
The one down side is that all mailing lists have to send individual
mails to each recipient and we all know what sort of red flag that is
to some bulls.
That sounds as if you think the confirmation token needs to be handled at
RFC2822 level rather than at RFC2821 level. Since the mailbox to which the
message is to be delivered is identified only at RFC2821 level, that seems a
little odd to say the least. Surely the token should be handled at the
envelope level, just as a matter of principal (the tokken expresses consent
relating to an envelope - RCPT_TO - destination, not to anything specified
in the content, in the context of the envelope sender (mailing list) not in
respect to anything specified in the content). And putting it at the level
it belongs at would avoid waving that red flag to those bulls.
As well as elimintatinmg the red flag, putting the token in the appropriate
level of protocl eliminates another problem that would arrive from putting
it in the wrong place. Email sent through RFC821 systems does not have to
conform to RFC2822 (see first two paragraphs of section 2.1 of that RFC,
which list some mail content RFCs which use octets not permitted in RFC2822
conformant mail). There is no requirement on MTAs to understand RFC2822 or
any other standard that might be used to encode a mail body - they only have
to understand RFC2821. I think that the volume of RFC2822 non-conformant
email is now greater than the body of RFC2822 conformant email (it
certainly is in terms of mail I receive, one reason being that a lot of it
uses the ISO western European character set rather than USASCII). So putting
the solution in a replacement for RFC2822 instead of in a replacement for
RFC2821 will just not work for most mail transferred through RFC2821
conformant MTAs unless we put it also into every other content encoding
standard (and it would require MTAs to have to mess about in stuff that is
essentially none of their business).
Tom Thomson
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg