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

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

The unifying principle is that we need a third-party authentication method, a need which is not adequately satisfied with SPF and DKIM.   The standard can support multiple options, such as the following

send3="method=ATPS,p=reject,sp=quarantine;  method=reputation,p=quarantine,dns=uri; method=RHSWL, sp=reject"

where:
"method=ATPS" means RFC 6541 third-party signatures, as suggested by Hector"method=reputation" means a trust service like trusted-forwarders.org, as suggested by John"method=RHSWL" means the whitelist system suggested by Alessandro
Usage:
If multiple methods are specified, the receiver checks all of the methods that it is willing and able to use.If p= is missing, the third-party authentication method is not supported for primary domains.If sp= is missing, the third-party verification method is not supported for subdomainsIf any method passes, the message passes.   No other checks need to be performed.   If all methods fail, the strictest policy is the recommendation action.If any third-party authorization method is supported, the DMARC policies should be p=none and sp=none, to avoid false positives by entities that do not know how to check the third-party method.
A domain could optionally advertise which third-party methods it is willing to check using a similar keyword structure:
verify3="method ATPS;  method=reputation; dns=uri; method=RHSWL".  
This would allow senders to limit third-party impersonation to those recipients that will accept the impersonation as legitimate.

It would be desirable for DMARC feedback reports to indicate which third-party methods were checked.   Updating the reporting specification might be more complex than specifying the verification method itself.

Do we move forward with an approach like this?

----------------------------------------
From: Alessandro Vesely <[e-mail]>
Sent: 8/8/20 5:52 AM
To: [e-mail]
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 2020-08-08 4:27 a.m., John Levine wrote:
>
> Some years back people kept asking Spamhaus to set up a whitelist, so
> they hired me to do it. Technically it worked fine, but it soon became
> apparent that the only people who were interested weren't people who
> we'd want to whitelist. The good quality senders get their mail
> delivered already, the terrible ones didn't bother, and all we heard
> from were people who sometimes sent some spam along with the good mail
> but assured us they were nice people.

I'm not clear why that failed. Personally, I was puzzled by the .com
suffix, which somehow sounded like pay for being whitelisted.

> I think you'll find that all of the existing whitelist like things
> are a sideshow to the company's real business of deliverability
> consulting.

Of course whitelisting can easily become ESPs combat zone.

> For DMARC, it would be nice if there were a shared list of credible
> forwarders, not to automatically accept their mail, but just to say
> they're good enough that you can believe what's in their ARC seals
> when you're doing the usual spam filtering.

Trusted-forwarder.org still exists...[*]

Automatically accept is not the same as override DMARC policy. The
latter can cure some of MLM and non-MLM problems.

I proposed snd=rhswl.zone.example. The difference w.r.t.
trusted-forwarder.org is that some sites can start building their own
right hand side whitelists (RHSWL). Specifying the zone in the
protocol makes it visible, so lazy admins can help themselves to
quickly build their not-so-strict DMARC policy by using someone else's
RHSWL.

Combining lists could also become possible, once there is a decent
amount of them. There is already An Architecture for Reputation
Reporting, RFC 7070/3, which could support exchanging entries among
similarly scoped RHSWLs.

> You can't just let people sign themselves up for a list like that,
> since every dodgy bulk mailer will figure this will get them an
> extra 2% delivery, and we've never gotten past a vague hope that we
> could canvass people we know to make a combined set of mailing
> lists hosts we know.

Seeking how to make that hope less vague should be a highly commended
task.

Best
Ale
--

[*] http://multirbl.valli.org/detail/wl.trusted-forwarder.org.html

_______________________________________________
dmarc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmarc