On Wed 19/Jul/2023 23:42:55 +0200 Tero Kivinen wrote:
Wei Chuang writes:
2) The proposed language calls out "“alumni forwarders”, role-based email
aliases, and mailing lists" for consideration by receivers. How should
receivers be aware that traffic failing authentication should be reconsidered?
Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1]
call out more strongly the application of those List-id headers? Can
something be done so that receivers can identify the other scenarios e.g.
role-based email aliases and alumni-forwarders?
For alumni forwarders / role-based forwarders things are different, as
users who set those up, actually knows who does the forwarding, and
they themself recognize that emails coming to those addresses are
important to them, and they also trust (university etc) the one doing
forwarding.
That's particularly true for internal role forwarding. As time goes by,
maintenance almost always forget to whitelist forwarders.
So if the alumni forwarder / role-based forwarder adds ARC signatures,
then the final recipient can whitelist that ARC signer in their setup
and say that the policy code that checks the SPF/DKIM/DMARC results
can fully trust the signed ARC authentication results from that
signer.
Setting up an maintaining such trust lists is an effort which requires some
planning. And learning about new forwarders who deserve trust is not easily
automated too.
This of course requires that the recipient SMTP server can't simply
reject the incoming email after the MAIL FROM because SPF checks do
not match, they actually need to receive the email so they can check
ARC and DKIM headers...
Shared whitelists may seem to help smoothing this corner. Granting just the
minimal trust necessary to receive the message could be afforded at minimal cost.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
