Re: DMARC: perspectives from a listadmin of large open-source lists

[Hector Santos <[e-mail]>]

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, [e-mail] 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
>
>
>