On 2024-02-09 15:50:36 (+0800), Cyril - ImprovMX via mailop wrote:
But to get circle back at email forwarding and Gmail issues, there is
one
point that bothers me with ARC and I'd like that someone could tell me
that
I'm wrong (with valid arguments, of course).
ARC tells the receiver party that the sender is not the original one,
but
that sender signed the previous state of AR headers (SPF, DKIM and
DMARC
state), which they now somehow broke but "it's okay because the
original
source was different".
Now, if I'm a bad person, I can easily create fake previous headers
that
looks like it's coming from, say, the IRS, and say that it's passing
the
SPF and DMARC with great success. I would sign my ARC with my domain,
which
I control, and in theory, the receiving party would receive an email
from
me, supposedly originated from the IRS with valid SPF and DMARC
because I
told so, and signed it ?
This would work if you could trust me in that scenario, but how can
you?
I'm definitely opposed on building a (white) list of allowed domains,
as it
would give even more power to the big ones (you'd certainly include
GAFAM
in it) and gives nearly an impossible state for all the small ones, or
the
new ones.
If you exclude that whitelisting, ARC (for validating) is absolutely
useless.
Am I wrong?
You are not wrong. But you should treat ARC signatures in exactly the
same way you treat DKIM signatures: as one signal. Blindly trusting ARC
signatures is not going to go well for you.
Forwarding is generally only seen on the last hop these days. Unless
you're the final recipient, ARC won't be a very meaningful signal. If
you are the final recipient, you could check how often you've seen that
ARC signer. Or that {source,signer,recipient} tuple. Or a subset.
The only thing ARC tells you is that the forwarder is making some claim
about the Authentication-Results header. What you make of that is up to
you.
Philip
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
