Paul Smith wrote:
> mouss wrote:
>>> That's fine, as it doesn't seem that the remote server is supposed to
>>> gain any benefit. It's the spoofed domain's MTAs which can gain the
>>> benefit.
>> but then why standardize the format? anybody can use "internal
>> aliases" of any form (aka disposable addresses).
> That's my view as well. A standard return path syntax (eg
> 'batv=<key>=<orig-local-part>@<domain>') is a good idea as it allows the
> original local part to be extracted if necessary, but beyond that,
> there's no point to a standard format for private keys.
"Extracting the local part" is obviously an interpretation of the
local-part, which would break section 2.3.11 of 2821bis, as SM
noticed. I don't recall anything in the standard that deprecates equal
signs in the local-part.
As I already stated in a previou reply, this document is "breaking" this
section of 2821bis. (I prefer the term "relaxing", is so much more, um,
relaxed.) I have no problem with it doing this and even welcome having this
capability, but it is definitely a big deal and therefore reqires extra careful
consideration.
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 violate 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.
Ned