[Top] [All Lists]

Re: BATV breaks rfc2821bis?

2008-05-22 05:10:35

John Leslie wrote:
ned+ietf-smtp(_at_)mrochek(_dot_)com <ned+ietf-smtp(_at_)mrochek(_dot_)com> 
To: Alessandro Vesely <vesely(_at_)tana(_dot_)it>

Section additionally states that "The reverse-path consists of
the sender mailbox", not a variation thereof. That wording apparently
bans using time-varying tags, unless we reinterpret BATV as a
redistribution service for ephemeral ad-hoc lists, in the sense of
section 3.9.2 (but beware poor subscription policies.) A rather
cumbersome way to standardize things.

OK, I have to admit I hadn't thought of or noticed this conflict. As a
practical matter there are already an abundance of schemes that violated
the letter, if not the intent, of this language: SRS and VERP immediately
come to mind. I therefore wonder if this isn't something we ought to
consider "relaxing" in 2821bis.

Or 2821ter, as Frank suggested. However, please don't mistake me for a foxy Faust if I say I'd like to be still alive the day it comes :-)

   Though it's still possible to do substantive changes to 2821bis, since
the IESG hasn't acted on it, I'm not sure there's any need. After all,
"mailbox" means whatever 2821bis chooses to mean by it, and that would
seem to be defined in 2.3.11:
" " As used in this specification, an "address" is a character string
" that identifies a user to whom mail will be sent or a location into
" which mail will be deposited.  The term "mailbox" refers to that
" depository.  The two terms are typically used interchangeably unless
" the distinction between the location in which mail is placed (the
" mailbox) and a reference to it (the address) is important.  An
" address normally consists of user and domain specifications.  The
" standard mailbox naming convention is defined to be
" "local-part(_at_)domain";

The above quote is general enough, and clarifies some important concepts.

" contemporary usage permits a much broader set of
" applications than simple "user names".  Consequently, and due to a
" long history of problems when intermediate hosts have attempted to
" optimize transport by modifying them, the local-part MUST be
" interpreted and assigned semantics only by the host specified in the
" domain part of the address.

The latter part provides room for local mangling, but does not help devising ways to "drop messages with invalid return addresses", as mentioned in section 6.2. If it is possible to explicitly encode validity information into a local part, it should be legal for a remote host to take advantage of it. Thus, it should be up to the BATV (or analogous) specifications to state who may do what with any meta information encoded in the local part. The scope of the last quoted sentence could be restricted by appending, say ", unless otherwise stated by the relevant SMTP extension." However, for that to make sense, it is necessary to mention that extensions can also be encoded in mail addresses, besides additional SMTP commands or parameters.

It might be something similar to, e.g.,

   Local-part     = Dot-string / Quoted-string / Ext-string
   Ext-string     = Ext-prefix 1*("=" Atom) "=" Local-part
   Ext-prefix     = 1*Let-dig *Atom
   Atom           = 1*(atext except "=")

That would allow a whole new tide of extensions, in addition to traditional encodings such as VERP, which is alluded to, but not mentioned, in section 3.9.2. In this case, interpreting the local part may be useful to avoid sending multiple copies of the same message to the same MTA, as described e.g. in the expired

As for section, in the phrase "the reverse-path consists of the sender mailbox" I'd use a different verb, e.g. "involves", "depends on", "belongs to", that retains the intended semantics without mandating formal sameness. It may help legal concerns to state that the reverse-path is owned by the sender.

The historical note at the end of section 4.4 says that "The reverse path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages." Perhaps that could be extended saying that the return-path should be used (only?) for messages concerning the delivery of the message, in order to account for vacation messages and similar stuff.