On 2022-11-25 at 00:10 -0500, Dave Anderson wrote: > And even when it's possible it's not always desirable. An > organization > I'm involved with has many <function>@<organization> email aliases > which forward to the person(s) responsible for those functions. This > is convenient for people who need to communicate with us since they > don't have to hunt for the responsible person(s) and their email > address(es), and is convenient for us since we can easily change the > forwarding when who is responsible for a function changes. > > Dave
Forwarding is not the problem. The problem is that the forwardee's server is not aware of the forwarded, and treats it as first-party email. I'd say that forwarding such as the one you describe is done internally every day at lots of organisations. And it doesn't cause any problem, since the original and final server are "the same" (in the same organizational domain) and there is a trust relationship. However, if they are handled by distinct organisations, say j...@freebsd.org to j...@example.net, jdoe should get example.net configured so that freebsd,org MTA is treated as a trusted hop [whenreceiving email for j...@example.net]. When people configure forwarding only at the sending side, the setup is incomplete, and the result may or may not work (or, as it oten happens, work only sometimes), since from example.net point of view, the freebsd MTA is "spoofing everything". Now, one reason it's not done is that the end users don't know they should do anything at that side, but another is that most of them use provders which don't offer such option at all (and generally even freemails for which they don't have any support), So it's a semi-broken setup. (Yes, ARC is presented as a solution, and it could avoid it if the sealer was trusted, but you would still need to have a way to trust it, which is largely similar to getting it configured based on source IP, or a forwarding DKIM selector) _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
