Re: [dmarc-ietf] ARC usage, was Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Jesse Thompson <[e-mail]>]

On 10/6/20 10:20 AM, John Levine wrote:
> In article <[e-mail]> you write:
>> It would be much better if there were a few professional/community efforts to build reliable and complete lists of good
>> and bad ARC intermediaries, like for spam.
> 
> Having tried and failed to build a whitelist for Spamhaus, I can tell
> you that it's hopeless.
> 
> The bar for ARC to be usable is pretty low. It's not "doesn't send
> spam" or even "knows who its users are." It's only "doesn't lie about
> where mail came from."  I expect that in practice the usual DNSBLs
> will be good enough.

Is the assumption with ARC, when it reaches some point of "production" status, that intermediaries will be able to look themselves up in the usual DNSBLs to see if they are trusted so they know that they don't need to rewrite the From?  Sorry, that's going down the rabbit hole...

I only brought up ARC as one example of local policy overrides that an ISP-hosted receiver might want to have mechanics to control.  Even with ARC being adequately managed by the usual DNSBLs, I could imagine that I would want to have some control over the edge cases.

Surely there are other examples...

* This is probably the most common one, based on personal experience: Allowing a 3rd party to send inbound mail to your organization "From" your own domain, but not allowing that 3rd party to use your domain to send outside of your organization (hence, not authorized by DMARC).  Ideally I would want a solution that keys off of multiple signals (SPF result, DKIM result, DKIM domain/selector, etc) rather than something crude, like "trust all mail from these IPs".

Again, my larger point is that if we want "filtering signal" to be the primary value-add for DMARC, then I'm suggesting that we may need to ensure that receivers actually have the ability to invent filtering signal mechanics in order to be "using DMARC".  If the receiver's ISP is preventing that, then perhaps there needs to be a way for ISPs' customers' to measure their ISP's DMARC capabilities/maturity in this regard.

> I am told that Office365 allows clients to place their own email filter in front of the one provided by Microsoft.  I don't know whether that solves the black box problem that Jesse raises. 

Yes, this is what we do, but it's not common.  Microsoft occasionally tries to convince us to point MX at them, and I sympathize with their motivation to put all of their customers in a consistent configuration.  On the other hand, there are some local policy mechanics that we currently rely on which they don't provide.

Jesse