Hello, I have been lurking here around for a while and we have been working at M3AAWG for some time as well.
Today’s DMARC is breaking more and more email as it gets more widely and often overly strictly deployed. I feel the major issue with DMARC is email forwarding in it’s many forms, in addition to mailing list issues. It would be preferable to try to do something that helps email survive as an open platform instead of bad workarounds. Transactional and person-to-person emails also should work reliably with DMARC (and similar things) when forwarded i.e. indirect delivery. In M3AAWG discussions, we have identified many stakeholders who are seeing major issues with DMARC and SPF when forwarding email for various valid reasons, examples: a) ISPs hosting user domains and email from to addresses in those domains is forwarded to external mailbox addresses. This is very common for smaller organizations. b) Alumni and organization member addresses like alumni.harvard.edu, acm.org, iki.fi and many others that provide a “permanent” email address and forward email to user-specified mailbox provider addresses. c) Users forwarding email themselves to another email address e.g. based on rules or forwarding to their mobile device address, or forwarding old ISP email to new ISP, etc. d) Some mailing lists and smaller email distributions, too, which work just forward messages as they are to their members. e) and of course the many users using these services, and senders trying to send to them. So there may be many more stakeholders with DMARC issues than one might initially think about. DMARC is creating a lot of “the message did not get thru” issues for valid and real emails these days. To be worth pushing further, DMARC needs to be compatible with with email forwarding i.e. indirect mail flows. To try to clarify my thinking around this, I tried to put some thoughts into a practical proposal format so it would be easier to consider, comment and discuss and think about the practicalities around it. Based on the discussion, it seems it might be more practical to try to make “small” improvements into DMARC. If we can find some useful way forward, we’re willing to work on an internet-draft for more formal commenting. Background, in addition to the use cases above: Because SPF fails with forwarded/indirect emails, and as DMARC today depends on SPF, it also fails in these use cases, especially when deployed overly strictly. Normal email forwarding does not break DKIM as the messages are not changed. We have new tools available today that can help, specifically ARC. We should aim to make DMARC compatible with these forwarding use cases, without losing the anti-abuse aims if possible. Draft proposal for comments: When a DMARC recipient MTA is processing an incoming message, 1) If DKIM is valid, SPF results should be ignored. DKIM already proves the message is from the source it claims to be from, it doesn’t matter if it arrived via an indirect path. 2) If DKIM is not used, but ARC is used, SPF processing should walk the ARC header chain as long as they have acceptable reputation and if a matching IP address is found there, consider the SPF check successful. 3) If DKIM and ARC are not used and SPF/DMARC fails, you could act as today, or probably we should recommend always putting failing messages somewhere where the user can search for the “lost messages” when needed, e.g. to the junk mailbox or quarantine. If something like this was in place, forwarders and others would be highly motivated to implement ARC, helping senders and recipients who want to deploy DMARC or DMARC-like solutions. ARC reputation: ARC reputation has been discussed a lot and may be a major roadblock in going this way. I think the situation has changed now as DMARC issues become larger and affect more users, so people are more ready to do something about it now. * Technically we should be able to simply use DNS-based IP allowlists to get reputation information for the ARC signing intermediaries. * ARC allowlisting would allows MTA admins to choose suitable allowlists from free and paid options from various sources and vendors, just like they use blocklists today for email already. * We could probably even re-use existing email RBL allow/blocklists for this purpose, if you don’t trust some IP reputation as sender, you would not trust it for ARC either. * Free options would be available so DMARC2 software and solutions could include default settings that already work out of the box for smaller organizations. * It seems possible to maintain semi-manual lists of “major trusted” forwarding services and have a suitable vetting process for that. At iki.fi we have looked at doing something like this, if it would help. * Additionally people would offer various automated lists based on other analysis and methods. * ARC reputation could at this time have become an additional service for email protection vendors to sell. Maybe before this was not viable earlier because ARC was not widely available yet, or the SPF/DMARC issue was not severe enough before? * Mailbox service admins could add “trusted forwarding IPs” locally to help specific users with forwarding related issues. Today there doesn’t seem to be an easy options for mailbox service providers to help their users who have SPF/DMARC issues. Yours, Hannu -- Hannu Aronsson h...@iki.fi > Dave Crocker <d...@dcrocker.net> wrote 8.8.2020 5.37: > I suspect the calculus is less in the pragmatic terms of asking how big this > threat is and more in terms of wishing for some version of protection and > thinking this helps to achieve it. > > The degree to which so many folk embrace does not appear to have that much > empirical basis, but rather a sense of feeling a need to do something and at > first blush this seems to be something.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
