5.6.2 Maintainer currently states:

+---
| The package maintainer’s name and email address. The name must come
| first, then the email address inside angle brackets <> (in RFC822
| format).
|
| If the maintainer’s name contains a full stop then the whole field
| will not work directly as an email address due to a misfeature in the
| syntax specified in RFC822
+---

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.

Ansgar

Hello Ansgar,

Are there packages actually using the obsolete syntax ? Can this be
checked by Lintian ?

Cheers,

Maybe Policy should also refer to either `mailbox` or `name-addr` for
the Maintainer field (`name-addr` requires angle brackets `<>`) and
either `mailbox-list`, `address-list`, or even `group-list` (would also
allow groups) for Uploaders.

`mailbox` allows plain address (without angle brackets `<>`); the
display-name is optional in `name-addr` as well, so that might be a
small change, but one could require it to be non-empty.

That is a small change for Uploaders as it would allow bare addresses.
Currently Uploaders would be something like

  name-addr-list = name-addr *("," name-addr)

which doesn't exist in RFC 5322.

Personally I would probably just make Maintainer a `name-addr` and
Uploaders either `mailbox-list` (most restrictive) or `group-list`
(most permissive).  Debian-specific constructs should probably be
avoided.

Ansgar

Not checked yet. Stuff probably breaks with whitespace in local parts.

Lintian uses Email::Address::XS.  That seems to allow Unicode (allowed
by RFC 6532, but not by RFC 822), but also doesn't flag obsolete syntax
(whitespace).  It accepts the address `käse <"kä se"@example.com>`:

perl -mEmail::Address::XS -E '
  my $x = Email::Address::XS->parse(q{käse <"kä se"@example.com>});
  say $x->is_valid();
'

So it is more generous than Policy either way.

Ansgar

Sure. But a lintian test for this is probably required if we are going
to add it to policy.

Cheers,

Ansgar <ansgar@debian.org> writes:

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:rra@debian.org,eagle@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.