Re: Last Call: draft-klensin-rfc2821bis: Permitted and prohibited characters in addresses

["Frank Ellermann" <[e-mail]>]

John C Klensin wrote:

> it is clear that the rules are different from the syntax alone.

For details like length restrictions that might be the case, but
for simple questions I expect that the syntax means what it says.

> In other words, 
>    RCPT TO:<"Acct\ UserID"@domain>     and
>    RCPT TO:<"Acct UserID"@domain>
> are valid (although the first one is discouraged now)

A perfect example where something is NOT clear.  *Unnecessary*
quoted pairs in a quoted string are discouraged, but Alexey has
shown us that <"Acct UserID"@domain> is not allowed, and so the 
quoted pair in <"Acct\ UserID"@domain> is apparently necessary.

I vaguely recall a discussion about spaces in local parts years
ago in a Geman mail abuse newsgroup, unfortunately I forgot the
result, but if it was "RFC 2822 is only a PS" that would be bad.  

IMO this is no 2821(bis) issue but a problem for 2822(upd).  And
for EAI, they try to introduce *new* unnecessary quoted pairs,
as if the existing mess (e.g. 3696 errata) isn't bad enough.

>    RCPT TO:<Acct UserID@domain>
> is not and has never been.

ACK  

> Despite the way the 2821 syntax is constructed, with an
> invocation of "qcontent" which implicitly references a
> definition in 2822 and its use of the contentious NO-WS-CTL,
> there is very clear (to me at least) prose in 2821 that
> prohibits those controls entirely.

NAK, not clear for me.  My interpretation of re-using 2822(upd) 
rules in 2821(bis), where that's possible, is that the concepts
of "local part", "domain", and "address" must be identical in
2821(bis) and 2822(upd).  Of course you can't import CFWS into
2821(bis), sometimes you're forced to roll your own ABNF.  The
syntax should still be "identical modulo CFWS".

> we don't need to have a further discussion about whether it
> is time to finally get rid of them because we did it during
> DRUMS.

If RFC 2822 was a product of DRUMS it is IMO a showcase, and if
RFC 2821 was a product of DRUMS it is a counter-example.  That
is now ancient history, the reality is:  

- RFC 2821 doesn't tell us what to do with IPv6, 2821bis admits
  that this isn't trivial.
- RFC 2821 silently assumed that nobody forges envelope sender
  addresses because that made no sense in the time of 821, and
  it also made no sense with the design of 821.  But 1123 broke
  the 821 design, and 2821 did not admit that it is broken.
- RFC 2821 silently assumed that "accept, and let's see how it
  works out" is the best strategy.  But in practice this either
  means "bounce to a forged envelope sender address" or "drop 
  the mail if it didn't work out".  
- There's too much cruft in 2821, e.g. the source route business
  is only relevant for folks interested where 1123 broke 821.
  Anything about it could be removed from 2821bis keeping only
  <A-d-l> and <At-domain> as "MUST accept, MUST ignore, MUST NOT
  generate, no need to know what it was decades ago".
- While RFC 2821 inherited the 1123 5.3.6(a) bug 2821bis should
  admit that "keeping the envelope sender as is" in forwarding
  to third parties violates an essential point in the original
  SMTP, the complete transfer of responsibility at all relays,
  with obvious ways (251+551) to accept or reject this transfer
  of responsibility.
- The discrepancies about what mailing lists really are (noted
  in the Last Call) should be also addressed.  Bugs and issues
  should be fixed or documented.  Just "not talk about it" (if
  it could hurt the feelings of ML operators) does not cut it.

> I will leave to others whether or not that raises an 
> interoperability testing/documentation problem with 2821bis

Or rather for 2822(upd).  SMTP tests could verify that nobody
rejects <"Acct UserID"@domain> as SMTP syntax error, then it's
an issue for 2822(upd).  <recycle> Your original 2005 proposal
to work on 2821bis and 28822upd simultaneously in a proper WG,
after fixing non-controversial errata and some ABNF nits, was
the way to go </recycle>

2821bis and 2822upd are far too important to get them wrong.
It's a bad sign if *new* issues turn up in an IETF Last Call.

  [CTL]
># These characters MUST NOT be used in MAIL or RCPT commands
># or other commands that require mailbox names.
 
> This seems very clear to me.

It is clear, so let 2822upd fix it where it has other ideas:

If CTL made sense in addresses for other protocols (not SMTP)
2822upd could move NO-WS-CTL to "obs" with a historical note.

If CTL never made sense 2822upd could drop it completely, all
"obs" constructs are still "MUST accept" (outside of Netnews).

For 2821bis I fail to see why it permits DEL in <ehlo-param>,
and why it permits NUL and NO-WS-CTL in <ehlo-greet>.  If the
only justification is "copied from 2821" it is IMO not enough
to violate net-utf8.  Four occurences of 127 in 2821bis, one
explaining why CTL is bad, two excluding CTL but permitting
DEL, and one ugly <ehlo-greet> permitting NO-WS-CTL plus NUL.

> Quoted-string  = DQUOTE *qcontentSMTP DQUOTE

A separate solution should be "plan B" if 2822upd is forced 
(or wishes) to keep something that cannot fly for 2821bis.
And "moved to obs" could still mean "kept" for your purposes.

Unless 2822upd introduces a syntactical finesse allowing to
import clean "non-obs" terms in other RFCs.  DKIM and others
needed a "clean" FWS, unfortunately 2822 only offers FWS in
combination with obs-FWS.  That is only a notorious example,
FWS does not affect 2821bis.

> this exactly restores both the substance and form of the
> 821 rule, adjusted to reflect the prohibition on control
> characters introduced in 2821.

Okay, maybe pick nicer names than <quoted-pairSMTP> etc.,
how about <S-quoted-pair> ?  

> While (3.a) makes part of it redundant, I suggest leaving
> the paragraph quoted above in the text and intact.  It
> contains the explicit MUST NOT prohibition and may be more
> clear in context than the ABNF comments.

Yes, "make a shorter RFC" was never an objective for 2821bis,
and starting with it here would be strange.

>| The reader is cautioned that the grammar expressed in
>| the metalanguage is not comprehensive.  There are many
>| instances in which provisions in the text constrain or
>| otherwise modify the syntax or semantics implied by the
>| grammar.

<shrug />  Of course the prose and especially 2119 keywords
have a purpose, and stating the obvious can be confusing...
 
As noted in the Last Call I also fail to understand why you
copied 2119 definitions verbatim instead of referencing the
source.

> Does that help move us forward?

For that particular issue, assuming that 2822upd can't fix
it, yes.  Generally I've no good idea, of course 2821bis is
better than 2821, therefore it should be published.  But it
doesn't address important problems with the 1123 design for
a world where almost 90% of the mail traffic is spam.

I'm also not sure about IPv6 MX and AAAA issues when an IPv6-
only sender meets an IPv4-only receiver with the help of an
IPvAnything forwarder, a variant of the 1123 5.3.6(a) issue.

 Frank