Dave,
In the 2006 DSAP I-D, I wrote down and implemented what I felt were
reasonable integration changes for our list server package (MLS):
https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3
3.3. Mailing List Servers
Mailing List Servers (MLS) applications who are compliant with DKIM
and DSAP operations, SHOULD adhere to the following guidelines:
Subscription Controls
MLS subscription processes should perform a DSAP check to
determine if a subscribing email domain DSAP policy is restrictive
in regards to mail integrity changes or 3rd party signatures. The
MLS SHOULD only allow original domain policies who allow 3rd party
signatures.
Message Content Integrity Change
List Servers which will alter the message content SHOULD only do
so for original domains with optional DKIM signing practices and
it should remove the original signature if present. If the List
Server is not going to alter the message, it SHOULD NOT remove the
signature, if present.
When it, DKIM+ADSP+ATPSrev4, was finally implemented, very little
change was done to the MLS itself as long as its entry points did all
the ADSP (and now DMARC) checking.
It really hasn't deviated other than we are replacing ADSP with DMARC,
with the same issues, same needs, long worked out.
--
HLS
On 5/15/2015 4:28 PM, Dave Crocker wrote:
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?
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
