On 10/6/20 10:20 AM, John Levine wrote:
> In article <1265372281.9984.1601969016...@appsuite-gw1.open-xchange.com> 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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
