Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 10:11:14 -0400

I will probably regret this, but since people are throwing around things like 
Pareto to argue in favor or against specific solution areas, I thought it might 
be useful to take a step back and look at what might make a solution (or set 
of solutions) useful to pursue.

For indirect mail flows like mailing lists, there are three actors involved:

1.  Originator
2.  Mediator
3.  Receiver

For the purposes of this discussion I'll further categorize the entities 
involved as big and small (yes, it's way more complex than that, but I think 
that's sufficient).

That leads to six combinations: Originator/Big, Originator/Small, 
Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small.

There have been solutions proposed that only require changes for one of the 
three above, that require changes at two of the above, and that require 
changes at all three.

Two examples of solutions that require changes only for one actor are 
configuring mailing lists not to make changes that break DKIM signatures and 
mailing lists rewriting the body From to a local value.  While both of those 
have drawbacks, from a utility analysis perspective, I think they are useful 
to include in the family of solutions to the indirect mail flow problems caused 
by DMARC.

Rationale:  They can be deployed by mediators both big and small with no 
further coordination with other actors.  For mediators that choose to go down 
this path and accept the downsides of these approaches, they can solve the 
indirect mail flow problem.

Another example of a potential solution is receivers amalgamating data from 
across their user base to identify forwarders and utilize a local policy 
override to not reject DMARC fail messages assessed to be sent via an indirect 
mail flow.  This is supported by the DMARC specification, but it's not something 
that Receiver/Small is going to be able to do.  It's only really useful for 
Receiver/Big.  It should be included in the family of solutions, but it could 
not be said to 'solve' the indirect mail flow problem since it doesn't scale 
down.

While none of these three solutions are complete, they are complete at least 
for those entities willing and able to deploy them.

Once a solution requires changes from multiple actors, the assessment is more 
complex.  If a solution requires (as an example) both sender and receiver 
changes to work, then if it only works for small entities, then I don't think 
it has utility.  Since Big sends to Small and Small sends to Big, any solution 
that affects multiple types of actors needs to work for both Big and Small, 
otherwise if a Small only solution is deployed it will fail when Small sends 
to Big.  Conversely, if a Big only solution is deployed, it will fail when Big 
sends to Small.  

This type of assessment is why I was attracted to John Levine's fs= proposal.  
While it is inherently very complex to deploy (it definitely requires sender 
and receiver changes and for some indirect mail flows [those that strip 
signatures today]), there is nothing inherently Big or Small about it.  I 
think it has other problems that may or may not be resolvable, but from a 
solution space coverage perspective it is attractive.

For the complex solution set that covers multiple actors, I think we have to 
have a single solution to propose.  If we have multiple, multiple actor 
solutions, then interoperability in this space gets much more complex.  For 
single actor solutions, any solution that works and can be deployed helps 
interoperability because if any actor deploys it, the breakage is reduced.  
For multi-actor solutions, adding additional solutions probably reduces 
interoperability since in any given mail transaction (Originator -> Mediator -
> Receiver) all three have to have the same solution deployed.  If the 
Originator and Receiver have deployed three part solution #1 and the Mediator 
has deployed three part solution #2, then both solutions fail.  It's the same 
as having done nothing.

In terms of what makes sense to specify in the output of the working group, I 
think we should be willing to accept as many single actor solutions as we 
discover and have energy to document.  They are always good.  None of these 
solutions is free of side effects and actors should be free to pick their 
poison as long as it doesn't break things elsewhere.

For multi-entity solutions, I think we should be more constrained.  I think 
any multi-actor solution has to work for both Big and Small actors or else 
there is no interoperability.  I think at most one three actor modification 
solution ought to be included.  I think there is possibly room for solutions 
that relate only to two actors in addition.  We can't afford, both in terms of 
working group time and energy and in eventual interoperability to have a lot 
of choices in this more complex space.

Note:  This is not intended to say anything is in or out, just to give a 
framework for the discussion.

Scott K

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 16 Apr 2015 14:32:24 +0000

Scott,

Thanks for laying the problem space out in this manner.

Mike

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, April 16, 2015 10:11 AM
> To: [email-masked]
> Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
> 
> For the purposes of this discussion I'll further categorize the entities involved
> as big and small (yes, it's way more complex than that, but I think that's
> sufficient).
> 
> have drawbacks, from a utility analysis perspective, I think they are useful to
> include in the family of solutions to the indirect mail flow problems caused by
> DMARC.
> 
> further coordination with other actors.  For mediators that choose to go
> down this path and accept the downsides of these approaches, they can
> solve the indirect mail flow problem.
> 
> across their user base to identify forwarders and utilize a local policy override
> to not reject DMARC fail messages assessed to be sent via an indirect mail
> flow.  This is supported by the DMARC specification, but it's not something
> Receiver/Big.  It should be included in the family of solutions, but it could not
> be said to 'solve' the indirect mail flow problem since it doesn't scale down.
> 
> Once a solution requires changes from multiple actors, the assessment is
> more complex.  If a solution requires (as an example) both sender and
> receiver changes to work, then if it only works for small entities, then I don't
> think it has utility.  Since Big sends to Small and Small sends to Big, any
> solution that affects multiple types of actors needs to work for both Big and
> Small, otherwise if a Small only solution is deployed it will fail when Small
> sends to Big.  Conversely, if a Big only solution is deployed, it will fail when Big
> sends to Small.
> 
> signatures today]), there is nothing inherently Big or Small about it.  I think it
> has other problems that may or may not be resolvable, but from a solution
> space coverage perspective it is attractive.
> 
> Originator and Receiver have deployed three part solution #1 and the
> Mediator has deployed three part solution #2, then both solutions fail.  It's
> the same as having done nothing.
> 
> discover and have energy to document.  They are always good.  None of
> these solutions is free of side effects and actors should be free to pick their
> For multi-entity solutions, I think we should be more constrained.  I think any
> multi-actor solution has to work for both Big and Small actors or else there is
> no interoperability.  I think at most one three actor modification solution
> ought to be included.  I think there is possibly room for solutions that relate
> only to two actors in addition.  We can't afford, both in terms of working
> group time and energy and in eventual interoperability to have a lot of
> choices in this more complex space.
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2015 16:31:37 -0000

>Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small.

This is indeed useful.  But I think it's also important to look at
technical vs. nontechnical costs for each actor.  The whole reason
we're having this discussion is that a few large originators had
nontechnical costs that they decided to push off onto other people.*

The most tedious and unhelpful discussions here have implicitly (or
perhaps explicitly) assumed that receiver nontechnical costs don't
matter, then repeatedly pointed out the true but useless fact that
there are single party mediator changes with trivial technical costs.

R's,
John

* - the essence of Internet economics is forcing as many of your costs
onto other people as you can, but that doesn't make it a virtue

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Apr 2015 13:03:20 -0400

Scott, 

what is your summary with all this?

We probably should understand optimization concepts such as Pareto Optimality and Query Dissemination.  Both are applicable here as well.

I've actually have two receivers; one for the mediator and one for the end-users.   The problem was that Levine did not want the mediator receivers to support policy.  Hence ADSP got no support by MLM receivers (except for us, but we didn't flip the rejection switch, just recorded results).  What Levine forgot was the user receivers, and that is what DMARC forgot too.   Overall, they presumed no one will take it serious and honor it, including controlling the MLM entry points.

Well. It did.

We got many IETF-MAN-YEARS  of engineering into all this and the policy lookup was the method ultimately devised as the baseline.  While it was confused with mandates to limit the business damage to the resigner market, and a focus to kill policy methods all together,  it never removed the need to get 3rd authorization from the ADID.  

Blind resigners was a security threat. DKIM could not separate the purported author from the signature and signer.  The 5322.From is required. If it wasn't, we would then have a different security model.  From all historical angles, from rewrites is simply not a good idea to crack open that door.  It changes everything  and makes the entire discussions moot.  As mentioned before, a rewrite is most certainly IETF Appeal sensitive.  Just saying.

RFC work was done for threats, requirements and overall the DKIM architecture and using 1st and 3rd party policy framework is a result and consistent with all the IETF-MAN-YEARS put into this work.   We were complaining about the  actually record and query method and possible management complexity.  Not so much the registration part of it because that can also be learned over time.  This work is still relevant and even more so today because the mindset has changed to enable policy (via DMARC).  We simply did not have this before with ADSP.  So DMARC has changed the game. 

The in-band is fine but it's weaker and more expensive to implement, and the registration is still required by the organizations still interested in keeping with a higher level of DKIM security strength a policy framework provides.   Let's not assume that given no other design option, sites will just blindly sign all mail.   Given no other choice, who knows, you might force sites to re-invest in their DKIM engine to do this double signing  and also do the policy level verification,

Also, keep in mind, the failures points of the proposal too. That's very important here.  Are we ready to do the MUST/SHOULD for negative classification (reject/discard/quarantine) when the detectable @fs= protocol failures exist?   Remember, it's not just about looking for the good,  but filtering the failures from the stream, and we can't once again get the disillusionment that no one will honor rejection because the two receivers are also using query dissemination methods to minimize connection abuse issues.

Look, supposedly opendkim has support for ADSP/ATPS.  A simple change to piggy back off the DMARC record itself with the renewed interest for policy now, we can better measure the level of support and also provide the opportunity for sites to do registration R&D.   

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

> On Apr 16, 2015, at 10:11 AM, Scott Kitterman <[email-masked]> wrote:
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Apr 2015 11:07:21 -0700

> there are single party mediator changes with trivial technical costs.

Useless because it presumes the non-technical costs of those changes are
high?

---

From: "John R Levine" <[email-masked]>
Date: 16 Apr 2015 14:34:38 -0400

> Useless because it presumes the non-technical costs of those changes are

At least, we need to look at what non-technical costs they push onto other 
parties.

Some changes have insignificant non-techincal costs and are not 
controversial, e.g., adding a List-ID header for the benefit of recipients 
who know how to use it.  Changes that seem similar may have quite 
different costs, e.g., adding a List-ID and removing subject tags, forcing 
recipients to change the way they sort and organize their incoming 
messages.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 16 Apr 2015 21:35:45 +0200

On 04/16/2015 08:34 PM, John R Levine wrote:
> At least, we need to look at what non-technical costs they push onto 
> other parties.
>
> controversial, e.g., adding a List-ID header for the benefit of 
> recipients who know how to use it.  Changes that seem similar may have 
> quite different costs, e.g., adding a List-ID and removing subject 
> tags, forcing recipients to change the way they sort and organize 
> their incoming messages.

I (think I) understand what you mean and I sympathize with your 
reasoning. But how are we supposed to compare non-technical costs with 
technical costs? And what would be the formula to make a fair comparison 
between Technical/Non-technical Costs for Big/Small 
Originators/Mediators/Receivers? The concept of technical vs 
non-technical cost at least doubles the six combinations, mentioned by 
Scott.

/rolf

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 15:44:34 -0400

I don't have a summary.  To the extent I mentioned any specific proposal it was 
meant to be merely exemplary.  The point, is to come up with a framework to 
discuss solution utility.  Because there is a certain breadth of deployment 
needed for interoperability for some solutions, I don't think Pareto analysis 
is useful at all.

We've spent a lot of time going around in circles about various proposals and 
so I'm trying to come up with a useful way for us to focus.  It doesn't 
eliminate the need to make sure any method we pursue works and is secure, it's 
just a way to see what clears the minimum threshold for deployability to 
provide a potential for interoperability.

Your mail is mostly arguing about specifics of different solutions.  That means 
we're not at all on the same page.  I'm attempting a step back to define a 
framework we can use to move the group forward.  Please look at it at that 
level and take a step back both from the well known history and the particular 
solutions you like or don't like.

Scott K

On Thursday, April 16, 2015 01:03:20 PM Hector Santos wrote:
> We probably should understand optimization concepts such as Pareto
> Optimality and Query Dissemination.  Both are applicable here as well.
> 
> I've actually have two receivers; one for the mediator and one for the
> end-users.   The problem was that Levine did not want the mediator
> receivers to support policy.  Hence ADSP got no support by MLM receivers
> (except for us, but we didn't flip the rejection switch, just recorded
> results).  What Levine forgot was the user receivers, and that is what
> DMARC forgot too.   Overall, they presumed no one will take it serious and
> honor it, including controlling the MLM entry points.
> 
> Well. It did.
> 
> We got many IETF-MAN-YEARS  of engineering into all this and the policy
> lookup was the method ultimately devised as the baseline.  While it was
> confused with mandates to limit the business damage to the resigner market,
> and a focus to kill policy methods all together,  it never removed the need
> to get 3rd authorization from the ADID.
> 
> Blind resigners was a security threat. DKIM could not separate the purported
> author from the signature and signer.  The 5322.From is required. If it
> wasn't, we would then have a different security model.  From all historical
> angles, from rewrites is simply not a good idea to crack open that door. 
> It changes everything  and makes the entire discussions moot.  As mentioned
> before, a rewrite is most certainly IETF Appeal sensitive.  Just saying.
> 
> RFC work was done for threats, requirements and overall the DKIM
> architecture and using 1st and 3rd party policy framework is a result and
> consistent with all the IETF-MAN-YEARS put into this work.   We were
> complaining about the  actually record and query method and possible
> management complexity.  Not so much the registration part of it because
> that can also be learned over time.  This work is still relevant and even
> more so today because the mindset has changed to enable policy (via DMARC).
>  We simply did not have this before with ADSP.  So DMARC has changed the
> game.
> 
> The in-band is fine but it's weaker and more expensive to implement, and the
> registration is still required by the organizations still interested in
> keeping with a higher level of DKIM security strength a policy framework
> provides.   Let's not assume that given no other design option, sites will
> just blindly sign all mail.   Given no other choice, who knows, you might
> force sites to re-invest in their DKIM engine to do this double signing 
> and also do the policy level verification,
> 
> Also, keep in mind, the failures points of the proposal too. That's very
> important here.  Are we ready to do the MUST/SHOULD for negative
> classification (reject/discard/quarantine) when the detectable @fs=
> protocol failures exist?   Remember, it's not just about looking for the
> good,  but filtering the failures from the stream, and we can't once again
> get the disillusionment that no one will honor rejection because the two
> receivers are also using query dissemination methods to minimize connection
> abuse issues.
> 
> Look, supposedly opendkim has support for ADSP/ATPS.  A simple change to
> piggy back off the DMARC record itself with the renewed interest for policy
> now, we can better measure the level of support and also provide the
> opportunity for sites to do registration R&D.
> 
> --
> Hector Santos
> > I will probably regret this, but since people are throwing around things
> > like Pareto to argue in favor or against specific solution areas, I
> > thought it might be useful to take a step back and look at what might
> > make a solution (or set of solutions) useful to pursue.
> > 
> > involved as big and small (yes, it's way more complex than that, but I
> > think that's sufficient).
> > 
> > configuring mailing lists not to make changes that break DKIM signatures
> > and mailing lists rewriting the body From to a local value.  While both
> > of those have drawbacks, from a utility analysis perspective, I think
> > they are useful to include in the family of solutions to the indirect
> > mail flow problems caused by DMARC.
> > 
> > override to not reject DMARC fail messages assessed to be sent via an
> > indirect mail flow.  This is supported by the DMARC specification, but
> > it's not something that Receiver/Small is going to be able to do.  It's
> > only really useful for Receiver/Big.  It should be included in the family
> > of solutions, but it could not be said to 'solve' the indirect mail flow
> > problem since it doesn't scale down.
> > 
> > While none of these three solutions are complete, they are complete at
> > least for those entities willing and able to deploy them.
> > 
> > receiver changes to work, then if it only works for small entities, then
> > I don't think it has utility.  Since Big sends to Small and Small sends
> > to Big, any solution that affects multiple types of actors needs to work
> > for both Big and Small, otherwise if a Small only solution is deployed it
> > will fail when Small sends to Big.  Conversely, if a Big only solution is
> > deployed, it will fail when Big sends to Small.
> > 
> > This type of assessment is why I was attracted to John Levine's fs=
> > proposal. While it is inherently very complex to deploy (it definitely
> > requires sender and receiver changes and for some indirect mail flows
> > [those that strip signatures today]), there is nothing inherently Big or
> > Small about it.  I think it has other problems that may or may not be
> > resolvable, but from a solution space coverage perspective it is
> > attractive.
> > 
> > For the complex solution set that covers multiple actors, I think we have
> > to have a single solution to propose.  If we have multiple, multiple
> > actor solutions, then interoperability in this space gets much more
> > complex.  For single actor solutions, any solution that works and can be
> > deployed helps interoperability because if any actor deploys it, the
> > breakage is reduced. For multi-actor solutions, adding additional
> > solutions probably reduces interoperability since in any given mail
> > transaction (Originator -> Mediator -> 
> > Mediator has deployed three part solution #2, then both solutions fail. 
> > It's the same as having done nothing.
> > 
> > In terms of what makes sense to specify in the output of the working
> > group, I think we should be willing to accept as many single actor
> > solutions as we discover and have energy to document.  They are always
> > good.  None of these solutions is free of side effects and actors should
> > be free to pick their poison as long as it doesn't break things
> > elsewhere.
> > 
> > solution ought to be included.  I think there is possibly room for
> > solutions that relate only to two actors in addition.  We can't afford,
> > both in terms of working group time and energy and in eventual
> > interoperability to have a lot of choices in this more complex space.
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Apr 2015 13:58:59 -0700

On Thu, Apr 16, 2015 at 11:34 AM, John R Levine <[email-masked]> wrote:

> who know how to use it.  Changes that seem similar may have quite different
> costs, e.g., adding a List-ID and removing subject tags, forcing recipients
> to change the way they sort and organize their incoming messages.
>

Rolf kind of said what I'm thinking here: I agree that we need to look at
the costs.  But are we willing, or not willing, to accept costs that are
not zero?

For example, asserting that all parties should have to take on zero
non-technical cost here seems like it might leave us dead in the water
before we even start.  I don't have a good non-zero suggestion though,
because it's hard (or maybe even impossible) to be specific.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 17:05:55 -0400

On Thursday, April 16, 2015 01:58:59 PM Murray S. Kucherawy wrote:
> > different

I think there's a wide enough variety of participants in the working group 
that we'll know if it's 'too much', whatever that turns out to be.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Apr 2015 17:20:01 -0400

> because it's hard (or maybe even impossible) to be specific.

Murray, we don't need to go that far.

We are talking about a IETF protocol engine that has two basic flows:

     ADID == SDID  conditions
     ADID != SDID  conditions

We just need to come up with the models for this and let the market 
decide.

The problem is that ATPS was short-changed as an extension to ADSP 
which was being abandoned.

The APIs were ready for this.  Since DMARC replaces ADSP, you need to 
update RFC6541 to have it piggy back off DMARC.  Since DMARC is now 
being adopted to replace ADSP in the industry, you now need to make it 
market ready for the 3rd party check allowing them to learn how to 
scale it too.

If you want to do this IN-BAND stuff for those systems that can not do 
DMARC+ATPS, that would be great and it would cover a wider market, 
including the biggest one who can afford the additional changes to all 
this.  They can also afford to do both ATPS and IN-BAND as well if 
they choose to so.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2015 21:20:38 -0000

>the costs.  But are we willing, or not willing, to accept costs that are

Sure, everything has some cost.  Something I should have made clearer
is the difference between the costs of changes one imposes on one's
self and those forced on third parties, particularly on third parties
that didn't volunteer to accept them.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 17:26:05 -0400

On Thursday, April 16, 2015 05:20:01 PM Hector Santos wrote:
> >> other
> >> recipients

I don't think market share in the abstract is useful for this discussion. Per 
my utility analysis, the question is not percent of market (however that is 
defined), but breadth of market scope being sufficient to enable interoperability 
when it's needed.  I would still appreciate solution independent discussion of 
how to do the utility analysis or I fear we'll continue to just argue past 
each other.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Apr 2015 14:57:10 -0700

On 4/16/15 2:26 PM, Scott Kitterman wrote:
> I don't think market share in the abstract is useful for
> this discussion. Per my utility analysis, the question is
> not percent of market (however that is defined), but
> breadth of market scope being sufficient to enable
> interoperability when it's needed. I would still
> appreciate solution independent discussion of how to do
> the utility analysis or I fear we'll continue to just
> argue past each other.
Dear Scott,

DMARC is leveraging a public-suffix list to reduce
overhead.  This approach will cause problems if it leaves a
gap between the domains provided by a registrar and those
listed as part of the public suffix.  With the massive
amounts of DMARC feedback being generated, perhaps there
should be a way to consolidate these domains into some type
of list.  Of course, I'll suggest a hashed label approach. 
Can anyone envision some type of community or specialized
effort at consolidating this category of the domain space?

Regards,
Douglas Otis

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 17 Apr 2015 00:21:33 +0200

> that didn't volunteer to accept them.

yes, but the problem with cost imposed on third parties is that it is 
valued different by the one who imposes it on someone else and the one, 
on which is it imposed. And that is due to the fact, like you said 
earlier today:

> The whole reason
> nontechnical costs that they decided to push off onto other people.

Now I think Scott is right that we need to make a step back and his 
analysis might help us to know on which solutions we'd best spend most 
of our time. However, having said that, I'm afraid that we're biased by 
our discussions around the 'DMARC/Mailing List problem'. Let's not 
forget the other use cases of draft-ietf-dmarc-interoperability.

I believe a number of the Mediators, described in par. 3.2 of 
https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot 
easily be changed. To give an example: recently when I was working for 
company A, I forwarded an invitation I got from company B to one of my 
addresses at ESP C. I just used the Exchange/Outlook forward function at 
company A and discovered that the mail client I used at ESP C showed the 
address of company B, no the address I have with company A. Company A is 
using Exchange/Outlook 2010 and has no plans to upgrade for the next 
couple of years. Should Microsoft update Exchange to support some 
mediator 'change' for DMARC, then this probably won't be 'retrofitted' 
into Exchange 2010. So it may take many years before I can use a version 
that supports DMARC 'mediation'.

Maybe we should assign a higher score/priority to solutions that only 
cover Originator and Receiver, as (in general) the Originator and 
Receiver are primary stakeholders re. the proper transfer and delivery 
of the message.

/rolf

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 18:40:59 -0400

>effort at consolidating this category of the domain space?

I think it would be better to await the results of the recently chartered dbound working group. Whatever DMARC does should, in the end, align to that, so it would be better not to have this group expend effort in that area for now. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Apr 2015 19:06:02 -0400

On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote:

> of our time. However, having said that, I'm afraid that we're biased
> by our discussions around the 'DMARC/Mailing List problem'. Let's not

+1 Extremely bias.

Lets keep in mind that there are two minimum receivers generally with 
a MLM transaction that also need to be part of the cost and impact 
analysis:

    MDA1 -- receiver and resigner
    MDA2 -- final user(s) receiver(s).

Another solution (partial) is for MDA1 honor policy and not allow 
resigning to take place.  The one that is talked about the most are 
the MDA2 end user receivers rejecting messages.   We will  want to 
maximize the MDA2 consistent and persistent result factor since there 
could be many different implementations at the MDA2 nodes.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2015 00:03:40 -0000

>on which is it imposed.

Well, sure.  If I can force you to solve my problem, as far as I'm
concerned that's a free solution.  I hope we agree we want to stay
away from that dark corner.

>easily be changed.

That seems reasonable.  We can have a discussion about whether things
like my double signer trick, which might be implemented in a wrapper
or a postprocessor qualify as not changing the mediator.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Apr 2015 17:05:25 -0700

Dear Scott,

This misses the point.  There is precedence for DMARC using
lists composed without an official basis yet essential to
its operation.  Why wait for dbound aimed at offering
completely different results?  As this WG considers special
handling for domains that operate some type of third-party
service, these same considerations become critical elements
in achieving a network effect toward practical solutions
safely restoring the role of Sender wholly ignored by DMARC.

Achieving a network effect requires consensus on how to
effectively deal with problems DMARC creates when handling
third-party services and dealing with misleading assertions
made in DMARC policy.  Consensus should avoid endorsing
modes of operation that detract from the social and civic
benefits derived from an open exchange of email.  The WG
should strive to ensure an email notification scheme will
not cripple other services in use for decades.  Finding a
balance likely means algorithmically categorizing either
third-party domains or domains making misleading assertions. 

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 20:16:11 -0400

>could be many different implementations at the MDA2 nodes.

It's a bit more complex than just not resigning (actually resigning shouldn't hurt).  What MDA/MTA1 needs to do is avoid any transformations that would invalidate the originator's DKIM signature.   
For some, that's a reasonable solution, but for others it's not because they aren't willing to give up the traditional mailing list transformations, i.e. there is a side effect that leads the mediator to consider the approach to costly (costs aren't just money).

Although we've been focused on mailing lists in discussing the possible solution space, the framework I laid out is suitable for any mediated message transaction.  I think the solution space for third-party originators is likely disjoint from the  solution space for mediated transactions, so I haven't worried about it too much. 

I'd still rather focus on an assessment framework before we go zooming into solutions again. I don't think we're getting very far without it. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Apr 2015 20:21:36 -0400

On April 16, 2015 8:05:25 PM EDT, Douglas Otis <[email-masked]> wrote:
>> I think it would be better to await the results of the recently
>chartered dbound working group. Whatever DMARC does should, in the end,
>align to that, so it would be better not to have this group expend
>effort in that area for now. 
>Dear Scott,
>

We're going to have to use whatever PSL replacement dbound produces.  Let's not have to change twice. 

I agree that harmonizing DMARC and various third-party originator's operations will be complicated. I think the mediator case is more tractable, so I have focused there for now. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 17 Apr 2015 13:29:48 -0400

On 4/16/2015 8:16 PM, Scott Kitterman wrote:
> It's a bit more complex than just not resigning (actually resigning shouldn't hurt).

What I meant about actually, is for the MDA1 to respect the 
restrictive policy and reject the message (list submission, 
subscription attempts, etc) and use a reply code/response to explain 
why.

> What MDA/MTA1 needs to do is avoid any transformations that would invalidate the originator's DKIM signature.

Thats optional. Again Domain Policy based:

    Policy is relaxed, the MLM may resign, including stripping.
    Policy is strict,  the MLM should block the subscription/submission.

Again, as long as the policy also give options for the 3rd party, it 
can satisfy all boundary conditions.  See below.

> For some, that's a reasonable solution, but for others it's not because they aren't willing to give up the traditional mailing list transformations, i.e. there is a side effect that leads the media…

Scott, when it comes to products, you will have all sides and the good 
way to address is to make it optional. Everyone is happy.  Sure, its 
more work, but thats the life of a product developer.

So yes, we need to separate all the subjective, possible 
Administrator/Operator options, local policy related stuff and extract 
the basic protocol engine stuff, the state machine.   If you control 
the access points, then much of this is resolved.  See below.

> I'd still rather focus on an assessment framework before we go zooming into solutions again. I don't think we're getting very far without it.

We went thru a threat analysis (RFC4686) and functional requirements 
(RFC5016) RFC productions and have the basic ideas and problem points 
well understood.

At the end of the day, no matter what, the receiver will have a fixed 
set of boundary conditions regarding what the ADID and SDID will look 
like. There are nine basic combinations of signatures when you assign 
to each NEVER, ALWAYS, OPTIONAL expectations:

    1st party:  NEVER, ALWAYS, OPTIONAL
    3rd party:  NEVER, ALWAYS, OPTIONAL

So your protocol engine needs to be able to deal with each combination 
of possible policy.  Some will fold providing a smaller set of 
conditions.  The following is an example diagram illustrating this:

    +-----------+
    |  PAYLOAD  |
    +-----------+
         |
         v
  +----------------+
  |                |                            +------------+
  | DKIM           |--------------------------->| CONTINUE   |
  | Signature      | UNSIGNED: OPTIONAL (1)     +------------+
  | Authorization  |
  | Protocol       |
  |                |                            +------------+
  |                |--------------------------->|            |
  |                | SIGNED: EXPIRED (2)        |            |
  |                |--------------------------->|            |
  |                | NO MAIL EXPECTED (3)       | FAILURE/   |
  |                |--------------------------->| CLASSIFY   |
  |                | UNSIGNED: REQUIRED (4)     |            |
  |                |--------------------------->|            |
  |                | SIGNED: NOT EXPECTED (5)   |            |
  |                |--------------------------->|            |
  |                | 3P SIGNED: NOT ALLOWED (6) |            |
  +----------------+                            +------------+
         |
         |
      SIGNED
      MESSAGE
         |
         v                                      +------------+
    +--------------+                            | CONTINUE/  |
    |              |--------------------------->| CLASSIFY   |
    |              |    INVALID SIGNATURE       +------------+
    | DKIM         |
    | SIGNATURE    |
    | VERIFICATION |                            +------------+
    | (7)          |--------------------------->| PASS       |
    |              |    VALID SIGNATURE         +------------+
    +--------------+

No matter what system you have, they all have be persistent and 
consistent on what is expected for each condition. That is not a 
mandate (you have local policy), but it tells you what are the MUSTs, 
SHOULDs and MAYs.

Overall, you are looking for the failure points.

(1) Unsigned mail arrives and the policy says its optional. 
Indeterminate condition, punt, continue.

(2) Signed mail, but it expired.  Negative classification.

(3) No mail is expected for this domain, Negative classification.

(4) Unsigned mail arrives and the policy says its required.  Negative 
classification.

(5) The main is signed, but it wasn't expected. Negative classification.

(6) The mail is signed by 3rd party and policy doesn't allow that. 
Negative classification.

While some of the conditions can be folded, we are missing #6 which 
allows for checking for 3rd party signature authorization.  But it can 
even be just that you don't expect it, hence a condition that allows 
for strong failure detection.

-- 
HLS

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 25 Apr 2015 11:50:31 +0200

On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote:

> I will probably regret this, but since people are throwing around
> things like Pareto to argue in favor or against specific solution
> areas, I thought it might be useful to take a step back and look at
> what might make a solution (or set 
> For the purposes of this discussion I'll further categorize the
> entities involved as big and small (yes, it's way more complex than
> that, but I think that's sufficient).
> 
> There have been solutions proposed that only require changes for one
> of the three above, that require changes at two of the above, and
> that require 
> changes at all three.

Nice framework.

I'd like to note that it is the presence/existance of actor "Mediator" which induces the DMARC compatibility problems with indirect flows.

I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution.

I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc.

And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc.

What costs are Mediators currently taking to improve validation/authentication of the email system as a whole?

Regards,
J.Gomez

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 25 Apr 2015 12:24:14 +0200

> What costs are Mediators currently taking to improve validation/authentication of the email system as a whole?

and what benefits do they get in return?

/rolf

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 25 Apr 2015 15:32:59 +0200

On Saturday, April 25, 2015 12:24 PM [GMT+1=CET], Rolf E. Sonneveld wrote:

> > > areas, I thought it might be useful to take a step back and look
> > > at what might make a solution (or set
> > > entities involved as big and small (yes, it's way more complex
> > > than that, but I think that's sufficient).
> > > 
> > > There have been solutions proposed that only require changes for
> > > one of the three above, that require changes at two of the above,
> > > and that require
> > > changes at all three.
> > Nice framework.
> > 
> > I'd like to note that it is the presence/existance of actor
> > "Mediator" which induces the DMARC compatibility problems with
> > indirect flows.  
> > 
> > I.e., if you supress the Mediator, all is fine and dandy. That fact
> > should at leat put some pressure on Mediator regarding the
> > searching for a solution, and should induce Mediator to acknowledge
> > that he will have to assume certain costs for such a solution.   
> > 
> > I see Originator already assuming costs: deploying SPF in DNS and
> > keeping it current, deploying DKIM records and DKIM-signing
> > outgoing email, deploying DMARC records and being vigilant
> > regarding Header-From alignment in his outgoing email, etc.   
> > 
> > And I see Receiver already assuming costs: setting up systems to
> > check SPF, DKIM and DMARC for incoming email, dealing with the
> > support costs of false positives and phised users, sending out
> > DMARC reports, etc.   
> > 
> > What costs are Mediators currently taking to improve
> > validation/authentication of the email system as a whole? 
> 

The benefit to Mediators is that they will avoid becoming an obsolete artifact of the past, like open SMTP relays.

Regards,
J.Gomez

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Apr 2015 06:38:32 -0700

On 4/25/2015 6:32 AM, J. Gomez wrote:
>>> I.e., if you supress the Mediator, all is fine and dandy. 
...
> The benefit to Mediators is that they will avoid becoming an obsolete artifact of the past, like open SMTP relays.

The word that is needed here is 'Procrustean'.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 25 Apr 2015 23:29:49 +0900

> validation/authentication of the email system as a whole?

Isn't it obvious that Mediators bear all of the burden that *both*
ends do?  Of course, we perform both roles on each message.  We verify
signatures and filter messages on the way in, which potentially could
reduce costs system-wide due to the multiplier effect of mailing lists
(except of course nobody trusts us to do it well).  We sign the
version of the message that we send out.  (These are functions of the
MTA, of course, and we can't do a better or worse job than any
Originator or Recipient.  Except that to some extent Mediators may
have information about the Originator that Recipient systems don't,
which may improve filtering.)

What else do you propose that we do?  GNU Mailman has been working
(desultorily) on lists which authenticate posters via personal digital
signatures, but that isn't going to help much.

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 25 Apr 2015 19:11:00 +0200

On Saturday, April 25, 2015 4:29 PM [GMT+1=CET], Stephen J. Turnbull wrote:

> What else do you propose that we do?

Well, if you ask... Mediators could take ownership of the Header-From whenever their involvement results in the Originator's DKIM signature being invalidated. Or some other change to their "entrenched" traditional behavior, like stop adding subject tags and body footers and being content with using some List-ID header to identify themselves, etc.

Everyone (Originators and Receivers) is changing their email usage patterns/processes in order to take email to the next level (in reality, just to keep it a viable communication option in an increasingly hostile Internet environment), but Mediators seem totally unwilling to change their email usage patterns/processes.

Email is changing. We all have to change to accomodate the fact that email is changing. Mediators don't seem willing to change at all. What I see is that email is about to evolve to the next level, and Mediators are at risk of being left behind if they refuse to change to accomodate the fact that email is changing.

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 26 Apr 2015 09:25:31 +0900

J. Gomez writes:

 > Well, if you ask... Mediators could take ownership of the
 > Header-From whenever their involvement results in the Originator's
 > DKIM signature being invalidated.

The From header field is not in the public domain, and not available
for appropriation.  "Taking ownership" of something that isn't yours
is properly called "theft", and as I understand it is it forbidden by
all of the mail header RFCs since 733, which assign that field to the
originator, and no role in editing it to other participants in the
mail system.

The fact that Message-ID changes not only are not performed, but
actually cause annoyance (unfilterable duplicates for subscribing
recipients and inability to search archives for non-subscribers)
suggests that to recipients as well as to originators and mediators
the two messages are the same.  Therefore the authors of the original
messages remain the authors for the purpose of "From ownership".

We (MLMs in general, as exemplified by GNU Mailman) in fact *do* allow
this (as a per-list option).  Not only does it violate the RFCs
according to our interpretation, not only is it ugly and inconvenient,
but it even causes some users to identify our posts as spam.  This is
hardly a desirable change if other changes can be made to improve the
situation.

 > Or some other change to their "entrenched" traditional behavior,
 > like stop adding subject tags and body footers and being content
 > with using some List-ID header to identify themselves, etc.

My own Internet facing lists don't add any such, although the lists
where I can effectively forbid use of DMARC-abusing mailbox providers
do.  In general, it's not the mediators who care.  It's the recipient
users, who have a conflict of interest with their mailbox providers,
not with the mediators.

 > Everyone (Originators and Receivers)

And Mediators.  I don't understand why you refuse to admit that
Mediators *must* perform the same functions as Receivers and
Originators in order to safely accept and reinject messages.  In the
case of GNU Mailman, with the help of Franck Martin, we also released
(publicly, as part of our normal development cycle) a version
including DMARC mitigations 6 months *in advance* of the April Fiasco.

I don't understand why you insist on attacking the mediators, when (1)
the DMARC Originators who publish p=reject are in conflict with their
own users, (2) the DMARC Originators are not only signing their own
content, but unilaterally asserting that it is the only content
permitted in any version of messages originated in their system, in
violation of the expectations of their own users as originators and of
mailing list subscribers as recipients, and (3) the particular
"p=reject" use case causing issues was pre-deprecated in their own
standard.

In any case, your "burden-equalization" approach is purely political,
and does not respect that fact that the technical opportunities to
mitigate the problem are not equally distributed.  Mediators have very
little power to improve service unless the Originators participate;
all we can do is watch the services we are allowed to provide be
deprecated.

 > is changing their email usage patterns/processes in order to take
 > email to the next level (in reality, just to keep it a viable
 > communication option in an increasingly hostile Internet
 > environment), but Mediators seem totally unwilling to change their
 > email usage patterns/processes.

Nonsense, and your insistence on this nonsense is getting very
tiresome.  The reality is that Mediators *have* changed their patterns
and processes *already*, in fact some of the changes anticipated the
issues we now are wrestling with.

It's not the Mediators who are unwilling to change.  It's the *users*.
The agents who are blocking the changes needed to satisfy the users'
requirements are the DMARC p=reject mailbox providers, in view of (1)
and (2) above.

Mediators such as mailing lists can adapt, *and already have done so*,
but we also advocate our users' interests.  Those interests continue
to be harmed, to the profit of Yahoo! and AOL, and to the detriment of
*everybody else* in the mail system.  "Everybody else" includes those
DMARC participating domains who respect the SHOULDs and SHOULD NOTs of
DMARC!  That's because a protocol that brings them benefit is now a
dirty word all over the Internet.  For example, are you aware that the
Japanese government has deprecated use of *all* yahoo.* addresses for
official business, despite the fact that only yahoo.com publishes
p=reject?

 > Email is changing. We all have to change to accomodate the fact
 > that email is changing. Mediators don't seem willing to change at
 > all. What I see is that email is about to evolve to the next level,
 > and Mediators are at risk of being left behind if they refuse to
 > change to accomodate the fact that email is changing.

Thank you for your concern.  We Mediators can and will take care of
our own interests, and ask you to desist with your efforts to help --
they are not helpful because they do not respect our users'
requirements.

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 26 Apr 2015 12:21:04 +0200

On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote:

> is properly called "theft"

Is the message Subject in the public domain? Is the message Body in the public domain? Why are many mailing lists taking liberties with them? Sorry, but I think your analogy of email vs property does not compute.

> and as I understand it is it forbidden by

I think that point was settled as "it is debatable". That field contains the Author, and if the Author signed with DKIM and the mediated message breaks that signature, it can then be argued that Authorship has suffered and therefore that the From: Header should reflect that fact.

> Originators in order to safely accept and reinject messages.

Because the fact that Mediators also do the role of Originators and the role of Receivers is not what makes them special, but the very fact that they are the only ones doing the role of Mediators.

So the role of Originator has had to change and adapt. The role of Receiver has had to change and adapt. What changes have happened to the role of Mediator, to improve validation/authentication of the email system as a whole? None that I see, yet.

> "p=reject" use case causing issues was pre-deprecated in their own

Well, I don't "attack" anyone, I express my opinion about what I think would be the easiest and lest painful --considering the email system as a whole-- solution to the problem. If your feel that as an "attack", what can I do?

Yes, Mediators did not create the problem. It is not their fault. But live systems change, and we have to adapt. The roles of Originator and Receiver already are trying very hard to adapt. What is the role of Mediator doing to adapt to such change?

> all we can do is watch the services we are allowed to provide be

Yes, I see that danger of deprecation to mailing lists too (at least, to mailing lists managed/configured old-style). Email is heavily used in corporate settings; inter-domain mailing lists used as "discussion groups many-to-many", not so much. Market is a powerful force...

> *everybody else* in the mail system.

I think we should get past the Yahoos and the AOLs. They pioneered the misue of DMARC, but that misuse is here to stay and will certainly grow, to the point it will become "common usage". So the problem space is now bigger than just Yahoo and AOL.

I also feel I am advocating my users's best interests. I am not mad at you, don't be mad at me. :-)

> they are not helpful because they do not respect our users'

Well, I also have users whose interests I humbly try to present and defend here. I don't see why I should desist from doing so.

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 27 Apr 2015 09:34:01 +0900

J. Gomez writes:

 > Is the message Subject in the public domain? Is the message Body in
 > the public domain? Why are many mailing lists taking liberties with
 > them?

Our interpretation is that no liberties are being taken: we have tacit
permission from the authors.  I've *never* seen an author object to
those changes.  The only people who interpret them as not consonant
with the authors' wishes are spamfighters like you who aren't even
subscribed to the lists whose policy they advocate changing.

On the other hand, authors (and recipients) do object to lists
falsely claiming authorship of posts, for several reasons.  The cases
are quite different in the minds of the users.  Ask yours; you find
the same, I'm sure.

 > Sorry, but I think your analogy of email vs property does not
 > compute.

"Taking ownership" is your term, not mine.  I simply pointed out that
it has pretty wretched connotations of theft, forgery, and fraud.

 > That field contains the Author, and if the Author signed with DKIM
 > and the mediated message breaks that signature, it can then be
 > argued that Authorship has suffered and therefore that the From:
 > Header should reflect that fact.

Anything can be argued.  But I've never seen a *subscriber* ask for
this change, except when directed to do so by the "customer placation"
department at their provider.  I conclude that "cure worse than the
disease" spamfighters are the only advocates of this interpretation.

 > What changes have happened to the role of Mediator, to improve
 > validation/authentication of the email system as a whole? None that
 > I see, yet.

You won't, because there are none possible.  Currently, validation/
authentication is a protocol agreed between the originator and the
recipient, and as currently formulated, it is the originator's option
to deprecate *all* mediation unilaterally by signing the whole message
-- and that's the common practice.  Further, originators can use the
DMARC protocol to *forbid* mediation by signing the whole message and
publishing p=reject, again unilaterally.

Several attempts to devise ways for Mediators to participate in these
protocols are in the internet-draft stage, but all have strong
detractors.  And of course one option (of abstaining from mediation)
is as old as mailing lists -- the earliest MLMs were simple exploders
-- and is still availabie at the list owner's option.

 > Well, I don't "attack" anyone, I express my opinion about what I
 > think would be the easiest and lest painful --considering the email
 > system as a whole-- solution to the problem.

It's already available, and already used when the actual participants
in a mediated channel so prefer.  Your expression of opinion therefore
is useless -- *you* can already do what you claim is best on your own
lists, and at least the MLM product I help develop provides the
option, but experience shows that many subscribers and owners strongly
dislike it and very few favor it.

 > I think we should get past the Yahoos and the AOLs. They pioneered
 > the misue of DMARC, but that misuse is here to stay and will
 > certainly grow,

That's possible, but really, only yahoo.com and aol.com matter.  No
Yahoo! or AOL affiliate that I've checked other than those two
publishes p=reject or even p=quarantine, and in fact I've never seen
p=reject on a domain that posts to a mailing list other than those two.

It's true that a great majority of mail is sent from domains that
participate in the DMARC protocol, and many of them publish p=reject.
But IME only yahoo.com and aol.com cause problems for mailing lists.
he others either don't post to lists or don't publish p=reject.

 > problem space is now bigger than just Yahoo and AOL.

Name some other domains whose actual interaction with Mediators is
problematic.

 > at you, don't be mad at me. :-)

Why is it in *your* users' interests to tell *me* how to run my lists?
That's what I perceive as an attack, since I see no good reason.

GNU Mailman, for example, provides several DMARC mitigations.  The
traditionally available "just forward" configuration is still
available, but disliked strongly because users really like have
unsubscribe and archive links in the footer.  The "steal authorship"
option is available since Oct 2013 (6 months before the April
Fiasco).  Encapsulation of the decorated message in a message/rfc822
MIME part was provided later in 2013 IIRC.

The problem is that all are detested by some users, and none are
actually liked by any user.  Therefore we developers continue to seek
alternatives -- but all desirable alternatives require cooperation of
"p=reject" posting domains because of the nature of current validation/
authentication protocols as Originator-Receiver agreements.

---

From: Steve Atkins <[email-masked]>
Date: Sun, 26 Apr 2015 17:57:36 -0700

> he others either don't post to lists or don't publish p=reject.

They're the vast majority of breakage today, for sure.

There's also linkedin.com and one or two other corporates that
use the same domain for both their bulk mail and some of their
employee mail.

And libero.it went to p=quarantine last month, which will also break
mailing list interaction, though with less damage to bystanders
than p=reject.

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Apr 2015 01:09:13 -0400

On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote:
>> should at leat put some pressure on Mediator regarding the searching
>> for a solution, and should induce Mediator to acknowledge that he
>> will have to assume certain costs for such a solution.
>>
>> keeping it current, deploying DKIM records and DKIM-signing outgoing
>> email, deploying DMARC records and being vigilant regarding
>> Header-From alignment in his outgoing email, etc.
>>
>> support costs of false positives and phised users, sending out DMARC
>> reports, etc.
>>

Smooth operation?

Mediators don't really need to change, but their entry points need to 
support DKIM+POLICY.  For example, the Mediator receiver can simply 
support honoring restrictive policies and it doesn't need to bother 
with much else.

-- 
HLS

---

From: Michael Jack Assels <[email-masked]>
Date: Mon, 27 Apr 2015 07:17:05 -0400

On Sun, 26 Apr 2015 12:21:04 +0200, 
"J. Gomez" <[email-masked]> wrote:

> > for appropriation.  "Taking ownership" of something that isn't yours is
> > properly called "theft"
> 
> Is the message Subject in the public domain? Is the message Body in the
> public domain? Why are many mailing lists taking liberties with them?
> Sorry, but I think your analogy of email vs property does not compute.

Whether any header field is in the public domain is a legal question on
which I won't venture an opinion, but the From header stands out as one
that is treated specially by RFC5332, section 3.6.2:

   [...] The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the mailbox of the secretary would appear in the
   "Sender:" field and the mailbox of the actual author would appear in
   the "From:" field.  If the originator of the message can be indicated
   by a single mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

   [...]

   In all cases, the "From:" field SHOULD NOT contain any mailbox that
   does not belong to the author(s) of the message. [...]

It seems clear to me that, at the very least, the mailbox of the message's
author ought not to be and replaced by the mailbox of an automaton that
added a subject tag and a list trailer.  If the mailing list software has
made DKIM-breaking changes, it may make sense for it to *add* its own
mailbox to the From header (as a "coauthor"), and make itself the
Sender. 

MUAs may have widely varying methods of dealing with multiple mailbox From
headers, but in my experience, MTAs have no trouble with them, and they're
generally the ones handling DMARC issues.  RFC7489 has this to say (in
Section 6.6.1) about multiple-mailbox From headers:

   o  Messages bearing a single RFC5322.From field containing multiple
      addresses (and, thus, multiple domain names to be evaluated) are
      typically rejected because the sorts of mail normally protected by
      DMARC do not use this format;

   [...]

   The case of a syntactically valid multi-valued RFC5322.From field
   presents a particular challenge.  The process in this case is to
   apply the DMARC check using each of those domains found in the
   RFC5322.From field as the Author Domain and apply the most strict
   policy selected among the checks that fail.

The first paragraph seems to imply that DMARC admits the validity of
a multimailbox From field, but simply doesn't plan to support it.  The
second paragraph makes clear how the nonsupport is to be accomplished.

I understand that a ne'er-do-well might craft a spammy message with

      From: "Need enhancement?  See http://bad-example.com"
            <[email-masked]>, <[email-masked]>
      Sender: <[email-masked]>
      DKIM-Signature: [...]i=bad-example.com[...]
      DKIM-Signature: [...]i=example.org[...]

among the headers; hence the second quoted paragraph of RFC7489 above.

However, given an opportunity by DKIM, e.g., implementing Murray's
draft-kucherawy-dkim-transform-00, with some extra detail to accommodate
reversible From and Subject transformations, a mailing list could
fairly easily get away with something like

      From: <[email-masked]>, <[email-masked]>
      Sender: <[email-masked]>
      Subject: [list] Original subject
      DKIM-Signature: [...]i=example.com; ftf=2; stf=[list]; [...]
      DKIM-Signature: [...]i=example.org[...]

where "ftf=2" means "the second mailbox in the From header was added", and
"stf=[list]" means "the tag '[list]' in the Subject header was added.  Both
transformations are easily reversed.

MTAs implementing draft-kucherawy-dkim-transform-00 supplemented with ftf
and stf transformations should be able to reconstruct the original message
and verify its DKIM-Signature.  This adds plenty of work for Mediators --
possibly more than they can handle if the MLM has no direct access to DKIM
-- and only a little extra for Receivers.

RFC 7489's paragraph dealing with multimailbox From headers would have to
be change to something like

   The case of a syntactically valid multi-valued RFC5322.From field
   presents a particular challenge.  The process in this case is to
   apply the DMARC check using each of those domains found in the
   RFC5322.From field as the Author Domain and apply the most strict
   policy selected among the checks that fail.  However, if one
   DKIM-Signature fails on its own but passes under the reversal
   of transformations specified by another passing DKIM-Signature,
   then the first DKIM-Signature is deemed to have passed.

> I think that point was settled as "it is debatable". That field contains
> the Author, and if the Author signed with DKIM and the mediated message
> breaks that signature, it can then be argued that Authorship has suffered
> and therefore that the From: Header should reflect that fact.

The Authorship certainly hasn't suffered to the extent that the content has
been significantly changed.  At worst, the Authorship has been augmented by
the addition of content by another Author, which, I think, merits the
addition of a mailbox to the From header, not the replacement of the
principle Author with a minor contributor, which would be tantamount to
replacing a book's author with its publisher, who added the binding and
the copyright notice.

If MUAs do unpredictable things with multimailbox From headers, it
may be because they don't see them often enough.  I'm sure they'll fix
their errors if list mail begins to arrive with heretofore unusual but
RFC5322-compliant headers.

MJA (regretting that this turned out to be so long)

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Apr 2015 08:32:12 -0400

> authentication protocols as Originator-Receiver agreements.

The mediator has a receiver.  Doesn't it have the same 
Originator-Receiver agreements?

-- 
HLS

---

From: Michael Jack Assels <[email-masked]>
Date: Mon, 27 Apr 2015 12:45:38 -0400

On Mon, 27 Apr 2015 07:17:05 EDT, 

>       DKIM-Signature: [...]i=example.org[...]

Sigh.  All instances of "i=" were intended to be "d=", passim.

MJA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Apr 2015 11:44:38 -0700

> mailbox to the From header (as a "coauthor"), and make itself the

The question to me is whether the message that the MLM software emits is
the same as the original message.  If it is, then the Author ought to be
preserved across the MLM.  If it is not, then the MLM emits a new message,
and it actually SHOULD NOT keep the Author the same, as described above.
So we get to argue about "same", and of course the specs aren't
particularly rigorous about this.

RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it
doesn't change From, from which I infer it doesn't change Author, although
it does say it's a "new" message that's emitted.  That document is not a
proposed standard and merely documents current use (as I understand it), so
it's merely recording the fact that MLMs technically violate the SHOULD NOT.

So it seems to me the points of contention here are:

1) Is the MLM violation of the SHOULD NOT cited above the kind of violation
that we accept based on how "SHOULD NOT" is defined in RFC2119?  It seems
to me that it is, especially given how long they've been doing it without
objection (until now).  One could argue they've been "getting away with it"
for too long, but we can't change history.

2) Is the MLM emitting a new message?  I would agree with Michael and
contend that it is if there have been any content changes at all, in the
same way that someone making a compilation of a series of independent works
(a "mix tape") owns the copyright on the mix, though not on the original
material.  Now, MLMs do that with digests already -- who else could one
legitimately put in the From of a digest? -- but typically not for resent
messages.

To the point of Message-IDs, I would say that should follow the same rule
as the From change: If the content changes, it's a new message, and it gets
a new Message-ID.

Might it be sufficient to declare an "Original-Message-ID" or
"Author-Message-ID" or "List-Original-Message-ID" field that contains the
author-generated Message-ID, allowing for the duplicate suppression that's
done now?

> RFC5322-compliant headers.

I would far rather have MUA developers work with us directly, but the IETF
has a persistent allergy to us tampering in user space.  As I understand
it, our desire in general tends to be to create well-defined interfaces
(not APIs, mind you) at which MUAs can "meet" us on their own, and let them
take it from there.  Thus, the best we can do is be very clear about what
information is presented by a multi-From message and perhaps why, and hope
they'll adapt.

The sad legacy is that different mail operators have historically done
different things, which has led to MUAs doing different things, which has
in turn led to a global system that interoperates enough to be useful but
not enough to be able to lock down certain undesirable things without a
great deal of pain.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 27 Apr 2015 20:55:32 +0200

On Monday, April 27, 2015 2:34 AM [GMT+1=CET], Stephen J. Turnbull wrote:

> is useless

I am sorry my opinion is useless to you. It does not intent to have an utility per se, but to express my point of view as an actor in the email system.

> That's what I perceive as an attack, since I see no good reason.

You asked "What else do you propose that we do?". I obliged.

Again, I am sorry you didn't like it.

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 27 Apr 2015 21:27:42 +0200

Original Message from: Murray S. Kucherawy

> The question to me is whether the message that the MLM software emits
> is the same as the original message.  If it is, then the Author ought
> to be preserved across the MLM.  If it is not, then the MLM emits a
> new message, and it actually SHOULD NOT keep the Author the same, as
> described above.  So we get to argue about "same", and of course the
> specs aren't particularly rigorous about this.     
> 
> RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that
> it doesn't change From, from which I infer it doesn't change Author,
> although it does say it's a "new" message that's emitted. 

It seems RFC5598 says 3 things:

1. That the Author and only the Author goes in the Header-From. Period.
2. That mailing lists keep the "original Author" (sic) in the Header-From.
3. That mailing lists also become an Author when they retransmit a message (Section 5.3: "Because a Mailing List can modify the content of a message in any way, it is responsible for that content; that is, it is an Author.").

I see point 1 as normative, point 3 as an arrived conclusion (logical deduction) and therefore also normative as long as it is logically valid, and point 2 as documenting customary practice at the time that document was written.

So it seems, as per RFC5598, that a message mediated by a mailing list which alters its content has, at least, to Authors: the "original Author", and the mailing list itself.

Hmm, I see several ways to go from here.

Regards,
J.Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Apr 2015 12:38:15 -0700

> 3. That mailing lists also become an Author when they retransmit a message
> (Section 5.3: "Because a Mailing List can modify the content of a message
> in any way, it is responsible for that content; that is, it is an
> Author.").
>

> I see point 1 as normative, point 3 as an arrived conclusion (logical
> deduction) and therefore also normative as long as it is logically valid,
> and point 2 as documenting customary practice at the time that document was
> written.
>
> So it seems, as per RFC5598, that a message mediated by a mailing list
> which alters its content has, at least, to Authors: the "original Author",
> and the mailing list itself.
>

Keep in mind that RFC5598 is Informational.  It doesn't prescribe or
proscribe anything.  It just describes the "current" (at the time) email
architecture.  RFC5322 and its ilk are Standards track, and thus normative.

Even if we were all to concur that altering the From by adding the list is
the right way forward here (an intriguing idea at the moment), the question
of ordering would need to be addressed, and then how that applies to all
the standards we're talking about, and how MUAs need to be nudged to make
use of such things.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 27 Apr 2015 22:23:15 +0200

On Monday, April 27, 2015 7:09 AM [GMT+1=CET], Hector Santos wrote:

> > > I.e., if you supress the Mediator, all is fine and dandy. That
> > > fact should at leat put some pressure on Mediator regarding the
> > > searching for a solution, and should induce Mediator to
> > > acknowledge that he will have to assume certain costs for such a
> > > solution. 
> > > 

That is interesting.

Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received messages into the public email infrastructure in any way that could render them (or reveal them to be) DMARC-rejectable?

So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant?

That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC checks.

Then, if the market deems DMARC valuable by itself, pressure would be applied by the "invisible hand" there were it needs to be applied (so that reputable actors in the email ecosystem could claim to be DMARC-compatible).

Regards,
J.Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Apr 2015 13:58:28 -0700

On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez <[email-masked]> wrote:

> Couldn't the DMARC specification spell out that Receivers claiming to be
> DMARC-compliant, when choosing to *accept* incoming messages from Senders
> publishing p=reject (irrespective of whether such accepted messages passed
> or not the DMARC checks), CANNOT after-the-fact reinject such received
> messages into the public email infrastructure in any way that could render
> them (or reveal them to be) DMARC-rejectable?
>
> That would force DMARC-compliant Mediators to reject (or accept but not
> resend) incoming email from p=reject domains, irrespective of whether such
> mail passes or not the initial incoming DMARC checks.
>
> Then, if the market deems DMARC valuable by itself, pressure would be
> applied by the "invisible hand" there were it needs to be applied (so that
> reputable actors in the email ecosystem could claim to be DMARC-compatible).
>

Apart from the CANNOT bit, is that different from where we are today?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2015 21:25:38 -0000

>them (or reveal them to be) DMARC-rejectable?

Since there is no spec for "Receivers claiming to be DMARC-compliant"
and there never will be, of course not.  

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2015 21:29:51 -0000

>the right way forward here (an intriguing idea at the moment), ...

Just for the record, I haven't been responding to arguments about
rewriting the From: line because I don't any way they will lead to
anything useful, and I suspect I am far from the only one.  

But in this case, silence definitely does not mean consent.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 27 Apr 2015 23:33:50 +0200

On Monday, April 27, 2015 11:25 PM [GMT+1=CET], John Levine wrote:

> > Couldn't the DMARC specification spell out that Receivers claiming
> > to be DMARC-compliant, when choosing to *accept* incoming messages
> > from Senders publishing p=reject (irrespective of whether such
> > accepted messages passed or not the DMARC checks), CANNOT
> > after-the-fact reinject such received messages into the public
> > email infrastructure in any way that could render them (or reveal
> > them to be) DMARC-rejectable? 
> 

What? There is an spec for DMARC. With the current DMARC specification, anyone can do almost anything and still claim to be DMARC-compliant. What about if to claim being DMARC-compliant, Receivers could not reinject alien messages into the email infrastructure if the original Sender is publishing p=reject and said reinjected messages would fail a DMARC check when performed by its ultimate Recipient(s)?

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 27 Apr 2015 23:37:31 +0200

Original Message From: Murray S. Kucherawy
  On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez <[email-masked]> wrote:

  Apart from the CANNOT bit, is that different from where we are today?
Well, the CANNOT part would impede the whole lot of problems we are trying to solve, wouldn't it so?

Regards,
J.Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Apr 2015 17:51 -0400

On Monday, April 27, 2015 11:33:50 PM J. Gomez wrote:
> What? There is an spec for DMARC. With the current DMARC specification,
> anyone can do almost anything and still claim to be DMARC-compliant. What
> about if to claim being DMARC-compliant, Receivers could not reinject alien
> messages into the email infrastructure if the original Sender is publishing
> p=reject and said reinjected messages would fail a DMARC check when
> performed by its ultimate Recipient(s)?

Why would a mailing list care to claim spec conformance?

All they care about is getting the mail delivered, managing subscriber lists, 
etc.  Since there are no internet police, can not doesn't mean anything.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Apr 2015 14:56:45 -0700

> to solve, wouldn't it so?

Maybe.  I was just confirming that that's the only part that's different in
your proposal.

I think there's a concern with this approach though.  I don't believe we
can just come up with something new on the standards track and then go hit
operators over the head with it telling them they're non-compliant.  That
tends not to be well-received, to put it lightly.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Apr 2015 17:56:44 -0400

> Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such…

Yes.  To be protocol Z-ORDER correct, yes.

> So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant?

It would be violation of he protocol engine -- causing potential grief.

> That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC chec…

As DMARC is written yes, this is why we need the 3rd party 
authorization. It is incomplete otherwise.

> Then, if the market deems DMARC valuable by itself, pressure would be applied by the "invisible hand" there were it needs to be applied (so that reputable actors in the email ecosystem could claim…

Can't have it both ways.  If a MLM has resigning and touching based 
with DKIM, it needs to filter the unauthorized DMARC mail at the MLM 
receiver just like their is a presumption the distribution end-user 
MDA receivers will also apply DMARC.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Apr 2015 18:11:57 -0400

> etc.  Since there are no internet police, can not doesn't mean anything.

Lets not lump "mailing list" into the same kind or group of MLM 
operations. I care. I have a product to market.    As a side note, 
there is a legal argument to make when a MLM has intentionally ignored 
a security protocol designed to protect a domain and end-users. 
Claims of MalPractice and Intentional Neglect can easily be made. 
There is most certainly, product liability issues.  Can't have it both 
ways.

The point is not what the MLM does, but what the MLM RECEIVER does. 
It MUST also be a DMARC compliant system too as a protocol design 
presumption.

So as I always said, the first rule of thumb is to follow the honor 
protocol first.  And if that doesn't make sense, then its broken. 
DMARC is an incomplete protocol until it offers support for ADID != 
SDID conditions whether its deemed feasible or not by some.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Apr 2015 18:20:51 -0400

On Monday, April 27, 2015 06:11:57 PM Hector Santos wrote:
> > All they care about is getting the mail delivered, managing subscriber
> > lists, etc.  Since there are no internet police, can not doesn't mean
> > anything.

I'm not aware of any cases where someone was successfully sued for not 
implementing something that's optional.

> SDID conditions whether its deemed feasible or not by some.

As a mail receiver, they can accept or reject mail based on DMARC policies and 
be compliant as a receiver.  That helps not at all when the mediator later 
modifies the message so a DKIM signature breaks.

DMARC may be incomplete, but it's sufficiently complete for large scale 
deployment.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Apr 2015 18:36:01 -0400

> implementing something that's optional.

Reread what I said. There is most certainly product liability 
concerns. You don't have to wait until a lawsuit occurs to know what 
is the ethical, common sense engineering thing to do that will 
minimize both technical and legal contention.     The dilemma with 
this is the same as it was ADSP -- the MLM receiver can not skip a 
DKIM policy protocol and also do resigning.

With a 3rd authorization scheme in place, the MLM SHOULD only work on 
the relaxed policies.

> modifies the message so a DKIM signature breaks.

If the policy is relaxed, then it doesn't matter.

> DMARC may be incomplete, but it's sufficiently complete for large scale

Dimensional Analysis  -- what works for the smallest dimension will in 
theory work at any dimension.

Anyway, we have been saying that since day one -- DKIM POLICY highest 
benefit is the direct 1st party signature polices and that satisfies 
MOST domains.

But we still have the indirect problem because both ADSP and DMARC 
lacks the ADID != SDID protocol semantics.  ADSP punted on it. DMARC 
tries to punt on it and we should not be surprise we are finding they 
can't.

If they want to punt on it, then they MUST honor the restrictive 
policies at the MLM receiver, at the entry point.  That is all the 
point was.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Apr 2015 10:39:53 +0900

> Originator-Receiver agreements?

The effects are different.  According to DMARC, a message which passes
at the Mediator, will fail at the next Receiver.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 27 Apr 2015 18:44:38 -0700

> But in this case, silence definitely does not mean consent.

+1.

Cheers,
  Steve

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Apr 2015 13:11:33 +0900

J. Gomez writes:

 >     That would force DMARC-compliant Mediators to reject (or accept
 >     but not resend) incoming email from p=reject domains,
 >     irrespective of whether such mail passes or not the initial
 >     incoming DMARC checks.

Yahoo! and AOL are bigger than MLMs.  MLMs would bear the brunt of
user rage at that treatment.

Really.  We now have a couple of decades of experience.  The big
mailbox providers have our subscribers by the short hairs -- their
Internet reputations are intimately tied to those email addresses.  If
the big provider won't change (and historically they've followed the
principle of throw the garbage in their neighbor's yard and protest
innocence loudly when users question them), then the subscriber/poster
screams at the list owner.  They're typically much less attached to
their ML subscriptions than to their email addresses, and list owners
tend to be much more responsive to their subscribers than big mailbox
providers are.  We have to jump through their hoops, or at least our
list owner constituency thinks they do.

I'm an economist even before I'm an MLM developer, I'm willing to go
with the market if there is no market failure.  But here there is a
failure: email address lock-in.  On many lists, the AOL and Yahoo!
users are a small minority.  If "customer is always right"
considerations mandate catering to their mailbox providers' DMARC
policies, the great majority loses MLM features they value -- but they
are unlikely to kick up a corresponding fuss.

I'm quite sure that the market test will give the answer "knuckle
under", regardless of whether the majority of AOL and Yahoo! users
would prefer to keep the current MLM features or not.  They don't pay
for AOL/Yahoo!/GMail/Hotmail MUA dev costs, so those providers have
very little incentive to respond positively to their requests to
support MLM features better.  And, in fact, they WONTFIX them
regularly (dunno about Hotmail, but GMail is as bad as the others in
this respect).

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Apr 2015 13:33:23 +0900

> it's merely recording the fact that MLMs technically violate the SHOULD NOT.

AFAICS the "new message" referred to there is from the point of view
of the SMTP protocol, not the higher level of RFC 5322.  In
particular, RFC 5322 says that it the message is a "new message" at
this level, Message-Id should change too.  That would clearly screw up
list traffic processing for many users.

RFC 5598 itself says:

   In addition to sending the new message to a potentially large
   number of new Recipients, the Mailing List can modify content, for
   example, by deleting attachments, converting the format, and adding
   list-specific comments.  Mailing Lists also archive messages
   posted by Authors.  Still the message retains characteristics of
   being from the original Author.

In particular,

      RFC5322.From:  Set by - original Author

         Names and email addresses for the original Author of the
         message content are retained.

 > that we accept based on how "SHOULD NOT" is defined in RFC2119?

It's not a violation IMO.  See below.

 > 2) Is the MLM emitting a new message?  I would agree with Michael

See the discussion in RFC 5322 about when a new Message-Id should be
assigned.  Specifically, from sec. 3.6.4:

      In all cases, it is the meaning that the sender of the message
      wishes to convey (i.e., whether this is the same message or a
      different message) that determines whether or not the
      "Message-ID:" field changes, not any particular syntactic
      difference that appears (or does not appear) in the message.

Here, sender refers to the MLM, and in most cases (not all!) the MLM
intends that the distributed message be considered the same as the
received message.  Further more, human recipients rarely have any
trouble distinguishing the MLM decorations and extracting the original
message.  MLMs which delete MIME parts and translate HTML to plain
text are another matter, but even there I believe that both senders
and recipients agree that it is the "same message".  If (human) sender
and recipient agree on this, I see *zero space* for the interpretation
that it's a new message, unless you deprecate RFC 5322 at the same time.

As I wrote elsewhere, the only people who ever claim that list
messages as distributed are new messages in the sense of RFC 5322,
sec. 3.6.4, are non-participants in almost all of the mailing lists on
which they want to impose this interpretation.

 > and contend that it is if there have been any content changes at
 > all, in the same way that someone making a compilation of a series
 > of independent works (a "mix tape") owns the copyright on the mix,
 > though not on the original material.  Now, MLMs do that with
 > digests already -- who else could one legitimately put in the From
 > of a digest? -- but typically not for resent messages.

As long as you mention copyright, it's likely that the material
typically appended by MLMs is not copyrightable, it's mostly
determined by the MLM's interface (eg, unsubscription and archive
URLs), and the rest is hardly an original work of expression.  So the
copyright analogy says there is no ground for claiming the MLM is an
author.  Not even in the case of deletion or transformation of MIME
parts -- when automated, these are also not "expressive works".

 > "Author-Message-ID" or "List-Original-Message-ID" field that
 > contains the author-generated Message-ID, allowing for the
 > duplicate suppression that's done now?

It's not just duplicate suppression, it's also threading, because some
people have mixed sources for messages in the thread.

That screws all existing MUAs in processing dupes and threading
messages when some are received via and some off- list.  Even once
they are taught recognize Original-Message-ID, the threading algorithm
will become *much* more complex.

Somebody, perhaps this WG or more likely an appropriate WG with input
from us, just needs to decide this issue one way or the other.  If
it's decided that MLM decorations create "new messages", and that
therefore MLMs must provide new From and Message-ID values, I suspect
we can expect widespread violation from existing lists indefinitely.

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 28 Apr 2015 08:12:53 +0200

On Tuesday, April 28, 2015 3:39 AM [GMT+1=CET], Stephen J. Turnbull wrote:

>  > > actually liked by any user.  Therefore we developers continue to
>  seek > > alternatives -- but all desirable alternatives require
>  cooperation of > > "p=reject" posting domains because of the nature
>  of current validation/ > > authentication protocols as
>  Originator-Receiver agreements. >

That is why it would be appropriate for the DMARC spec to explicitely say that a "DMARC-compliant Operator" CANNOT accept messages from p=reject domains AND then reinject them into the public email infrastructure in any why that would make them (or reveal them to be) susceptible to fail a DMARC check performed by the next-hop Recipient. The DMARC spec should declare that if any email operator did that, he could not be termed as "DMARC-compliant". Because if any email operator does that, he is in fact polluting the global email traffic stream with non-authorized email according to the public policies declared by DMARC-compliant original Senders.

So that: to be a "DMARC-compliant Operator", it would be required to be (1) DMARC-compliant when performing the role of Receiver, and also to be (2) DMARC compliant when performing the role of Sender. So that lacking (1) or (2) it would render the email operator as non compliant with DMARC.

DMARC-compliant Operator == DMARC-compliant in the role of Receiver + DMARC-compliant in the role of Sender

Regards,
J.Gomez

---

From: Michael Jack Assels <[email-masked]>
Date: Tue, 28 Apr 2015 09:00:52 -0400

On Mon, 27 Apr 2015 11:44:38 PDT, 

> particularly rigorous about this.

In the context I was considering -- one in which the message had been
reversibly transformed as indicated in draft-kucherawy-dkim-transform-00
and reversibly transformed by adding tags "ftf=" (From TransFormed) and
"stf=" (Subject TransFormed) -- the initial Author's message is entirely
contained in the "new" message, and it's easily reconstructed from the
"new" message.  A downstream Receiver can reconstruct the original message
such that the reconstructed message passes the original DKIM test and
aligns as required by DMARC.  By hypothesis, since the transformed message
has changed enough to invalidate the original DKIM signature, the MLM has
also signed the transformed message (with its mailbox appended to the
5322.From header.)

Given that the message has been transformed, the question arises whether
it's "the same" as the original or not.  Obviously it's not strictly
identical, but equally obviously (at least in the case of normal mailing
list decorations) it's not significantly different; it lies somewhere in
the continuum between strictly identical and significantly different.
According to RFC 5322, section 3.6.4:

      [...] In all cases, it is the meaning that the sender of the message
      wishes to convey (i.e., whether this is the same message or a
      different message) that determines whether or not the "Message-ID:"
      field changes, not any particular syntactic difference that appears
      (or does not appear) in the message.

I can't see a reading of that sentence that would require a new Message-ID
on a single message as transformed automatically by an ordinary mailing
list.

> it's merely recording the fact that MLMs technically violate the SHOULD NOT.

Right, although that had already been a long-standing and widely accepted
practice long before RFC5598 was published in July 2009.  Adherence to the
normative RFC5322 counts for more, I'd say.

> for too long, but we can't change history.

Yup.

> legitimately put in the From of a digest? -- but typically not for resent

My view is that it's a "new" message in the sense that it breaks a
DKIM signature, but not RFC5322's sense of changing the meaning of the
original author's message, so the Message-ID should stay the same.

Of course, this is assuming normal mailing list handling.  Ne'er-do-wells
might take advantage by making the standard reversible transformations
but adding large chunks of spam.  In such a case, it would at least be
clear that the original author's domain was only responsible for the
original message, and the ne'er-do-wells' domain for the rest.  Normal
spam/phishing filtering can still be deployed, and who knows; maybe MUAs
might even help out by marking the differences for the human recipients.

> as the From change: If the content changes, it's a new message, and it gets

I think that's too strong, but I wouldn't go to the wall defending that
position.

> author-generated Message-ID, allowing for the duplicate suppression that's

That could work, too.

> information is presented by a multi-From message and perhaps why, and hope

Agreed.  I really wouldn't even contemplate dictating standards for MUAs.

MJA

---

From: Michael Jack Assels <[email-masked]>
Date: Tue, 28 Apr 2015 09:39:33 -0400

On Mon, 27 Apr 2015 12:38:15 PDT, 

> the standards we're talking about, and how MUAs need to be nudged to make

We're not all going to concur, but let me chime in anyhow:

The ordering of "Authors" in the From ought to be fairly easy.  In any
applicable case, there will be at least two DKIM-Signatures, of which one
(the list's) will be valid, and the other (the original Author's) will
be invalid by itself.  The list's valid signature includes (e.g.) "fsf=2",
indicating that the From-transformation added the second From mailbox, so
that the first is the original Author's.  Reconstruction the original
message my reversing all reversible transformations should result in
a message for which the original Author's DKIM signature is valid,
confirming that the first mailbox in the "new" message is the original
Author's.

(Here, I'm assuming that the consensus that we won't reach would want
the From order to match the temporal order of mailbox addition.)

Some gentle suggestions for MUAs:

1.  Display the whole 5322.From header, as well as the Sender.

2.  In the absence of "Reply-To", replies should go to the
    first 5322.From mailbox, and reply-to-all to everybody.

MJA

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Apr 2015 09:49:50 -0400

On 4/27/2015 2:44 PM, Murray S. Kucherawy wrote:

> 1) Is the MLM violation of the SHOULD NOT cited above the kind of
> violation that we accept based on how "SHOULD NOT" is defined in
> RFC2119?  It seems to me that it is, especially given how long they've
> been doing it without objection (until now).  One could argue they've
> been "getting away with it" for too long, but we can't change history.

For the record, there was objection in DKIM-WG and in particular cited 
with the deployment guide and also with the requirement guide where 
the integration conflicts was obvious.
> contend that it is if there have been any content changes at all, in
> the same way that someone making a compilation of a series of
> independent works (a "mix tape") owns the copyright on the mix, though
> not on the original material.  Now, MLMs do that with digests already
> -- who else could one legitimately put in the From of a digest? -- but
> typically not for resent messages.

Its not a new author message.   It is how the MLM massages the 
submission for redistribute for an One to Many groupware logic. MLM is 
technically an Email Kludge for an electronic messaging conferencing 
system.  It is at best a "repackaged" message.  But its not a "new" 
message per se that would warrant any kind of idea for rewriting the 
Mail Infrastructure persistent and consistent "From" field.   Reply-ID 
is already on "iffy" grounds but it was done, pointing the mail back 
to the list in the name of reducing unintentional direct messages in 
legacy MUAs with layman users doing the most naturally thing.  List-ID 
were still not widely adopted or around the time.

A Digest would be a new message -- because not one list author created 
it.  The MLM created it.

-- 
HLS

---

From: Michael Jack Assels <[email-masked]>
Date: Tue, 28 Apr 2015 10:12:19 -0400

On 27 Apr 2015 21:29:51 -0000, 

> anything useful, and I suspect I am far from the only one.  

This is merely an attempt to find a mechanism whereby DMARC and MLMs could
cooperate, up to the point where subscriber Recipient validators could
honour an Author domain's p=reject, without removing the original author's
mailbox from the From header.

> But in this case, silence definitely does not mean consent.

Fair enough.  For my own part, I'd be happy enough to see the
list mailbox stripped from the From header after validation, but I can
already hear a deafening silence from people not consenting to that.

MJA

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2015 12:51:42 -0400

> mailbox from the From header.

Unless I've missed something, I don't see how this solves any of the well 
known problems.  Bad guys can do whatever lists do, so you need to know 
whether to trust the list, at which point you might as well just trust the 
list and not mess around with the headers.

Also, if you want to go down the sender + list route, how about that 
double DKIM signing hack?  It has the advantage that it's invisible to 
MUAs and doesn't affect reciepient MTAs beyond the DKIM validation code 
which probably comes from a library that Murray wrote.

Regards,

---

From: Franck Martin <[email-masked]>
Date: Tue, 28 Apr 2015 13:12:58 -0500 (CDT)

----- Original Message -----
> From: "Scott Kitterman" <[email-masked]>
> To: [email-masked]
> Sent: Thursday, April 16, 2015 7:11:14 AM

> indirect

Was not in dmarc-interoperability, surprisingly, added

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 28 Apr 2015 20:18:44 +0200

> user rage at that treatment.

So do you think it is proper for an email actor to knowingly inject DMARC-rejectable messages into the public email infrastructure? Because that is exactly what mailing lists are doing when: (a) they check DMARC for incoming email (therefore, they are DMARC-aware), and (b) they then reinject into the public email infrastructure messages whose original Author's domain has declared p=reject.

That case I think looks like utter disregard for a standard they know about (DMARC), in the name of convenience. If a mailing list was DMARC-agnostic, i.e. it didn't care about DMARC and didn't check it for incoming email, I would have no problem with such mailing list also disregarding DMARC when reinjecting messages. However, if a mailing list cared about DMARC when receiving, I think it SHOULD also care for DMARC when sending (and therefore NEVER reinject DMARC-rejectable messages into the public email infrastructure).

> regularly (dunno about Hotmail, but GMail is as bad as the others in

Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they kept publishing p=reject and MLMs decided to be DMARC-compliant when reinjecting messages.

Regards,
J.Gomez

---

From: Terry Zink <[email-masked]>
Date: Tue, 28 Apr 2015 18:26:00 +0000

> Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they
 > kept publishing p=reject and MLMs decided to be DMARC-compliant when 
> reinjecting messages.

I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo and AOL pushed their problems onto everyone else", etc. I don't think it's useful to blame Yahoo and AOL for everything. What happens when Hotmail.com, outlook.com, and gmail.com start publishing p=reject? Are we going to say "The big four email providers pushed their problems onto everyone else" ?

Then, if other big email providers in non-American markets (mail.ru, orange.fr, etc.) start doing it, are we going to say "Everyone but me pushes their problems onto the smaller providers" ?

-- Terry

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2015 18:35:36 -0000

> Are we going to say "The big four email providers pushed their problems onto
>everyone else" ?

Yes, of course.  But as we've seen, we have little ability to push
back.

R's,
John

---

From: Michael Jack Assels <[email-masked]>
Date: Tue, 28 Apr 2015 16:54:14 -0400

On 28 Apr 2015 12:51:42 EDT, 

> list and not mess around with the headers.

The main difference is that the original Author's message, including
5322.From, is precisely reproducible (modulo canonicalization changes) from
the message sent to the list, and will match the original DKIM-Signature
with the required 5322.From alignment.  If it doesn't, the final Receiver
should do what RFC7489 says it should do:  "[A]pply the most strict policy
selected among the checks that fail."

Yes, bad guys can do whatever lists do, but in this case, they'll need to
piggy-back on a recent DMARC-passing message sent legitimately to them from
the originating domain with a p=reject policy, and they'll have to include
that message in its entirety, including all the signed headers, in their
spam/phishing message; they can't simply replace the original message with
their own.  It seems much easier just to open a disposable account at a
p=reject ESP and send the spam directly from there.

> which probably comes from a library that Murray wrote.

I'll grant the advantage of invisibility to MUAs, but double signing has the
disadvantage that the originating signer has to know when to add a weak
signature with an fs=lists-r-us.com tag.  What I'm suggesting doesn't need
the originating signer to have any special knowledge.

There's another, slightly labour-intensive approach (still dependent on
Murray's draft-kucherawy-dkim-transform-00, and an extra "stf=" tag for
subject tagging) that doesn't modify 5322.From:

1.  The list keeps the original author's mailbox alone in the From header,
    but makes the reversible transformations described, and adds a DKIM
    signature with d=list.domain and tf= and stf= tags.

2.  The "decorated" message is sent to list members with list-domain address
    as Sender.

3.  Recipient validators find an Author Domain signature that fails, and
    a Sender Domain signature that is valid but doesn't align with the From
    Domain.

4.  Because the Sender Domain signature is valid and contains tf= and stf=
    tags, Recipient validators reconstruct the original message and check
    it against the Author Domain DKIM signature.  If it passes, the message
    is deemed to pass DMARC; otherwise it fails.

I'm not sure if that's an improvement on the multimailbox From approach,
but at least it leaves no burden for MUAs (unless they happen to be
validators).

MJA

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2015 17:04:31 -0400

>    tags, Recipient validators reconstruct the original message ...

Oh, it's message wrapping.  There are easier ways to do that without 
changing DKIM: have the list send the message as a single entry MIME 
digest.  Mailman already knows how do to that, and in the extremely 
implausible event that you can persuade MUAs to do message reconstruction, 
it's easy to unwrap using existing tools.

Regards,

---

From: Franck Martin <[email-masked]>
Date: Tue, 28 Apr 2015 16:04:52 -0500 (CDT)

----- Original Message -----
> From: "Rolf E. Sonneveld" <[email-masked]>
> To: "John Levine" <[email-masked]>, [email-masked]
> Cc: [email-masked]
> Sent: Thursday, April 16, 2015 3:21:33 PM
> Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
> 
Personally, I consider this a bug, because it looks like to C that B invited him/her, while it was A that did.

This bug is on the wiki, but it falls under the "Message Forwarding" section, not sure we need to spell it out there, but it is not uncommon.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Apr 2015 14:08:47 -0700

> Yes, of course.  But as we've seen, we have little ability to push

Dear John,

Standing up to abusive domains requires a fallback policy
compatible with SMTP.

https://tools.ietf.org/html/draft-otis-dmarc-escape-01

Describes a safer and SMTP compatible policy as "Public". 
By ignoring the role of Sender DMARC is not compatible with
SMTP which leads to dangerous practices when handling email
exchanges serving the general public.  Hacks aimed at
transforming the From header into playing this role, such as
the dubious double signing or proposed reversible
transformation are solutions making the problem worse.

Why make the source of a message more confusing?  A role
clearly defined by the Sender header field when present.

The efficiency hack used by DMARC for applying policy
against transactional messaging fails badly when misapplied
against mediated and valid third-party services.

Regards,
Douglas Otis

---

From: Franck Martin <[email-masked]>
Date: Tue, 28 Apr 2015 16:34:28 -0500 (CDT)

----- Original Message -----
> From: "Terry Zink" <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, April 28, 2015 11:26:00 AM
> I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo
> and AOL pushed their problems onto everyone else", etc. I don't think it's
> useful to blame Yahoo and AOL for everything. What happens when Hotmail.com,
> outlook.com, and gmail.com start publishing p=reject? Are we going to say
> "The big four email providers pushed their problems onto everyone else" ?
> 
> Then, if other big email providers in non-American markets (mail.ru,
> orange.fr, etc.) start doing it, are we going to say "Everyone but me pushes
> their problems onto the smaller providers" ?

I think we should refrain to blame anything or anyone. It is what it is, and we should just note it, technically describe it, and see if better solutions can be provided. This atmosphere is not conducive for group work.

---

From: Franck Martin <[email-masked]>
Date: Tue, 28 Apr 2015 16:35:26 -0500 (CDT)

----- Original Message -----
> From: "Franck Martin" <[email-masked]>
> To: "R E Sonneveld" <[email-masked]>
 
> This bug is on the wiki, but it falls under the "Message Forwarding" section,
> not sure we need to spell it out there, but it is not uncommon.
> 
Correction it is described in the draft and still is...

---

From: Michael Jack Assels <[email-masked]>
Date: Tue, 28 Apr 2015 18:56:24 -0400

On 28 Apr 2015 17:04:31 EDT, 

> it's easy to unwrap using existing tools.

I think I've failed to communicate.  Yes, the pristine original message
will be appropriately MIME-wrapped, with the list decorations becoming
separate MIME parts, but the MUA is not expected to do anything except
to present the MIME message to the final recipient.

The message reconstruction is to be done by the validator at the
recipient's end, which will presumably be an MTA because it has the job
of accepting or rejecting messages.  The only reason for reconstructing
the original message is to let DKIM check the validity of the From-aligned
signature against the original message.

Apart from the addition of tags, there isn't much change for DKIM.  What
changes is the algorithm used by DMARC in the special case where there
exists a From-aligned but invalid signature and a Sender-aligned valid
signature specifying the tf= tag and (if there's a consensus) an stf=
tag.

MJA

---

From: "John R Levine" <[email-masked]>
Date: 28 Apr 2015 19:25:36 -0400

> to present the MIME message to the final recipient.

Discussions on the Mailman list say that users hate wrapped messages, 
because in most MUAs they look really ugly.

> signature specifying the tf= tag and (if there's a consensus) an stf=

I still don't see what the advantage is compared to a single message 
digest which requires no changes to DKIM, no changes to DMARC, and has 
already been implemented in a widely used list manager.  The only downside 
is that it looks awful in most MUAs so users hate it, which I expect would 
also apply to your proposal.

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 29 Apr 2015 13:36:37 +0900

John R Levine writes:

 > Discussions on the Mailman list say that users hate wrapped
 > messages, because in most MUAs they look really ugly.

It's worse than that.  As of 6 months ago, it was impossible to read
wrapped messages (as implemented by Mailman, anyway) in Apple Mail for
iOS.

As for "really ugly", in MUAs that can read it but do nothing special
(all MUAs that can read it AFAIK) it looks like a bare digest of a
single message.  My feeling is that users think it looks *stupid*, not
ugly, and posters at p=reject domains (the recommended configuration
for Mailman does the DNS lookup so only p=reject domains are wrapped)
complain about discrimination.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 29 Apr 2015 16:09:18 +0900

Franck Martin writes:

 > I think we should refrain to blame anything or anyone.

I think that there is no solution attractive to email users possible
without naming names.

AFAIK[1], it is a fact that the problems that have made "DMARC" a
four-letter word across the Internet are almost entirely due to the
unilateral decisions to publish "p=reject" by *two* domains.  Call
that "blaming" if you like, but that fact matters because any *good*
mitigation[2] involves their participation.

The only alternative I can see to participation by those specific
domains (and any domains producing similar mailflows that may publish
p=reject in the future) is a general agreement among DMARC receivers
to treat "p=reject" as purely advisory (say, -2 spam points if
alignment is verified in SpamAssassin).  I know you don't like that
weakening of the protocol, and I don't think it's a good idea, either.
DMARC is a great protocol for direct mail streams, proven in practice.

Two?  Yes, *two*.  Bank of America?  No problem, it's all direct mail.
LinkedIn?  Who cares?  Pretty clearly linkedin.com employees have
figured out that posting to MLs from that domain is not good for
their ability to communicate, and LinkedIn itself primarily uses
*direct* mail to collect traffic to their website.  Accidental leakage
from either kind of domain is no big deal and self-correcting.

Why single those two out?  Because they've already demonstrated that
they place their own security issues over the general functionality of
the mail system, so it's questionable whether they will buy in to any
solutions we come up with.  We already know that there may be security
issues (DKIM delegation-style proposals) or significant costs (TPA via
DNS-style proposals) to implementing those solutions.  The best way to
get an answer about what *they* want in a solution is to ask them.
For that, we need to say their names.

And if those two buy in, I think there will be huge pressure on any
future p=reject-niks to participate in the mitigation protocols, even
if not 6-sigma secure or involving additional nameservers or other
costs.

 > It is what it is,

Indeed, and what it is, is a purely private protocol whose own
specification deprecates the controversial use case.  Don't forget
that fact.

 > and we should just note it, technically describe it,

It had better not stay what it is!

One thing that is easy to forget and to ignore is that, without a
practical third-party authorization protocol, "p=reject" from even one
large group of mail users has a chilling effect on all *new* third-
party mail services.  A large service with an established user base
such as Intuit's invoicing service can weather even something like
what happened in April 2014, but I wonder how many new 3rd-party
services rolled out in first quarter of 2014 just died without even a
whimper because of how "unreliable" they were for ordinary mail users
at p=reject domains after April.  I wonder how many 3rd-party services
won't ever be implemented commercially for that reason.

Yes, as written those stillborn services are just FUD, but economists
have ample evidence that removal of apparently minor hindrances can
invigorate innovation and the general business climate.[3]  Don't
deprecate the potential for innovation just because I'm unable to
provide figures for the case of 3rd-party email offhand -- these
things are essential impossible to measure in advance.

 > and see if better solutions can be provided.

They can only be "provided" if the unblameable domains implement,
because as DMARC is currently specified "p=reject" is a unilateral
decision by the Author Domain.  Otherwise, the solutions aren't worth
the paper they won't be printed on.

 > This atmosphere is not conducive for group work.

The deafening silence of the "p=reject" domains which originate large
general-use mail streams as to how they will contribute to mitigation
of the bad effects of their DMARC policies isn't conducive to group
work, either.

I've observed that posters here consistently categorically reject
potential solutions as unworkable based on FUD about DNS costs and
insecurity and inability to scale user profiles that specify per-user
"trusted 3rd party" lists, despite the fact that representatives of
these two domains haven't even commented on them.  That fact matters
because nobody who doesn't (1) originate general-use mail streams and
(2) publish "p=reject" has to pay those costs, and at present they are
only ones that satisfy both criteria!

Footnotes: 
[1]  If I am ignorant of relevant facts, please inform me.

[2]  Conforming to existing normative RFCs and meeting the
requirements of *email users* as expressed to the providers of
services they use.  Eg, "author appears in From on mailing list
posts".

[3]  Two cases in point.  1. Relaxation of airline regulation.  Air
travel in the U.S. today is much cheaper, more flexible, and
(remarkably) safer than it was up to the 1970s.  2. Relaxation of
postal and transport regulation, without which the amazing progress in
logistics that makes Amazon.com a dominating presence in the book-
selling industry could not have occurred.

---

From: Michael Jack Assels <[email-masked]>
Date: Wed, 29 Apr 2015 07:54:40 -0400

On 28 Apr 2015 19:25:36 EDT, 

> because in most MUAs they look really ugly.

OK, I'll concede that.  They don't bother me, but I don't count for much.

> already been implemented in a widely used list manager.

Do single message digests get sent with the original Author's mailbox in
the From header?  If so, there's no advantage at all, but I have the
impression that digests in general are sent "From" the list.

> The only downside is that it looks awful in most MUAs so users hate it,
> which I expect would also apply to your proposal.

I'm still hoping for something that users will like, so I guess it's back
to the drawing board.

MJA

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 29 Apr 2015 21:04:37 +0900

> > >     irrespective of whether such mail passes or not the initial

Something about having mediators (ie, non-MTAs) implement this check
was bothering me.  I realized that the nagging thought was the
*Mediator* doesn't have to do it.

Variation A:

The *outgoing MTA* can do this check; it has the same information (the
"From" field, the DKIM signature, and the DNS) that the mediator does.
This outgoing check is just a variation on the spamfighting theme of
"if pretty much anybody can send from your system, you have to check
outgoing mail as well as incoming mail."

Having the outgoing MTA do the check has the following advantages:

- MTAs already have to implement DMARC logic; Mediators would not have
  to.
- Where the outgoing MTA is also the incoming MTA (or they can
  communicate), the DMARC policy can be cached, possibly avoiding a
  DNS check.
- When the outgoing MTA rejects based on next-hop DMARC rejection, it
  can inform the Mediator of the reason for rejection (which SMTP
  servers often fail to provide to the SMTP client).  This is actually
  important to MLMs, at least, which often count bounces and disable
  or cancel subscriptions based on the result.

Disadvantages:

- Naive MLMs (and perhaps other Mediators) can generate many copies of
  a single message, and present them individually to the MTA.  It
  would be better to do the detection at addressee generation time in
  the MLM.  Note: this may not be as expensive as it seems at first
  glance, as given the Message-Id and the addressee, the result is
  known without doing any further checks.  Many MTAs do parse out the
  Message-Id, for reporting in logs if nothing else.

I'm not a big fan of rejecting mail in this way, but it also led to
the thought that it would be nice to be able to avoid the somewhat
finicky DNS checks in Mediators that want to be DMARC-aware.  Thus
variation B.

Variation B:

When the incoming MTA knows the local recipient is a Mediator, it
could perform the policy lookup even for From-aligned messages, and
communicate that (perhaps in the Authorization-Results field).  I
doubt that this could be more efficient, but again the implementation
would be done in MTAs, which have to do it anyway.

---

From: "John R Levine" <[email-masked]>
Date: 29 Apr 2015 09:11:57 -0400

> I'm still hoping for something that users will like, so I guess it's back

The usual next step is to write up the proposal as an I-D and send it in, 
so we have a concrete description.  Even if we decide not to use it, 
having a spec to refer to is often useful when looking at future 
proposals.

Regards,

---

From: Michael Jack Assels <[email-masked]>
Date: Wed, 29 Apr 2015 09:26:58 -0400

On 29 Apr 2015 09:11:57 EDT, 

> having a spec to refer to is often useful when looking at future 

Right.  I'd been avoiding that because I saw this as a relatively minor
change to Murray's draft-kucherawy-dkim-transform-00, but if message
wrapping is considered a nonstarter, a new I-D is in order, assuming that
there's a simple, secure, and palatable way to divide any arbitrary message
body into its "original Author part" and "list decoration part(s)",
irrespective of the Author's part being good-ol' text or MIME.

MJA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Apr 2015 08:28:13 -0700

> irrespective of the Author's part being good-ol' text or MIME.

Since we're just throwing out ideas, I don't mind adding your "stf" idea to
the transform draft.  Just send me some text.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Apr 2015 12:14:44 -0400

Side note: DMARC is not a BCP, nor a Proposed Standard. It has an 
Informational Status. DMARC is very much incomplete.

> *Mediator* doesn't have to do it.

In the SMTP world, all receivers are expected to play by the same 
"interop" rules. We have "standard" expectations and best practices 
among SMTP mail systems.  A SMTP receiver is a SMTP receiver.  It is 
really all mechanical.  The "Mediator" is just one or many types of 
"mail services" that is a post SMTP operation.  There is no such thing 
as a MLM receiver unless its behaving like an "open relay." The goal 
with any SMTP level deterministic policy protocol is to:

  1) Protect Receivers from Abuse
  2) Protect Originator Domain from abuse
  3) Protect End-Users from Abuse

All three have benefits when everyone is expected to follow the 
"protocol standard" and its really in the above order.  In other 
words, I'm adding support not to just protect domains or the end-user, 
its controlling and helping to reduce  the tremendous abuse the 
receiver sees on a constant basis.

We are looking for a persistent, consistent protocol that ALL SMTP 
receivers can run and the end results is expected to be the same from 
node to node.  Like SPF, the DNS published rules, when applied 
corrected per specification, the result is the same at Receiver Nodes 
X, Y and Z.

> Variation A:  Outgoing Checking...
> Variation B:  Incoming Checking....

These are specific vendor implementation design details. It generally 
does not apply to IETF Protocol design because it wouldn't be 
applicable to all systems, including small guys.  Look at our 
integrated design (attached!)  Very complicated due to the history.

In other words, it doesn't matter how its done, whether you can do it 
or not or where, but from a functional protocol specification 
standpoint, that it is done, and that mean all nodes in the mail 
network, otherwise there are loopholes.

-- 
HLS

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 29 Apr 2015 21:35:32 +0200

> *Mediator* doesn't have to do it.

How is a Mediator not an MTA (among other things)? Didn't we agree that a Mediator is an actor that does both the role of Receiver (MTA-based) and the role of Originator (MTA-based)?

Original Originator ==> [ Mediator's Receiver role -> Mediator's internal process -> Mediator's Originator role ] ==> Final Receiver.

The important point is that "Mediator's Originator role" SHOULD NOT inject DMARC-rejectable messages into the public email infrastructure (but I don't care if the Mediator rejects[*] those messages at the point "Mediator's Receiver role", or at the point "Mediator's internal process", or at the point "Mediator's Originator role"; that is an implementation detail specific to each Mediator.

[*] I don't care also if the Mediator *rejects* those messages, or *forwards* them to /dev/null, or *transforms* them into non DMARC-rejectable messages. The point is: Mediator SHOULD NOT inject DMARC-rejectable messages into the public email infrastructure[**], how they achieve that is 100% up to them to decide/solve.

[**] And if they do inject them, then such Mediator SHOULD be labeled and non DMARC-compliant and the DMARC specification SHOULD spell out clearly that doing such a thing is a VIOLATION of the DMARC specification. (Keep in mind DMARC is not mandatory for SMTP, so email actors can always choose to be or not to be DMARC-compliant.)

Regards,
J.Gomez

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Apr 2015 19:37:40 -0700

> DMARC is a great protocol for direct mail streams, proven in practice.
Dear Stephen,

An update of Dmarc-Escape draft attempts to unbury what
should be a workable solution.  Once DMARC libraries are
updated to support an addition that includes a requested
policy of "public", the cooperation of problematic domains
should quickly become a minor concern.   Domains making
misleading assertions regarding their email alignment
practices, especially in regard to exchanges involving
public email would only require a small override to be
imposed where an inappropriate "reject" becomes "public". 
In that case, the Domain Owner wishes for Mail Receivers to
reject email that fails a modified DMARC alignment mechanism
check will now include the Sender header field or the first
email address in a multiple From header field.   Failure can
only result in Quarantine thereby making DMARC far more
compatible with SMTP while also better ensuring against
misleading policy assertions and undetected phishing.

Domain reputation remains an effective tool when narrowed to
specific criteria.  The current situation where Author
identity of a message being munged is not sustainable nor safe.

https://tools.ietf.org/html/draft-otis-dmarc-escape-02

Regards,
Douglas Otis