Andrey Rahmatullin writes ("Re: Comma in Maintainer field"):
> On Fri, Apr 20, 2018 at 04:24:59PM -0700, Russ Allbery wrote:
> > I'd be more comfortable with this (well, RFC 5322 at this point), since
> > this removes a lot of the insanity. However, note that this is
> > incompatible with existing Maintainer fields: RFC 5322 requires that . be
> > quoted. So any Maintainer field containing an unquoted period would have
> > to change.
>
> Note that the Policy says:
>
> 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; a program using this field as an address must check
> for this and correct the problem if necessary (for example by putting the
> name in round brackets and moving it to the end, and bringing the email
> address forward).
I think this is not really desirable. It would be much better to make
the syntax a subset of 5322, at least.
> > RFC 5322 also prohibits non-ASCII characters, which would have to be
> > encoded in RFC 2047 encoding.
>
> Yeah, we don't want this.
Luckily there is an established transformation for encoding non-ascii
in 5322 headers. But TBH I'm not sure what /usr/sbin/sendmail does
with un-encoded UTF-8 in To. Ideally, at least when invoked in
"submission" mode, it would encode it.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
