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 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 mai
