On Sat, 20 Oct 2007, Peter J. Holzer wrote:
On 2007-10-19 11:34:32 -0400, Charlie Brady wrote:
On Thu, 18 Oct 2007, David Nicol wrote:
FWIW, later on http://cr.yp.to/im/address.html Bernstein says
"Do not use an empty box part; it cannot appear in SMTP requests."
I think Bernstein is mistaken here. He should have written "it requires
quoting in mail headers and SMTP" like he did for many of the other
troublesome forms.
OK.
But qcontent is undefined.
That's intentional:
...
| routes as described in appendix C. Terminals not defined in this
| document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
| the "core" syntax [8 (section 6)] or in the message format syntax
| [32].
...
qcontent is defined in RFC 2822.
OK, thanks for pointing that out.
This seems to require that "" and empty must be treated equivalently, and
empty is clearly not valid.
I don't see that requirement. "All quoted forms" must be treated as
equivalent. That is probably intended to include non-quoted forms but I
don't think it is intended to include invalid forms.
OK.
The sending system should also use the empty
form, rather than quoting an empty string.
No. Clearly it cannot do this since the empty form is not valid. It
should use the minimum possible quoting, which in this case is "".
Maybe - but the "least quoted form" is no-quoting, in this case.
RFC2822 also makes it clear that "quoted-string is identical to atom,
semantically" so although ""@domain is syntactically permitted by RFC2822
(perhaps in error), it is not semantically valid.
I don't see that either. If that meant that a quoted string can only
contain the same characters as an atom, a quoted string would not be
necessary.
So how do you interpret "quoted-string is identical to atom,
semantically"?
The quoted string exists precicely because the for some uses
the syntax of the atom is too restrictive. I doubt they really intended
to allow empty local parts in email addresses, but other forms which
cannot be represented by atoms, like mail-addresses with embedded spaces
where almost certainly intentional.
OK.
(Personally, I find the RFC 822 mail address syntax ludicrously bizarre.
At least RFC 2822 marked some of it as obsolete, but there's still a lot
of wierd stuff left, like control characters in the local part).
OK.
So I'm guessing that you don't agree with the proposed code change to
check_badrcptto, to require $recipient->user. In that case, I can add by
own plugin:
use Qpsmtpd::DSN;
sub hook_rcpt {
my ($self, $transaction, $recipient, %param) = @_;
return Qpsmtpd::DSN->no_such_user("null mailbox not accepted")
unless $recipient->user;
}
or use:
^@ null mailbox not accepted
in config/badrcptto_patterns used by check_badrcptto_patterns.
I notice that check_badrcptto_patterns says:
qpsmtpd already ensures that the address contains an @, with something
to the left and right of the @.
which seems to be true, but may no longer be true after addresses are
converted to canonical form.
My other suggested patches to check_badrcptto still stand.
