Mailing List Archive

Unquoted spaces in 821 local-part
My reading of RFC 821 says that the following command is illegal:
rcpt to:<s. j. sudish@mindspring.com>

Here're the relevant quotes from the 821 grammar with comments between
brackets:

<forward-path> ::= <path>
<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"

[. an a-d-l must be followed by ":", so we can ignore that for the
above example ]

<mailbox> ::= <local-part> "@" <domain>
<local-part> ::= <dot-string> | <quoted-string>

[. a quoted-string must be surrounded by double quotes, so we can
ignore that ]

<dot-string> ::= <string> | <string> "." <dot-string>
<string> ::= <char> | <char> <string>
<char> ::= <c> | "\" <x>

[. so, every part of the local-path in this derivation is a <c>, since
we have no "\"'s ]

<c> ::= any one of the 128 ASCII characters, but not any
<special> or <SP>
Re: Unquoted spaces in 821 local-part [ In reply to ]
> My reading of RFC 821 says that the following command is illegal:
> rcpt to:<s. j. sudish@mindspring.com>

Yes, but for no good reason. This is accepted (and handled correctly)
by sendmail and PP, as well as qmail. Only a perverse implementation
would go out of its way to reject this.

Unfortunately, the grammar in RFC 821 contains a number of errors. This
command is also illegal, according to that grammar.

rcpt to:<user@somewhere.co.uk>

Tim.
Re: Unquoted spaces in 821 local-part [ In reply to ]
Tim Goodwin writes:
> Yes, but for no good reason. This is accepted (and handled correctly)
> by sendmail and PP, as well as qmail.

Depends on what you mean by correctly. If you mean that all three are
lenient when given bogus input, yes. If you mean that they're only
accepting addresses allowed by the spec., no.

While 821 contains errors, errors being defined as "conflicting
specification/examples", there is no conflict in this case in the
document that I can see. Quoted spaces are allowed, unquoted spaces
aren't. Please clarify what you mean by "correctly".

> Unfortunately, the grammar in RFC 821 contains a number of errors. This
> command is also illegal, according to that grammar.

> rcpt to:<user@somewhere.co.uk>

I must be missing something, for that command is derivable in a
straightforward manner from the grammar and the case-insensitivity
requirement (once you add the trailing CRLF, of course; but I doubt
you meant that particular nitpick). Elaborate, please.

-Sudish
Re: Unquoted spaces in 821 local-part [ In reply to ]
Sudish Joseph writes:
>> rcpt to:<user@somewhere.co.uk>

> I must be missing something, for that command is derivable in a
> straightforward manner from the grammar and the case-insensitivity
> requirement (once you add the trailing CRLF, of course; but I doubt
> you meant that particular nitpick). Elaborate, please.

Ah, the definition of <name> is rather overeager, leading to a bogus 3
letter requirement on domain components, never mind.

Note that this is quite different from my example, for the simple
reason that the standard contradicts itself in this case. See section
3.7, "Domains":

821> For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
821> "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.

There's a two letter <name> in the second example.


However, the existence of that or other inconsistencies is still no
reason to allow syntax that's _explicitly_ prohibited. Once again,
I'll repeat that there's another, perfectly legal, way to pass spaces
around in the envelope.

-Sudish
Re: Unquoted spaces in 821 local-part [ In reply to ]
[ rcpt to:<fred smith@somewhere.com> ]
> > Yes, but for no good reason. This is accepted (and handled correctly)
> > by sendmail and PP, as well as qmail.
>
> Depends on what you mean by correctly. If you mean that all three are
> lenient when given bogus input, yes.

That's what I meant by "accepted". By "correctly" I meant that they
apply the obvious (really, the only) interpretation, then proceed to
quote correctly when they relay the address.

> However, the existence of that or other inconsistencies is still no
> reason to allow syntax that's _explicitly_ prohibited.

Yes, but that's a prohibition on the client, to which qmail conforms.
The standard doesn't (can't) say what a server must do when it finds
it's dealing with a non-conformant client: the server implementor must
choose whether to reject the bad protocol, or try to interpret it.

In most cases, qmail rejects, with good reason. If you've been reading
this list for a while, you'll have seen my fulminations against MTAs
like sendmail and PP for accepting such things as missing brackets
around SMTP addresses, and LF.LF as an end of message indicator. In
these cases, the "lenient" behaviour introduces ambiguities and requires
extra code to implement whatever heuristics of interpretation the
implementor decides on.

But in this case, it would require extra code even to detect the out of
protocol behaviour. Why bother?

Tim.
Re: Unquoted spaces in 821 local-part [ In reply to ]
Tim Goodwin writes:
> But in this case, it would require extra code even to detect the out of
> protocol behaviour. Why bother?

Coz it's incorrect? What useful behaviour does it serve? Which
clients might have a legitimate use for this bug (i find it difficult
to call it a feature)? qmail already returns 553's on what it thinks
is broken syntax. Why should this be any different?

Also coz it clashes horribly with sendmail's (horribly broken) command line
recipient list handling. For instance,
sendmail 's. j. sudish@mindspring.com'
will see three separate recipients, never mind that it's one argument.

It'll bounce two and deliver one (sudish@ is a valid maildrop). qmail
when given that in a .qmail file will generate _one_ bounce message.
Totalling up the damages, we have: one recipient; sendmail saw three
and bounced two/delivered one, qmail saw one and thought sendmail
bounced it.

This is purely because of the unquoted spaces ("s. j. sudish"@ would
bounce correctly). Arguing whether it's sendmail or qmail that's
broken here is silly (I think both are, FWIW)--Dan doesn't seem to be
interested.

Maybe I should check every address qmail hands me to see if it really
contains 821-valid envelope addresses? Yeah, that'd be fun to write.

Not.

Hmm, Dan, is your address parsing library going to allow junk like the
above? Will it have separate 821 and 822 modes?

-Sudish