[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51733: 27.1; Detect impossible email addresses better
From: |
Eli Zaretskii |
Subject: |
bug#51733: 27.1; Detect impossible email addresses better |
Date: |
Wed, 19 Jan 2022 15:35:58 +0200 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 51733@debbugs.gnu.org
> Date: Wed, 19 Jan 2022 14:31:11 +0100
>
> Eli Zaretskii <eliz@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.
- bug#51733: 27.1; Detect impossible email addresses better, (continued)
- bug#51733: 27.1; Detect impossible email addresses better, Robert Pluim, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better,
Eli Zaretskii <=
- bug#51733: 27.1; Detect impossible email addresses better, Andreas Schwab, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Andreas Schwab, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Andreas Schwab, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Andreas Schwab, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/19
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/18