Re: MTS transparency and anonymity

On Fri February 25 2005 17:34, Keith Moore wrote:

> At the same time, the From field has been required for at least
> 25 years now, and there's a lot of software out there that was
> written to that specification.  There's no way we can expect to
> survey all of that software to determine whether omission of From
> will adversely impact it.  Email is already fragile enough (for
> instance, due to the filters that Ned refers to) that we should
> be very reluctant to create additional reasons for things to break -
> particularly when we don't gain any additional functionality to
> compensate the public for the breakage.

There is existing functionality (purported to exist) but which is
not achievable (correctly) w/o some change; see the discussion of
RFC 822 section A.2.6 and RFC 2822 section 3.6.2 (which are in
conflict).  That is the case of a message author with no Internet
mailbox [not necessarily unusual, given availability of we-based
interfaces for sending mail by anyone with HTTP access, even if
that person has no Internet mailbox].

There is additional functionality in provision for anonymous
authorship, which is important for reasons detailed in the draft.

And, as you point out, it is unclear whether there would be any
breakage.

> So I'd much rather define some 
> convention for a non-replyable address (e.g. From: <anonymous@[]> ) 
> which is at least syntactically compatible with RFC [2]822,
> than to say it's okay to omit the From field.

First, the intent is to provide for messages where the author
either has no Internet mailbox or is unable to disclose an
Internet mailbox, not specifically for "non-replyable"
conventions (for some unspecified purpose(s) and/or
condition(s)).  That is a matter of scope.

Second, the local-part can only be interpreted within the domain
in the mailbox specification.  It is therefore largely irrelevant
to either the scope of the draft or to your "non-replyable" case.
Aside from the local-part, your present example is the same as
the <""@[]> that was discussed quite some time ago.

Third, RFC 822 does not directly give ABNF for a domain literal,
instead deferring to RFC 820, which specifies four dot-separated
decimal integers in the 0-255 range.  RFC 2822 does give ABNF
syntax, but it is so broad (IPv6 issues not having been settled
at the time) as to permit almost anything, including non-whitespace
control characters; 2822 provides no guidance regarding the
semantics of domain literals, deferring to RFC 2821, which
has  provision for IPv4 dotted decimal quads and for tagged
IPv6 and tagged "General" literals.  The tags referred to in
2821 "MUST be specified in a standards-track RFC and registered
with IANA" -- I know of no such RFCs or registrations as of this
time.

So while I am not outright rejecting any such convention, I
believe that there are several issues that would have to be
carefully considered:
1. Conformance to RFC 2821 syntax as referenced by 2822 for syntax
   and semantics of domain literals.  This is also necessary for
   the case of SMTP gateways, which are expected to ensure
   that address fields (incl. From) are "effective and useful
   for sending replies".  Given the realities of the situations
   covered in the draft and your "non-replyable" case, I
   suspect that's a non-starter (unless you want to amend RFC
   2821 section 3.6.4 as well; and as noted, the draft under
   discussion carefully avoids transport issues -- there may
   well be other transport mechanisms that impose other,
   possibly conflicting, constraints on syntax and semantics;
   that would need to be researched).
2. Local-parts would have to remain irrelevant. To avoid
   possible conflicts with local-parts in use at a recipient
   site, any domain literal would have to be one guaranteed
   not to be interpreted as local anywhere.  That pretty
   much rules out all IPv4 literals (RFC 3330). I do not
   know if there are any IPv6 literals which would carry such
   a guarantee; that would have to be investigated as a
   possible approach.  Failing that, a Standards Track RFC
   defining an LDH tag per RFC 2821 would have to be published
   and the tag registered by IANA.  Then MUAs, MSAs, MTAs,
   etc. would have to be modified to recognize the tag. I
   suspect that we have another show-stopper, because ...
3. The impact on the existing infrastructure would have to be
   considered.  While it is certainly possible that there
   exists some software which does not gracefully handle
   absence of a From field, it is certainly the case that
   all transport and UA software currently fails to recognize
   an as-yet unspecified and unregistered tag in an RFC 2821
   domain literal.  I suspect that most don't handle the
   2821 "IPv6" tag.  I strongly suspect that older
   implementations in particular would attempt to hand off
   literal content, tag and all, to a resolver; that is
   unlikely to produce desirable results, and may cause
   confusion (e.g. the first 32 bits being interpreted as
   a binary IPv4 address) or other problems.  In short, I
   believe such an approach would lack backwards compatibility
   (indeed, the RFC 2821 "General" literals seem to have
   that problem, and as noted, I suspect that the "IPv6"
   tag itself poses compatibility problems).

In light of the above considerations, I cannot see that a
convention such as your example would (if properly designed
to conform to RFC 2821 requirements) result in fewer
problems than simply making the From field optional. Because
of the nearly universal loathing of <""@[]> when it was
last discussed, I did not include syntactically valid
(and that case really isn't valid if one follows 2822s
redirection to 2821) constructs in the list of alternatives
considered.  I'll rectify that omission in the next draft
revision.