Re: BATV breaks rfc2821bis?

John Leslie wrote:
> ned+ietf-smtp(_at_)mrochek(_dot_)com <ned+ietf-smtp(_at_)mrochek(_dot_)com> 
> wrote:
> > To: Alessandro Vesely <vesely(_at_)tana(_dot_)it>
> >
> > > Section 4.1.1.2 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 
http://tools.ietf.org/draft/draft-varshavchik-verp-smtpext/

As for section 4.1.1.2, 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.