GNU bug report logs - #51733
27.1; Detect impossible email addresses better

Previous Next

Full log

Message #275 received at 51733 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51733 <at> debbugs.gnu.org
Subject: Re: bug#51733: 27.1; Detect impossible email addresses better
Date: Wed, 19 Jan 2022 15:35:58 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 51733 <at> debbugs.gnu.org
> Date: Wed, 19 Jan 2022 14:31:11 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.