Subject: Re: bug#51733: 27.1; Detect impossible email addresses better

From: Eli Zaretskii <[email-masked]>
Date: Wed, 19 Jan 2022 15:35:58 +0200

> From: Lars Ingebrigtsen <[email-masked]>
> Cc: [email-masked]
> Date: Wed, 19 Jan 2022 14:31:11 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > I'm not asking to _replace_ RFC2047 support, I'm saying that we should
> > also support email addresses that were already decoded, for the use
> > cases where that could be more convenient or where the wire level is
> > unavailable.
> 
> These already exist.  The applications can call *-name-suspicious-p
> (etc) individually, if they want to.

I don't have a NAME, I have a full email address.

> > Why would you object to extending these functions so that they could
> > support decoded email addresses?  What harm could that possibly do?
> 
> That's the point -- when doing DWIM parsing

I didn't say DWIM, you did.

> the function can't reliably
> say whether a string is a suspicious email address, because the attacker
> may construct a name part, that when decoded, confuses the address
> parser, and thereby escapes domain/local part checking.  (Think of
> various combinations of names that contain "@" and "," characters.)

When the wire format is gone, this is all I have left.  You are saying
we should leave this case without a solution.  So be it.