Subject: [dmarc-ietf] Modeling MLM behavior

From: Tim Draegen <[email-masked]>
Date: Fri, 3 Oct 2014 12:05:40 -0400

On Sep 20, 2014, at 7:41 AM, Alessandro Vesely <[email-masked]> wrote:
> IMHO, we should specify a credible MLM model, even if that can be
> slightly off topic for the WG, in order to maximize its probability of
> being adopted.  The rest of this message has some notes to this end.

The discussion of interoperability between DMARC and MLMs has become opaque enough to warrant taking the time to document the learning.  To make comparing and contrasting between MLMs possible, I think the WG needs a model -- just like Alessandro proposed -- so that we can all talk about this space with a common understanding.  AND, so that others can quickly get up to speed and make appropriate contributions.

To this end, I've created:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MailingListModel

..and have asked Alessandro to put his proposal into Wiki form.  Alessandro's proposal can be found here:

  http://www.ietf.org/mail-archive/web/dmarc/current/msg01670.html

Everyone is free to help out by working on the page.

1/2 of the WG Chair,
=- Tim

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2014 17:14:45 -0000

>The discussion of interoperability between DMARC and MLMs has become opaque enough to
>warrant taking the time to document the learning.  To make comparing and contrasting between
>MLMs possible, I think the WG needs a model -- 

Take a look at RFC 6377.  It's not really a BCP, but it lays out most of the ways
MLMs interact with DKIM keys.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Oct 2014 13:24:49 -0700

> > being adopted.  The rest of this message has some notes to this end.

Can I get some clarification on the intent here?  As worded, this paragraph
suggests that we are looking to produce a model for MLMs to follow in a
DMARC-aware world.  I was under the impression that (a) this is a
non-starter, and (b) we're not chartered to do so.

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 06 Oct 2014 23:52:10 +0200

On 10/06/2014 10:24 PM, Murray S. Kucherawy wrote:
> On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Sep 20, 2014, at 7:41 AM, Alessandro Vesely <[email-masked]
>     <mailto:[email-masked]>> wrote:
> Can I get some clarification on the intent here?  As worded, this 
> paragraph suggests that we are looking to produce a model for MLMs to 
> follow in a DMARC-aware world.  I was under the impression that (a) 
> this is a non-starter, and (b) we're not chartered to do so.

I  believe your impression is correct. Let's not start working on MLM's.

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 06 Oct 2014 20:00:19 +0200

On Fri 03/Oct/2014 18:05:40 +0200 Tim Draegen wrote: 
> 
> The discussion of interoperability between DMARC and MLMs has
> become opaque enough to warrant taking the time to document the
> learning.

I re-read Section 3.9 of RFC 5321 and it looks like current MLM
behavior deviates considerably from the simple emulation of an MTA "as
a continuation in email transit" which is envisaged there.

While that was probably noted many times, I don't recall discussions
on To: rewriting.  Did we consider that?

Please feel free to change/comment
Ale

---

From: Hector Santos <[email-masked]>
Date: Mon, 6 Oct 2014 19:15:44 -0400

Murray, I think we need to make the distinction of two different concepts and acronyms; MLM "Mailing List Manager" and MLS "Mail List Servers" that serve the MLM market.  There are some basic integration guidelines for both the MLS and MLM.  I understand we don't want to make any changes, but the front-end, receivers, websites, i.e.  Potential Entry Points, do need implementation change considerations.

I was able to minimize direct MLS changes to nil and added a few MLM operator features to existing operator configuration capabilities to fit into a DKIM+ADSP+ATPS Mail I/O backend aware framework.  I am waiting to do the DMARC plug and play, swap.

The 2006 DSAP draft section 3.3 Mailing List Servers suggest some simple basic concepts that I believe is near universal. But by 2009, the actual suggested implementation changes were done outside the MLS component.   See my point? 

--
Hector Santos
http://www.santronics.com

> On Oct 6, 2014, at 4:24 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Can I get some clarification on the intent here?  As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world.  I was under the impression that (a) this is a non-starter, and (b) we're not chartered to do so.
> 
> -MSK
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Oct 2014 16:54:38 -0700

On Mon, Oct 6, 2014 at 2:52 PM, Rolf E. Sonneveld <
[email-masked]> wrote:

> follow in a DMARC-aware world.  I was under the impression that (a) this is
> a non-starter, and (b) we're not chartered to do so.
>
>

Just to be clear, I think cataloging MLM interactions and all that stuff is
potentially quite useful, but the suggestion was to "specify a credible MLM
model" which to me sounds like we're going to propose something we have no
business proposing; we're not chartered to do so, and history suggests
there will be aggressive objection to any such effort even if we were.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Oct 2014 17:03:45 -0700

On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos <[email-masked]> wrote:

> Murray, I think we need to make the distinction of two different concepts
> and acronyms; MLM "Mailing List Manager" and MLS "Mail List Servers" that
> serve the MLM market.  There are some basic integration guidelines for both
> the MLS and MLM.  I understand we don't want to make any changes, but the
> front-end, receivers, websites, i.e.  Potential Entry Points, do need
> implementation change considerations.
> [...]
>

I think this is unrelated to my point.

It's my understanding that the idea of altering DMARC to better work with
mailing lists is on the table, though later in our list of milestones.  The
idea of specifying how MLMs (or MLSes, or whatever) should operate in a
DMARC world, however, is not.

I just don't want any of us operating under the illusion that we can
prescribe how extant MLMs need to change now that DMARC is in use if in
fact we can't.  There's obviously a lot of energy to be wasted in that
direction.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 07 Oct 2014 11:29:04 +0900

Hector Santos writes:

 > The 2006 DSAP draft section 3.3 Mailing List Servers suggest some
 > simple basic concepts that I believe is near universal.

URL, please.  I never heard of this concept before.  To this MLM
developer, your heavily abbreviated description doesn't make the
utility of the concept clear, but I suppose the original document
explains in more detail.

 > But by 2009, the actual suggested implementation changes were done
 > outside the MLS component.  See my point?

Nope.  Need context.

---

From: Hector Santos <[email-masked]>
Date: Tue, 07 Oct 2014 07:57:13 -0400

Hi Stephen,

The 2006 DSAP "DKIM Signature Authorization Protocol" draft 
concentrated on the process boundary conditions (possible values for 
1st and 3rd party conditions).  Section 4.2 summaries the boundary 
conditions:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2

4.2.  DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;

    From the viewpoint of the verifier, when a message is received, there
    are two basic pieces of signature information to be of interest when
    analyzing the transaction:

    o  Original Party Signatures (OP)

       *  never expected
       *  always expected
       *  optional

    o  3rd Party Signatures (3P)

       *  never expected
       *  always expected
       *  optional

    When the two signature types are combines, the possible policies are
    listed in this following table:

+=================================================================+
| op=         | 3p=        | Domain Policy Semantics              |
|=================================================================|
| empty       | empty      | No mail expected                     |
|-----------------------------------------------------------------|
| never       | never      | No signing expected                  |
| never       | always     | Only 3P signing expected             |
| never       | optional   | Only 3P signing optional             |
|-----------------------------------------------------------------|
| always      | never      | OP signature expected                |
| always      | always     | Both parties expected                |
| always      | optional   | OP expected, 3P may sign             |
|-----------------------------------------------------------------|
| optional    | never      | Only OP signing expected             |
| optional    | always     | OP expected, 3P expected             |
| optional    | optional   | Both parties may sign.               |
+-----------------------------------------------------------------+
              Figure 4: DSAP Message Signing Policies

Section 3.3 basically provided some simple guidelines for a MLS:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3

The term DMARC can be swapped in the section since its really about a 
general DKIM+POLICY and it doesn't matter if it was SSP, ADSP, DSAP or 
DMARC:

    3.3.  Mailing List Servers

    Mailing List Servers (MLS) applications who are compliant with DKIM
    and DMARC operations, SHOULD adhere to the following guidelines:

    Subscription Controls

       MLS subscription processes should perform a DMARC check to
       determine if a subscribing email domain DMARC 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 DMARC 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.

However, the same issues of integrity changes was apparent then as it 
is now. The only way to minimize the impact is to first support it and 
only deal with the optional policies.  In other words, allow the 
YAHOO's to change their policies to FIT a proper end to end protocol 
(that means DMARC MUST offer 3rd party policies) that does include and 
allow the MLS to fit in -- PROPERLY without all this hacking and 
"ignore DMARC" and 5322.From destruction mentality going on that is 
only going to work with selected groups or systems, if that, leaving a 
security hole for the rest of the world to deal with.

Keep in mind that as much as DKIM wishes to separate the AUTHOR from 
the SIGNER domain, it can not.  It is BURNED into the spec as the 
single most important binding requirement -- That means it can't 
change and thats the purpose of this *security* concept.  Breaking it 
and assuming the original domains will allow this to occur 
unchallenged is not a good idea, playing with fire.

Have a good day Stephen

---

From: Hector Santos <[email-masked]>
Date: Tue, 07 Oct 2014 08:17:06 -0400

But I am a commercial MLS producer and there are some considerations 
when you integrate it into the mail system.  I think we covered most 
of the concepts over the years. But it is just lost in tons of 
verbiage and repeating it is just going to be as confusing.

I suggest to summarize it in a technical summary and can get begin 
with a basic idea:

     MLS/MLM (entry points) SHOULD honor DMARC policies by controlling
     the subscription and submission process of restrictive domains.

This is how we begin to minimize the impact.  I think it will be a 
mistake to assume domains who will invest into DMARC will accept the 
idea of "Security Holes" existing at certain MLM setups.  What I won't 
do is add the built-in out of the box MLS capability to satisfy this 
limited MLM and short term desire of rewriting 5322.From lines.  It 
will have to be totally binding with original domain permission to do 
so that all downlinks can verify. But then we will have a backward 
compatibility loophole.

Thanks Murray. Have a good day.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 08 Oct 2014 01:53:38 +0900

Hector Santos writes:

 >      the subscription

This is technologically infeasible.  DMARC provides no guidance from
the Domain Owner about what mailboxes are allowed to receive, so the
DMARC policy record provides no guidance about subscription to mailing
lists.

 >      and submission process of restrictive domains.

I think I'll just say no, at least for poster/subscriber combinations
where the subscribers want to see the poster's messages.  I really
don't see why I should devote resources to this, as long as this
protocol is available to be abused by Domain Owners who are unwilling
to impose appropriate terms of service on their users so that it is
absolutely clear that the Domain Owner forbids posting to my lists.
(I want to cite the ToS in my rejection notice.)

If this means that some spoofed transactional mail might get through
my content filters and distributed to the list, I'm willing to take
that risk.  My filters are pretty good so far.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 08 Oct 2014 02:49:57 +0900

>     http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2

Thank you for the URL.

In the following, I do not mean to discuss the concrete proposal as if
it were WG business (I don't believe it is).  I'm trying to understand
what model of Internet mail system behavior is presumed, which I
believe is WG business, as it is essential to framing BCPs and new
protocols to improve security.

 >     o  Original Party Signatures (OP)

I don't understand the differentation between 'optional' and 'never'
here in terms of real mail system behavior.  What would the
interpretation of a valid DKIM signature satisfying identity
alignment?  That's not a question about the spec (I can and will read
the spec).  The point is that in practice lots of admins do not read
the spec, and even those who do often provide some heuristic
interpretation rather than follow it precisely.  I doubt the answers
would be consistent with each other or with the spec.

That sounds like trouble to me.  We should prefer conceptualizations
that are crisp and intuitive to non-IETF-ers.

 >     o  3rd Party Signatures (3P)

Again, I don't understand the semantics of "expected" here, and
they're quite different from the semantics of the same values for OP.
Some 3rd parties will sign, others won't.  What key do they sign with?
Some will be authorized 3PS, some won't.  etc. etc.  I don't see how
this three-valued parameter can possibly be a good fit for most
"naive" admins' mental models, or for what they want the system to do.

 >     Subscription Controls

As I explain in more detail elsewhere, no policy framework I've seen
can justify subscription controls.

Overall, I get the impression that your mental model of email is
framed almost entirely by the corporate transactional mail use case,
where the employer can and does forbid "personal" and "indirect" use
of mailboxes in the corporate domain.  That's an important use case,
but your proposals leave little room for reliable and convenient
service to other use cases.  Rather, they arrogate all policy
decisions to Domain Owners, which will surely be a bottleneck for
small organizations running mailing lists and new entrants wishing to
develop new 3rd party email services.  Such services will want to
mitigate (ie, non-conforming behavior to avoid validation failure).

You threaten non-conforming services with

 > thats the purpose of this *security* concept.  Breaking it and
 > assuming the original domains will allow this to occur unchallenged
 > is not a good idea, playing with fire.

but in practice it seems to me that the restrictions and inconvenience
involved in conforming to your proposals is already everything those
"original domains" can use to threaten mailing lists, and quite
restrictive (at least) for other 3rd party services!

In any case, Google and several MTA vendors were already providing
relaxed implementations combining DMARC policy information with other
metadata and content analysis in making acceptance decisions.  Yahoo! 
and AOL quite obviously *want* the "security broken" (they thank us
for doing exactly what you describe as "playing with fire").  Aren't
they "original domains"?  If they are, the "original domains" are
going to have to sort things out among themselves to get a coherent
protocol.  If they aren't, aren't *they* the problem, not the 3rd
party services who are only doing what their clients and their
clients' domain owners want done?

That is, shouldn't you advocates of full OP control figure out how to
arrange that your protocol doesn't get hijacked by domains that permit
unregulated use of 3rd party services by mailbox users?

Steve

---

From: Tim Draegen <[email-masked]>
Date: Tue, 7 Oct 2014 16:41:05 -0400

> Can I get some clarification on the intent here?  As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world.  I was under the impression th…

Sorry to inject confusion and not immediately follow up.

The intention is to have something in place -- the MLM model -- that can be used to quickly identify issues that are related to DMARC interoperability with any given piece of MLM software.  I read Alessandro's model as a way to generically describe MLMs, which would make comparing and contrasting of MLMs a lot easier.

IOW, fleshing out a matrix of interoperability issues with respect to MLMs is made easier (possible?) if we have a generic way to describe MLM behavior.  This is not meant to be a robust exercise in crafting the ideal MLM.

If something like this is NOT in place, my concern is that the WG will only look at the big MLM packages.  If the WG does not spend time collecting input, the WG will not be able to make informed decisions regarding solutions.

=- Tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Oct 2014 14:39:42 -0700

On Tue, Oct 7, 2014 at 1:41 PM, Tim Draegen <[email-masked]> wrote:

> The intention is to have something in place -- the MLM model -- that can
> be used to quickly identify issues that are related to DMARC
> interoperability with any given piece of MLM software.  I read Alessandro's
> model as a way to generically describe MLMs, which would make comparing and
> contrasting of MLMs a lot easier.
>
> IOW, fleshing out a matrix of interoperability issues with respect to MLMs
> is made easier (possible?) if we have a generic way to describe MLM
> behavior.  This is not meant to be a robust exercise in crafting the ideal
> MLM.
>
> If something like this is NOT in place, my concern is that the WG will
> only look at the big MLM packages.  If the WG does not spend time
> collecting input, the WG will not be able to make informed decisions
> regarding solutions.
>
>
What I believe you're saying is that you want to have a description of the
current MLM model, generalized or in the aggregate, as a place from which
to start talking about DMARC's impact.  I'm totally fine with that and
agree that it's probably useful to write it down.

The way Alessandro made his proposal suggested to me that we were starting
down the road of some kind of formal description of how the DMARC world
wants MLMs to behave, as different from the current model.  That was a red
flag to me.

Thanks for clarifying.

-MSK