Hi! I keep reading the discussion and I am surprised how people express views that current DMARC standard does not work. I am surprised that technical people here express this view.
DMARC relies on SPF and DKIM. The latter is particularly important for the mailing lists to ensure that DMARC works. And when I read the cases it is clear that the issue is not of DMARC but of DKIM. RFC for DKIM says very clearly in the introductory part that and I quote "Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature." If this is not the case, the relay is actually violating DKIM standard. The lists we manage, we have made sure they follow the RFC and there is no issue of DKIM preservation. Some lists, however, have taken a different approach and to make sure we have delivery there also, we've looked at the elements which are used for DKIM calculation. We realise that not including the content into hash calculation can have a drawback but given that non-DKIM compliant lists do with content what they wish anyway, it's not much of a drawback. At the same time, prevention against spoofing and misuse is retained, which is the key for DMARC. Tonu t...@cert.ee On 09.08.2020 18:11, Hannu Aronsson wrote: > Hello, > > Quick correction: As DMARC requires only either DKIM or SPF which I had > confused, this removes the need for the proposal point 1). Thanks for the > off-list help received. > > This seems to be mostly an SPF issue, but still remains when > - SPF used used alone without DMARC (not sure if relevant for this > discussion, but it is a real-world problem) and > - DMARC when DKIM is not used and it falls back to SPF > causing indirect emails to fail, especially with p=reject or -all settings or > overly strict receiver deployments. > > For fixing the SPF issue a solution using ARC would be much preferable to the > SRS (Sender Rewriting Scheme) workaround, because e.g. the messages would be > unchanged, avoid problems with long email addresses or requiring databases, > and DMARC strict From alignment issues, etc. > > The other topics in the email, > - forwarding use cases from M3AAWG discussions and > - figuring out how we could get ARC reputation solution in place > are hopefully still interesting for this discussion. > > Yours, > Hannu > >> On 9.8.2020, at 13:28+0300, Hannu Aronsson <h...@iki.fi> wrote: >> >> 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. > > -- > h...@iki.fi https://www.haa.iki.fi > > > > _______________________________________________ > 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
