Subject: [ietf-smtp] FWD: [Technical Errata Reported] RFC5321 (5414)

From: John C Klensin <[email-masked]>
Date: Fri, 29 Jun 2018 20:49:34 -0400

Anyone have comments on this?  I don't remember whether there
was a reason it was done the way it was or if that was just a
dumb ABNF error.

   john

---------- Forwarded Message ----------
Date: Friday, June 29, 2018 15:30 -0700
From: RFC Errata System <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC5321 (5414)

The following errata report has been submitted for RFC5321,
"Simple Mail Transfer Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5414

--------------------------------------
Type: Technical
Reported by: David Romerstein <[email-masked]>

Section: 4.1.2

Original Text
-------------
Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

Corrected Text
--------------
Quoted-string  = DQUOTE 1*QcontentSMTP DQUOTE

Notes
-----
As written, this allows for an email envelope recipient
(Forward-path) with a NULL value for the local part of their
address. This is a functional departure from similar wording in
the preceding RFC 821, which defines quoted-string in such a way
as to require at least one character that is not one of the
surrounding quotation marks.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary,
please use "Reply All" to discuss whether it should be verified
or rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if
necessary. 

--------------------------------------
RFC5321 (draft-klensin-rfc2821bis-11)
--------------------------------------
Title               : Simple Mail Transfer Protocol
Publication Date    : October 2008
Author(s)           : J. Klensin
Category            : DRAFT STANDARD
Source              : IETF - NON WORKING GROUP
Area                : N/A
Stream              : IETF
Verifying Party     : IESG

---------- End Forwarded Message ----------

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 30 Jun 2018 21:06:35 +0200

I seem to remember that someone actually uses this... for double 
bounces? From: ""@[] or an address target like that.

Qmail, perhaps, 
but I am fairly sure I have seen two users.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jun 2018 15:29:35 -0400

--On Saturday, June 30, 2018 21:06 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> I seem to remember that someone actually uses this... for
> double bounces? From: ""@[] or an address target like that.
> 
> Qmail, perhaps, but I am fairly sure I have seen two users.

Strikes me today as terminally ugly; what I can't remember is
whether we decided to allow it.  It wouldn't be the only thing
that Qmail does that we decided to continue to disallow.  Put
differently, I personally think allowing this is dumb and
looking for trouble, but it is not clear that it is an error
rather than an intentional decision.

If we did decide to allow this, it goes back to 2821 and DRUMS,
which has

      Quoted-string = DQUOTE *qcontent DQUOTE

qcontent is defined for 2821 in 2822 with (order reversed for
convenience)

  qcontent  =       qtext / quoted-pair

  qtext  = NO-WS-CTL /    ; Non white space controls

            %d33 /        ; The rest of the US-ASCII
            %d35-91 /     ;  characters not including "\"
            %d93-126      ;  or the quote character

NO-WS-CTL = %d1-8 /       ; US-ASCII control characters
            %d11 /        ;  that do not include the
            %d12 /        ;  carriage return, line feed,
            %d14-31 /     ;  and white space characters
            %d127

So I think 2821 allows 
     ""@Domain   
too.

Anyone else remember?

    john

---

From: Steve Atkins <[email-masked]>
Date: Sat, 30 Jun 2018 12:33:30 -0700

> On Jun 30, 2018, at 12:06 PM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> I seem to remember that someone actually uses this... for double bounces? From: ""@[] or an address target like that.
> 

#@[], I think. But it's only used internally to qmail, not over SMTP, so it's (thankfully) outside our scope.

Cheers,
  Steve

---

From: "John Levine" <[email-masked]>
Date: 30 Jun 2018 14:38:55 -0500

>bounces? From: ""@[] or an address target like that.

Qmail uses addresses like that internally but they are not supposed to
go out on the wire.

The erratum looks right to me, but it is a little disconcerting that
it took 18 years for anyone to notice.  The 5321 text is the same as
in 2821.

R's,
John

---

From: Phil Pennock <[email-masked]>
Date: Sat, 30 Jun 2018 15:44:31 -0400

> was a reason it was done the way it was or if that was just a

Somewhere around 2000/2001, the ISP I worked at updated mail-systems and
indirectly enforced the suggested change.

It led to a customer complaint, from someone actually using
<""@customername.isp.example> (I think mostly for USENET posting)
because spam harvesting software never could handle it, but everyone
that customer cared to correspond with had compliant software which
could.

We fixed our systems.

RFC 2821 allows empty content, so 5321 is not a regression against its
predecessor.

Looking at 821, I don't see how empty content would be allowed there.  I
don't recall the standards discussion at the time, or if it was after
2821 had been published.  The ISP had by then supported ""@ for the
previous few years and failing to do so was a regression.

I suspect the population size using this "feature" of SMTP is small and
if it's considered an undue burden then there might be an argument for
cutting them off.  But it would break stuff known to work and be in use
now.

% exim -bt '""@spodhuis.org'
[email-masked]
    <-- ""@spodhuis.org
  router = imap_user, transport = imap_inject

(I did one s/usercode/censored/ there, just to avoid having spam
 harvesters skew the numbers for that rarely-used mailbox).
(I don't consider this "in use" for me, it exists in my system to be
 able to check it still works and to prove a point; the customer
 complaining was, back then, actively using it).

> Original Text

-Phil

---

From: Ned Freed <[email-masked]>
Date: Sat, 30 Jun 2018 13:20:37 -0700 (PDT)

> was a reason it was done the way it was or if that was just a

It was done this way to align it with RFC 822/RFC 5322. More below.

> surrounding quotation marks.

It is not, however, a departure from RFC 822, which defines quoted-string 
as:

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                 ;   quoted chars.

or RFC 5322, which defines it as:

quoted-string   =   [CFWS]
                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                       [CFWS]

Now, I don't particularly care whether or not this particular construct is
allowed. What I do care about is that what's in RFC 5321 be consistent with
what's in RFC 5322. Inconsistencies between these specifications should be
avoided whenever possible, as they can cause operational problems when
some uses a construct allowed by one but not the other.

I also note that since this change was one to align the specifications,
it cannot be claimed to simply be an editing error that can be changed
by an erratum.

> Instructions:

IMO this erratum should be rejected.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jun 2018 17:17:10 -0400

--On Saturday, June 30, 2018 13:20 -0700 Ned Freed
<[email-masked]> wrote:

>...
> Now, I don't particularly care whether or not this particular
> construct is allowed. What I do care about is that what's in
> RFC 5321 be consistent with what's in RFC 5322.
> Inconsistencies between these specifications should be avoided
> whenever possible, as they can cause operational problems when
> I also note that since this change was one to align the
> specifications, it cannot be claimed to simply be an editing
> error that can be changed by an erratum.
> 
>> Instructions:
>> -------------
>> please use "Reply All" to discuss whether it should be
>> verified or rejected. When a decision is reached, the
>> verifying party can log in to change the status and edit the
>> report, if necessary.
> 

I think that is the information I needed (and had long ago
forgotten).

See response to the Errata System just posted to the list.   If
anyone violently objects to that formulation and those
suggestions, say so.

thanks,
    john

---

From: S Moonesamy <[email-masked]>
Date: Sat, 30 Jun 2018 14:42:21 -0700

Hi John,
>was a reason it was done the way it was or if that was just a

The argument when the ABNF was discussed was: "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" [1].  The issue is interlinked with "Quoted-string" in 
what was the RFC 2822 update.

Regards,
S. Moonesamy

1. Please see Section 2.4 of RFC 5321

---

From: Ned Freed <[email-masked]>
Date: Sat, 30 Jun 2018 13:34:03 -0700 (PDT)

> cutting them off.

Maybe, maybe not. I'm not really comfortable with making assumptions about
usage based on the experiences of those who happen to particpate in the IETF.

> But it would break stuff known to work and be in use now.

Exactly.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jun 2018 19:04:08 -0400

--On Saturday, June 30, 2018 13:34 -0700 Ned Freed
<[email-masked]> wrote:

>> I suspect the population size using this "feature" of SMTP is
>> small and if it's considered an undue burden then there might
>> be an argument for cutting them off.
> 
> Maybe, maybe not. I'm not really comfortable with making
> assumptions about usage based on the experiences of those who
> happen to particpate in the IETF.
> 

Again, I think there are two questions here.   The first is
whether this should be accepted as a erratum.  I think the
answer to that is fairly clearly "no" (and becoming more clear).
Even if there weren't strong feelings that the current syntax
was a deliberate decision, declaring it an error in 5321 would
break the consistency between 5321 and 5322.  

The second is whether the rule should be changed for both specs.
I don't know the answer to that, but the way to pose the
question is with an I-D that reasons through the advantages and
disadvantages of the change and makes a suggestion.   I share
both of your concerns about about assumptions and things that
are known to work, but don't feel a need to worry about it until
and unless we see such an I-D.

Personally, I think that there were cases where we should have
synchronized 5321 and 5322 by relying on the narrower rules of
the 821ff chain rather than those of the Header specs.  However,
I was in the rough about that in DRUMS and there would be no way
to simply revisit those decisions even if we wanted to (and I
don't think anyone does).

   john