Re: [dmarc-ietf] non-mailing list use case for differing header domains

["Douglas E. Foster" <[e-mail]>]

Murray, I  have most recently used this link at AOL/Yahoo:  https://postmaster.verizonmedia.com/sender-request 

I have considered using the more complete "Complaint Feedback Loop", https://postmaster.verizonmedia.com/cfl-request  but have never completed the process.

Maybe they are the last to offer this type of feature.  Or maybe my memory is imagining things   Now that you have pressed me, I cannot remember whether I have had success with other services or not.

My heart is not in prior registration either, but I was trying to lay out the next-best alternative for those who want an alternative to using the MLM domain identity.    

The goal of DMARC is to end spoofing, which requires everyone to send using their own domain, even when performing a favor for someone in another domain.   A recipient domain owner has the right to define the rules for getting into its network.    Those who want into that network should play by the rules of that network, whether the rules are liked or disliked. 

An incoming email is a take-it-or-leave-it proposition for most recipients.   My domain does not have the market power to alter sender behavior.   When I receive a spoofed message that the recipient actually wants, I end up creating an exception to allow the spoof.   Spoofing senders are counting on their ability to force me to do that.   However, Microsoft is powerful enough to engage in a standoff.    Those who want to send to Microsoft destinations will need to not violate DMARC.   I hope and expect that they will win this battle.

DMARC is not new.   Products that have not become DMARC-aware are as obsolete as WindowsXP.   Unfortunately, that does include a lot of products.

Over a year ago, I was about to recommend Proofpoint as our new email filtering vendor.   But the next morning I realized that their secure email service will spoof the identity of non-clients when they respond to a message from a client.   I had a real problem with a vendor promoting their ability to enforce DMARC on incoming mail, while also violating DMARC on their secure email service.   Then I saw that Cisco Ironport did the same thing.   I raised CIRT issues with both vendors, but nothing has changed.   Maybe Microsoft will be able to change their attitudes.
DF

----------------------------------------
From: "Murray S. Kucherawy" <[e-mail]>
Sent: 8/7/20 7:16 PM
To: Doug Foster <[e-mail]>
Cc: Dave Crocker <[e-mail]>, IETF DMARC WG <[e-mail]>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster <[e-mail]> wrote:
Murray took server too literally.   I have expressed before that a system could do a sender authentication lookup on List-ID as easily as on From.   In this respect, it is similar to Dave's proposal, without the added complexity of additional identifiers.   So think "Registerd List-ID plus DKIM signature (or SPF, but DKIM seems both sufficient and preferable.)

If we take "server" to mean a tuple made up of a List-ID value and a "d=" value from a validated DKIM signature, which I believe is what you're saying here, the first occurrence of this necessarily has no internal value (or history) attached to it.  That means the operator has to develop meaning for it over time, which doesn't tell it how to handle the first N such messages.  Err on the side of openness and you have a spam or attack vector; err on the side of defense and you irritate your users by denying them some list traffic until a reputation can develop.

And it's probably actually a three-tuple, with the third part being the recipient.  Otherwise, I could register (or trigger the auto-registration of) any two-tuple I want and thus intentionally let in my preferred list streams, good or bad, which affects every other user.

Plus, you're trusting users to get this right.  For a manual registration scheme, every time they get it wrong by entering the wrong data or failing to even do it at all, you've got a failure mode to deal with, usually in the form of user complaints which require other humans to resolve.  That makes it relatively expensive.

And finally, lists change once in a while, maybe to a new signing domain, maybe to a new name, maybe both.  Every time that happens, the process has to start over.  Naturally lists won't want to do this because of the sterling reputations they've developed, but the pain reappears whenever the process needs to be repeated for whatever reason.

I'm not saying such a system can't or won't work.  I'm also not saying I have a better idea.  I am saying there's multi-faceted pain in every direction in this space, and this is no exception.  Whatever path we choose to deploy here has to account for those choices and their side effects, and the ways they might be gamed.

I am not sure what "Internet Scale" means to you.   Most of the major recipients have bulk mailer registration systems.   It does not guarantee whitelisting, but it tends to produce that effect.   I have had occasion to register with most of them.   So "does not scale" is not obvious to me.

"Internet Scale" means millions or billions of users, like GMail or Yahoo or AOL or Microsoft have.  Since they have the bulk of the inboxes, a solution needs to at least consider that size of use case, or explain why those cases don't need to be considered.

I've never seen this manual registration process to which you refer.  Where can I find it, for example, on GMail?

Even more to the point, check out this link:
https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto 

Verizon appears to be offering a service (probably for extra cost) which is based on:
(a) a well-defined mail stream from a known sender, and 
(b) a mailbox user identifying that mail stream as subscribed, and therefore desirable.

It appears that the target senders are retailers who want to ensure that their sale announcements are read before the sale is over.   It is an "Internet scale" application of the type of registration I was suggesting:   Well-identified senders, coupled with end-user endorsement, receive preferred treatment.

Is there a technical description someplace of the mechanism behind what they're doing?

As to the transparency question, it should be clear that there will be no simple solution to the ML problem.

Indeed.

[...] But the only way to establish an acceptable reputation is to either register with the receiver directly, or register with the sender in a way that the receiver will honor.

This needs to scale, from both ends:

1) If I as a new list operator want my list traffic to get accepted, how could I possibly go about registering with all (or even most) mailbox providers in a way they will trust?

2) If I as a mailbox provider want to give my users quality service and also spam filtering, what way can I offer list operators to identify themselves that can't be spoofed, and will only be exploited by good actors?  Putting this burden on my users doesn't feel tenable.

-MSK