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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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









[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]