I'm woefully behind on this list. Apologies if these points have already been
made.
On Wed, Jul 19, 2023, at 4:42 PM, 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.
>
> 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.
As someone who provided mail services for a R1 research university for 19
years...
Pretty much all universities have migrated to O365 or Gmail due to economic
factors, which have tiered pricing for hosting legacy addresses that use the
same domain as the active faculty/students. Researchers and grad students want
their old address to remain active because it what they publish on papers, and
they want the mail sent to their old address to follow them to their new
academic institution(s) and employer(s) when they move on. Yes, the Alumni
division also offers a different domain for alumni, hosted by admins who don't
know much about email interoperability, but that is just another domain hosted
on Gmail, so the forwarding problem is Gmail's so solve, as much as it is a
problem for the university to solve for allowing forwarding for active/former
faculty/students.
> 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...
During my 19 year career we used software built by Ned Freed. It was perfectly
capable of evaluating full content (as well as integrating with 3rd party
evaluation software) and return an appropriate SMTP response after DATA. Why is
it still so difficult?
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
