[dmarc-ietf] Re: Restating the forwarding problem

[Douglas Foster <[e-mail]>]

DMARC is vulnerable to false Pass from SPF Upgrade attacks, false Fail
results as consequence of most forwarding, and both events are difficult to
detect.  Forwarding either produces a false SPF Fail on the original
RFC5321.MailFrom address, or an SPF Pass result on a modified
RFC5321.MailFrom address which is irrelevant to the question of
authorization at origination.    So yes, authentication is unreliable
whenever an intermediary is present.  In practice, we accept credential
upgrades created by outbound service providers for the simple reason that
there is no better alternative.

My use of ARC has been primarily or exclusively focused on outbound gateway
services.    I have several unhappy experiences with spam and probable
impersonation getting through these services.  The highest volume of ARC
data comes from Outlook.com.   When it acts as an outbound gateway service,
it creates an ARC set with the results of SPF/DKIM/DMARC.   When those
results are clearly negative, Outlook.com adds the client signature anyway,
and sends it on to the intended recipient.   Some messages are then routed
to another outbound service provider, which ignores the failed
authentication data and adds a client signature as well.
These documented authentication lapses cause the environment to appear very
insecure, but the volume of true impersonation attacks is not consistent
with that appearance -  something less than one per year.   So while I log
the possible impersonations, I do not act on them at this time.   I have
the hooks in place to create local policy exceptions for the many
legitimate-but-unauthenticated messages, if I wish to begin enforcing
quarantine of these unauthenticated messages in the future.   At least one
other large platform has this problem, but I get much less traffic from it.

ARC has also been instructive to see the sloppiness of many outbound
gateway services.   Many break the ARC chain while adding a DKIM signature
for the client.   At one point, I made a list and started contacting
vendors.  One vendor thanked me and fixed the problem.   One said they
would deal with it in a year.   One said they would deal with it when their
customers complained.  The rest said nothing.

I have a very limited volume of external mailing list traffic, and I do not
recall that any of them have implemented ARC.   It is an ideal tool for a
mailing list to prove that it only accepts posts from authors that are
authenticated with aligned SPF Pass, but that has to be true before they
can document it.   In the absence of inbound authentication, I don't see
that they have any incentive to document what they do not do.

Doug




On Tue, Apr 28, 2026 at 4:03 PM Richard Clayton <[e-mail]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <[e-mail]
> il.com>, Douglas Foster <[e-mail]> writes
>
> >Email authentication is only reliable when the message is received
> directly
> >from the originating organization.
>
> I don't think that's entirely true ... but let's move forward with that
>
> [snip]
>
> >When the limitations of DMARC are understood, I cannot construct a
> scenario
> >where ARC data causes harm.
>
> At $DAYJOB$ we implemented a scheme for using ARC to influence DMARC
> decisions. It has no other real impact on "scoring" which is all about
> email content and customer feedback.
>
> Using ARC information worked very badly because another large provider
> failed to tell us that the contents of email had been altered (to make
> it malicious) by a third party ... The third party resent the email
> onward via the large provider who extended the ARC chain, so when we
> walked it back to the beginning we saw that the first ARC set told us to
> give the email a DMARC pass, which was an incorrect conclusion.
>
> The issue is that ARC envisages a chain of custody but the protocol
> described in the RFC does nothing to check that chain doesn't include
> entities that have changed the message without declaring they have done
> so. So ARC data can cause harm if you think it is useful.
>
> When $DAYJOB$ realised that trusting the ARC chain to give us a DMARC
> result was counter-productive we removed the other large provider from
> our trust list. They are now, months later, stripping their own ARC info
> from incoming email which may improve things.
>
> - --
> richard @ highwayman . com                       "Nothing seems the same
>                           Still you never see the change from day to day
>                                 And no-one notices the customs slip away"
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBafESM2HfC/FfW545EQIH1QCfUg3hqAsXMGKtCOqn9nOZ4n1n3tAAnjmG
> GMQJpGhqTs61IJrQFCCD+fsl
> =UkSL
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> dmarc mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>