Ansgar <ans...@debian.org> writes:
> There is an updated version (RFC 5322) that should be used instead.
> Notably RFC 5322 is more restrictive on the local part (whitespace and
> escape sequences are no longer allowed except as obsolete syntax).
> Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in
> local parts (and other places). That should probably be allowed as
> well.
> So, Policy should probably:
> - Refer to RFC 5322.
> - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax").
> - Allow the extensions from RFC 6532.
I agree with this as a general direction. I think we could probably just
make the first and third changes without much trouble; my recollection
that not much was dropped between RFC 822 and RFC 5322 and the stuff that
was is highly, highly unlikely to be in use.
We're also quite safe in dropping the obsolete syntax in RFC 5322. No one
is using source routing in email any more (I don't think it's worked on a
running mail system in decades), and I very much doubt anyone is using
CFWS in debian/control files in that way. The only time I used to see
that was with people mangling addresses for dubious spam protection, which
we don't allow in Debian anyway. I understand Bill's concern, but I'm not
worried about it here; the obsolete constructs are quite obsolete.
So, wording implementing the above three points is welcome.
As for your follow-up message to this bug, for better or worse Debian
pretty strongly assumes the "Full Name <email@address>" syntax and I'm not
sure we should expect people to allow the full RFC 5322 syntax. In
particular, you suggested name-addr, which is:
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
but we absolutely do not support CFWS (for those not familiar with RFC
5322, this is comment folding whitespace), only FWS.
display-name has a more obscure problem, which is that it allows quoted
strings, but I'm fairly sure that Debian software would break if we tried
to allow all the things that RFC 5322 allows inside quoted strings, and we
also would prefer people not use quotes if they're avoidable because not
all of our software deal with them correctly (and they're usually
unnecessary). The main exception is if a person's name contains a comma,
which we deal with quite poorly and which we probably should fix, and
allowing quotes in that case is probably the right fix, but it's also
probably a difficult fix for a lot of deb822 parsers.
In other words, I'm in general on board with aligning with the latest
email standards, but I don't want to take that so far as to allow
unnecessary and rather baroque constructs we don't currently permit in
practice just because they're allowed in email headers. We should go
stricter if anything, not more lenient. Similarly for Uploaders, in
practice it should be a comma-separated list of the same syntax as
Maintainer, and we don't want to use constructs that introduce the
possibility of comments.
We certainly don't want to support groups, which we've never allowed and
which are quite obscure even in RFC 5322. For those who have never seen
them, a group looks like:
Some Name:r...@debian.org,ea...@eyrie.org;
This has been formally supported in email since the beginning even though
essentially no one ever uses it. About the only time you ever see a group
in practice is the empty group in:
Undisclosed Recipients:;
which shows up from time to time.
There is some definite merit to using the ABNF productions in RFC 5322,
but it's tricky to do because RFC 5322 allows comments almost everywhere,
and we allow comments basically only in display-name (and in display-name
don't even treat it as a comment, but instead as part of the person's
name).
So, in short, definitely open to patches here, and I agree that the
current Policy specification for Maintainer is both underspecified and
somewhat obsolete, but I think the patches should be conservative and not
introduce the stuff that RFC 5322 allows in headers but that we currently
don't support.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
