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
Sent: 8/8/20 5:52 AM
To: dmarc@ietf.org
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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
