G'day.
In looking for ways to make a DMARC-style function succeed when the
message transits an intermediary, the current approach has mostly been
proposing one or another wholesale solution. This creates a complex
space for discussion and tends towards some version of deadly embrace.
It might be helpful to consider /basic types/ of changes that are
reasonable/unreasonable for intermediaries, distinct from how they might
fit into an entire solution.
Reasonable vs. unreasonable pertain to at least two axes:
1. Amount of work
2. Policy/Principle
Some choices entail too much work or run afoul of basic operational
policies. Others might entail some work, but not too much, and might
not be considered as significant violations of established policies.
Here be dragons, of course, but let's try to have the discussion anyhow.
Obviously, there will not be unanimity among all intermediaries, for any
proposal. So the question really is about plausible rough consensus
among a 'substantial' amount of the community.
The first question is: what are the 'types' of changes that have been
or might be proposed? This should turn into some sort of taxonomy,
eventually, but for now an undisciplined core dump(*) of choices would
be best.
Examples:
Modifying the rfc5322.From display-name
Modifying the rfc5322.From address
Modifying the footer of the message body (first body-part.)
Modifying the rfc5322.Subject preface
Performing DMARC validation upon receipt
Performing DKIM/SPF validation upon receipt
DKIM-signing all outbound mail.
Registering the intermediary with all potential sites posting to it
Registering the intermediary with all potential sites receiving from
it
Your turn...
d/
(*) it occurs to me that the term might now be archaic, since 'core'
hasn't been used in quite a long time. if so, i guess 'memory dump'
would be the term?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
