Subject: Re: [ietf-smtp] Discussion about draft-benecke-cfbl-address-header

From: "John Levine" <[email-masked]>
Date: 14 Jan 2022 21:22:54 -0500

[ redirected from the dispatch list ]

>>I want to introduce you my email-related draft "Complaint Feedback Loop
>>Address Header" which can be found @
>>https://datatracker.ietf.org/doc/draft-benecke-cfbl-address-header/.
>>The intention of this draft is to have documented, standardized and
>>automated way to provide a so called complaint feedback loop address to
>>mailbox providers.
>>Currently, providing and maintaining such an address is a manual and
>>time-consuming process for both sides, email senders and mailbox providers.
>>This draft defines the required header, how the header needs to be
>>processed and signed by DKIM.

Technically the proposal is fine.  In practice I have my doubts whether
this would get enough interest from mailbox providers to be worth
the effort.  To oversimplify, the bulk senders say "please please tell
us who our bad customers are" and the mailbox providers say "why should
we help you listwash your spam lists?"

This is why I said in another messsage that this is a topic for
M3AAWG.  Maybe they'd be interested if there were some sort of way to figure
out who is likely to be a good quality ESP trying to manage their customers
and who just wants to listwash complainers.

R's,
John

---

From: Jan-Philipp Benecke <[email-masked]>
Date: Sat, 15 Jan 2022 06:20:52 +0100

Hi John. Thanks for your feedback.
We're currently not belonging to the M3AAWG, we may working on this
later the year.

I would be more than happy if you could introduce this to the M3AAWG.

Best,
Jan-Philipp

Am 15.01.22 um 00:43 schrieb John Levine:
> Hi.  The ietf-smtp list is the right place to discuss mail extensions.
> I'm sending replies there and will send some more substantive comments.
>
> But before that, do you belong to M3AAWG? That's where the people who
> you would want to implement this are. The one-click unsubscribe
> originated in M3AAWG discussions, so by the time it got to the IETF,
> we knew that mail providers would likely implement it. I can make
> introductions if you'd like.
>
> Regards,
> John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
>
>
> It appears that Jan-Philipp Benecke <[email-masked]> said:
>> Hey dispatch wg!
>>
>> First of all, I would like to introduce myself briefly:
>> My name is Jan-Philipp Benecke, i work as a Deliverability & Software
>> Engineer at CleverReach GmbH & Co.KG.
>> We're a email marketing provider offering a software-as-a-service for
>> sending email campaigns and transactional mails.
>> This is my first IETF related work, so i'm a newbie when coming to this :)
>>
>> Now i want to kick off a discussion around the draft and collect
>> feedback. This draft has already been presented to the ISE, Adrian
>> advised me to introduce the draft to this wg for further review and
>> discussion.
>>
>> There has been already a heavy discussion while writing within the
>> Certified Senders Alliance (https://certified-senders.eu/), which is an
>> association of mailbox providers and senders.
>> The conclusion of this discussion was that a larger majority is
>> interested in such an automated path.
>> For example, 1&1 Mail & Media, the company behind web.de/gmx.de/mail.com
>> (major mailbox provider in Germany), is very interested in this draft
>> and would be happy to have this.
>> The same feedback i already got from some email senders i'm in contact with.
>>
>> I look forward to hear your feedback about this draft.
>>
>> Best,
>> Jan-Philipp

---

From: Jan-Philipp Benecke <[email-masked]>
Date: Sat, 15 Jan 2022 06:20:52 +0100

Best,
Jan-Philipp

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Jan 2022 19:52:14 +0100

>>>automated way to provide a so called complaint feedback loop address to

I'd be curious about some details of that I-D.

For one, why do all the exemplified DKIM signatures sign the Content-Type?  It 
is not among the recommended fields of Section 5.4.1 of RFC6376, unless using l=.

It is not clear how to obtain the double DKIM signature.  Since the examples 
show no selectors, it is unclear if super-saas-mailer publishes various keys, 
one for each authorized sender.

The practice to redact information could be mentioned.

Why shouldn't messages automatically filtered to the Junk folder be reported? 
Isn't it interesting?

Best
Ale
--

---

From: Jan-Philipp Benecke <[email-masked]>
Date: Thu, 20 Jan 2022 13:42:43 +0100

Thanks for looking into the I-D and your comments.

Am 19.01.22 um 19:52 schrieb Alessandro Vesely:
> For one, why do all the exemplified DKIM signatures sign the
> Content-Type?  It is not among the recommended fields of Section 5.4.1
> of RFC6376, unless using l=.
This is indeed wrong. There is no specific reason for it, i've just
copied a bad example. Will be fixed with the next revision.

> It is not clear how to obtain the double DKIM signature.  Since the
> examples show no selectors, it is unclear if super-saas-mailer
> publishes various keys, one for each authorized sender.
Will be fixed also with the next revision.

> The practice to redact information could be mentioned.
Could you give me a little more detail on what you expect here?
Do you mean the general existing practice to redact information?

> Why shouldn't messages automatically filtered to the Junk folder be
> reported? Isn't it interesting?

Good point, the information about automatic filtering is of course
interesting as well.
The more i think about it, the more i think that this decision should be
made by the mailbox provider and not by the I-D.

Best,
Jan-Philipp

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 22 Jan 2022 13:06:22 +0100

> Do you mean the general existing practice to redact information?

J.D. Falk recommends to redact the recipient email address throughout RFC 6449. 
  Since you cite that, you could as well cite RFC 6590.

> made by the mailbox provider and not by the I-D.

The I-D can provide a means to express that decision.

Best
Ale
--

---

From: Jan-Philipp Benecke <[email-masked]>
Date: Thu, 27 Jan 2022 10:09:41 +0100

... saw that i've sent the reply just to Ale.

Thanks for the explanation. I'm going to cite RFC 6590 with the next
revision.

Am 22.01.22 um 13:06 schrieb Alessandro Vesely:
> J.D. Falk recommends to redact the recipient email address throughout
> RFC 6449.  Since you cite that, you could as well cite RFC 6590.
>
>