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. 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. 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... -- kivi...@iki.fi _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
