On 10/12/2017 01:17 PM, Hector Santos wrote:
SRS "didn't work" (catch on) because there is/was a fundamental
concept/idea/methodology/philosophy/taboo that the Return Path
(5321.MailFrom) should never be changed/altered/tampered with along the
transport path/route.
Interesting.
That's new to me. But I haven't administered email as a day job in a
number of years. Just personal / friend / family things now.
I can see why people might view the Return Path (RFC 5321 Mail From) and
From header (RFC 5322 From) as sacrosanct. I can somewhat get behind
it. At least for the normal delivery path, including relays.
I guess I personally view things like forwarding email and mailing lists
as being the end of one delivery path and the start of a second delivery
path.
It's the same long time mail engineering ethics mindset against altering
the 5322.From original/authoring address to deal with 3rd party issues
and ADSP/DMARC strong policies.
I strongly view things like the original recipient's .forward file and
mailing lists to be entities unto themselves. I deliver messages to
them, and they can do what ever they want to with them. If that means
that they generate new messages (Auto-Submitted: auto-generated) based
on the incoming messages, so be it. - I view these new messages as
being from said entity, thus think the 5321.MailFrom and 5322.From
/should/ reflect said entity.
I know that I am *not* personally sending /individual/ messages to all
of the DMARC list subscribers. - I /am/ sending a single message the
DMARC mailing list. Subsequently the DMARC mailing list is sending many
individual messages to all the list subscribers. ;-)
But, to each his / her own.
Thank you for the enlightenment Hector.
--
Grant. . . .
unix || die
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
