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/>