Re: [Ietf-message-headers] Provisional Registration for "Wrong-Recipient" mail header

[David Weekly <[e-mail]>]

Simon,

It's a fair point -- and one that applies to List-Unsubscribe (RFC 8058) as
well. If a spammer sends you an email for which you then unsubscribe they
are aware that the email address is valid. The same is true here, so this
suggests we should use similar language.

To wit, if I were to plagiarize the following from RFC8058, would that
address the concern?

   The Wrong-Sender operation provides a strong hint to the mailer that
   the address to which the message was sent was valid, and could in
   principle be used as a way to test whether an email address is valid.
   In practice, though, there are simpler ways such as embedding image
   links into the HTML of a message and seeing whether the recipient
   fetches the images.

Cheers,
 David E. Weekly (@dweekly)


On Wed, Jan 3, 2024 at 10:46 PM Simon Josefsson <[e-mail]> wrote:

> David Weekly <david=[e-mail]> writes:
>
> > Header field name: Wrong-Recipient
> > Protocol: mail
> > Status: provisional
> > Author: David Weekly <[e-mail]>
> > Specification:
> > https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/
> >
> > Current intent is to attempt to develop the above draft I-D into an RFC
> > with IETF, am just beginning that process.
> >
> > This is a "cousin" to List-Unsubscribe (RFC 4021) and
> List-Unsubscribe-Post
> > (RFC 8058) meant to allow an email reader to explicitly indicate they are
> > the wrong recipient of an email from a service.
> >
>
> Interesting.
>
> There should be discussion about the potential for security problems for
> a user if she follows the link in the header: the user will leak to the
> service that she has received and read the e-mail.  This design may lead
> to an attack where malicious sites sends e-mails with this header, and
> unsuspecting users will click the button to avoid future such e-mails,
> and the malicious site has learned that this is a valid e-mail address
> read by a human (with a modern e-mail client that supports this
> feature).
>
> The draft doesn't say what the client should do with the response from
> the POST.  Is this to be displayed in a browser?  Or merely as a
> background POST from the MUA?  Users would want some form of feedback
> after pressing that button.
>
> /Simon
>