Really?
You knew that our software was the first to suggest and document in
the 2006 DSAP I-D on how to a MLS will need to handle restrictive
domain security policies. RFC 6377 (BCP 167) notes on this came from
my I-D and the DKIM WG discussions about it whether directly or not.
http://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.
Our MLS was the first supports this.
During development of RFC6377, the potential interop issues was well
known. I was able to show this when the middle ware ignores DKIM
signature controls.
DMARC will not resolve the problem, but .....
Part of the problem has been with the DKIM mindset to make it a 3rd
party signature framework where the LIST or 'central' mail distributor
has full control of signatures. Remember, in the original DKIM,
making it work with LIST system was a secondary chartered concern.
That charter changed (or did it?) and not for the better with a lesser
focus on the author domain policies, and eventually dismantling of
ADSP, but replaced with DMARC.
Restrictive 1st party controls are by design not to work in the 3rd
party environment. That was the purpose and intent of the original SSP
policies, and the reduced ADSP proposal. DSAP attempted to bring back
that idea. You could only implement it as described above or by simply
following the policy in some fashion to not cause downlink issues.
Intentionally ignoring it was not an option if you wanted to support DKIM.
But DKIM and its deployment documents are in conflict. It says follow
ADSP, but it allows for the 3rd party DKIM signing system to ignore it.
Can't have it both ways.
---
HLS
On 4/8/2014 1:19 PM, S Moonesamy wrote:
Hi Ned,
At 09:52 08-04-2014, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
Actually, mailing lists *can* implement DMARC, just not that way: Do
a DMARC
check on all incoming messages, and if the domain policy is one that is
incompatible with the list's own policies - whatever they are -
either change
the list's policies to conform to that message or reject it outright,
preferably with a nasty "find another a better mail provider" sort
of message.
There is some Mailman code which does the above.
If the IETF wants to take a leadership position in regards to this
issue,
perhaps someone could set this up.
I did a search before asking this question; I did not find any
answer. Does anyone know whether the IETF adheres to BCP 167?
Regards,
S. Moonesamy