Re: [dmarc-ietf] Mediation

2020-06-22 Thread Jesse Thompson 
On 6/22/20 10:48 AM, Hector Santos wrote:
> Your domain has a restrictive DMARC policy. Here are your options:
> 
> 1) Use another non-restrictive domain,
> 2) Prevent your domain from subscription and submission, or
> 3) Authorize the Rewriting of your secured domain to a secured resigner 
> domain.

If those were the only choices then no EDU would publish DMARC policies. 

Jesse

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-22 Thread Hector Santos 

Mailman and Sympa seem to tbe the popular open source list managers.

LISTSERV is an expensive commercial product and is I gather popular
among users who have money to pay for an SLA.


Thanks, I've reached out to all three and will report back.



This exchange does not read right.

Decisions like this should not be made on the basis of open source, 
nor commercial.  The magical Pareto margin with just those three 
mentioned may not be reached. There are others out there that may not 
be represented in this group, and there are those like my own 
commercial add-on product line, Wildcat! List Server, which does come 
with an optional SLA and it should not matter if it does or not, a 
smaller entity but has been "around" far longer than most except ListServ?


https://secure.santronics.com/products/winserver/wcListServer.php

I provided a guideline to a MLS approach back in the 2006 DSAP proposal:

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

   3.3.  Mailing List Servers

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

   Subscription Controls

  MLS subscription processes should perform a DSAP check to
  determine if a subscribing email domain DSAP policy is restrictive
  in regards to mail integrity changes or 3rd party signatures.  The
  MLS SHOULD only allow original domain policies who allow 3rd party
  signatures.

   Message Content Integrity Change

  List Servers which will alter the message content SHOULD only do
  so for original domains with optional DKIM signing practices and
  it should remove the original signature if present.  If the List
  Server is not going to alter the message, it SHOULD NOT remove the
  signature, if present.

I have since then employed a very simple first item, Prevent 
Subscription, added preventing submissions from restrictive domains 
and avoided the more complex, integrity change part.


I understand there are those who want to bypass the DKIM Policy 
security to be able to blindly resign any domain regardless of the 
submission's direct mail policy. But my take is, if a MLS is going to 
"change" then we should recommend to consider the preemption approach 
by simply honoring the policy.


I hope to read from the report those 3 packages are willing to offer 
the option to prevent restrictive domains. Even if rewriting remains 
as an IETF "sanctioned" option (I hope not), the recommendation should 
suggest a SHOULD to incorporate it as an authorized permission concept 
with the subscriber:


Your domain has a restrictive DMARC policy. Here are your options:

1) Use another non-restrictive domain,
2) Prevent your domain from subscription and submission, or
3) Authorize the Rewriting of your secured domain to a secured 
resigner domain.


Thanks

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-21 Thread Murray S. Kucherawy 
On Sun, Jun 21, 2020 at 6:07 PM John Levine  wrote:
> In article 
>  you 
> write:
> >Apart from Mailman, what would be a reasonable set of MLMs to
> >approach?  I don't need a universal set here, just enough to get us to
> >at least what we are pretty sure would be 80% or better of the active
> >modern use cases.
>
> Mailman and Sympa seem to tbe the popular open source list managers.
>
> LISTSERV is an expensive commercial product and is I gather popular
> among users who have money to pay for an SLA.

Thanks, I've reached out to all three and will report back.

-MSK

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-21 Thread John Levine 
In article  
you write:
>Apart from Mailman, what would be a reasonable set of MLMs to
>approach?  I don't need a universal set here, just enough to get us to
>at least what we are pretty sure would be 80% or better of the active
>modern use cases.

Mailman and Sympa seem to tbe the popular open source list managers.

LISTSERV is an expensive commercial product and is I gather popular
among users who have money to pay for an SLA.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-21 Thread Dave Crocker 

On 6/21/2020 4:35 PM, Murray S. Kucherawy wrote:

Armed with such a list and a plan, I can see what the IRTF Chair
thinks of the idea.


cool!

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-21 Thread Murray S. Kucherawy 
On Sat, Jun 20, 2020 at 1:24 PM Dave Crocker  wrote:
> Perhaps if the effort were viewed as a staged sequence, over an extended 
> time.  Staging along the lines of:
>
> Document a modest number of highly common 'patterns' of mailing list patterns.
> * Get reasonable community support (rough consensus) for the document -- 
> including from MLM developers and operators
> * Formulate survivable authentication choices
> * Get reasonable community support for that approach

I'm curious enough (and have been since the discussions that led to
draft-kucherawy-dkim-transform-00 five years ago) to give this effort
some energy orthogonal to what this working group is doing, and with
minimum distraction.

Apart from Mailman, what would be a reasonable set of MLMs to
approach?  I don't need a universal set here, just enough to get us to
at least what we are pretty sure would be 80% or better of the active
modern use cases.

Armed with such a list and a plan, I can see what the IRTF Chair
thinks of the idea.

-MSK

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-20 Thread Hector Santos 

On 6/20/2020 11:53 AM, John Levine wrote:


It would be nice if you'd looked at my conditional signing drafts
before guessing (wrong) about what they say.

Here's the 2014 version:

https://datatracker.ietf.org/doc/draft-levine-may-forward/

And the improved 2018 version:

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/


Does this mean, the author, nows support and is going to champion his 
proposal?


I seem to recall in 2014, the author citing a lack of interest to 
pursue this and felt it would cause problems. As stated in the 2014 
security conditions, he wrote:


6.  Security Considerations

   DKIM was designed to provide assurances that a message with a valid
   signature was received in essentially the same form that it was sent.
   The forwarding signature condition deliberately circumvents that
   design, to create a loophole for messages intended to be forwarded by
   entities that edit the message.  It opens up a variety of obvious
   replay attacks that may or may not be important depending on both the
   selection of target domains for messages to be forwarded, and the
   behavior of forwarders that receive messages with conditional
   signatures.

I felt then it was another "poison pill" to kill the 3rd party 
authorization effort. I was not impressed but this so I putted on the 
proposal.


Now I read in the improved 2018 version:

6.  Security Considerations

   DKIM was designed to provide assurances that a message with a valid
   signature was received in essentially the same form that it was sent.
   The forwarding signature condition deliberately creates a loophole
   for messages intended to be forwarded by entities that edit the
   message.  It opens up a variety of obvious replay attacks that may or
   may not be important depending on both the selection of target
   domains for messages to be forwarded, and the behavior of forwarders
   that receive messages with conditional signatures.

   A sender can limit the conceptual size of the loophole by being
   selective about what other domains it allows in its !fs tags, and by
   using the x= tag to limit the time during which forwarded signatures
   are valid.

If the author still believes this loophole exist, why are we bothering?


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-20 Thread Dave Crocker 

On 6/20/2020 1:08 PM, Murray S. Kucherawy wrote:

It wouldn't be hard to put a draft together that described the trivial
things like Subject field tagging and "two dashes at the end mark the
start of a signature', and maybe a couple of popular and mostly
harmless mutations the popular list servers do.  I might know someone
who could help with such a publication.

(I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)



Were I to chortle about any of this, it would be at the idea that any 
serious effort associated with email authentication could be considered 
altruistic...


In terms of pragmatics, I think the issues here are time and risk.  To 
get to a useful point will take too long for the current working group 
effort, and, given history and environment, its likelihood of being 
successful seems pretty low.


That doesn't mean that none of it is worth pursuing, but rather than it 
might be worth considering independently of the current work and 
initially as IRTF-ish work, rather than IETF-ish.


Perhaps if the effort were viewed as a staged sequence, over an extended 
time.  Staging along the lines of:


 * Document a modest number of highly common 'patterns' of mailing list
   patterns.
 * Get reasonable community support (rough consensus) for the document
   -- including from MLM developers and operators
 * Formulate survivable authentication choices
 * Get reasonable community support for that approach
 * ...

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-20 Thread Murray S. Kucherawy 
On Fri, Jun 19, 2020 at 5:54 PM Dave Crocker  wrote:
> > I wish in hindsight I'd tried it
> > anyway as an experiment, with maybe a couple of senders, receivers,
> > and mailing lists as participants.
>
> While I can imagine devising something that would look appealing, I
> believe it would have had a foundation of sand, in terms of operational
> realities, since none of what it would be relying on was documented
> standards and, again, there was (and I suspect remains) a view that
> mailing list operators did not make good candidates for reliable
> adherence to IETF 'standards'.

All true, but if it had yielded useful results, there might have been
encouragement to change that.  Then, suddenly, there would be common
ground from which to do future work such as this.

It wouldn't be hard to put a draft together that described the trivial
things like Subject field tagging and "two dashes at the end mark the
start of a signature', and maybe a couple of popular and mostly
harmless mutations the popular list servers do.  I might know someone
who could help with such a publication.

(I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...)

-MSK

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-20 Thread Alessandro Vesely 
On 2020-06-20 5:48 p.m., John Levine wrote:
> In article  you write:
>> For example, a water tight opt-in protocol ...
> 
> There's no such thing, unless you can somehow ensure that the list never 
> sends anything that any of the subscribers don't expect.


Small MTAs can trust their (not anonymously registered) users, so they could 
blindly accept to weakly sign messages destined to a MLM that a user of theirs 
has implicitly recommended by starting such a (yet unspecified[*]) water tight 
opt-in.


>> Without that, we're back to depending on reputation, for which simple 
>> whitelisting suffices.> 
> No, please see my message a few days ago about why ARC works the way it does.


Do you mean 
https://mailarchive.ietf.org/arch/msg/dmarc/gll_AD80SzysVJi9GDeKM12OslA ?

That message proves that ARC depends on reputation too.  I mentioned 
whitelisting because it's simpler than ARC.

My point is that, if an MTA is not Google, Yahoo, or some such, that is if it 
doesn't have the list of all MTAs worldwide, then the mailing list problem 
precludes reliable DMARC inbound filtering.

I don't think, as Douglas suggests, that the MLM problem stems from not wanting 
to seek domain owner involvement.  IMHO, it stems from domain owners not being 
able to maintain a global reputation list.  The MTAs who can do that can do 
ARC, can whitelist, can do DMARC filtering; they don't have a "mailing list 
problem".


Best
Ale
-- 

[*] See rough ideas at http://fixforwarding.org/wiki/Water_tight_opt-in



























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-20 Thread John Levine 
In article <63ffc5ec-f5e3-4e15-9a1f-09bf00036...@email.android.com> you write:
>Just as significantly, tbe MLM does not want to sign the same document as what 
>was signed by the author.  If the document is unchanged, a conditional
>signature is not needed.  If tbe document is alrered after the first 
>signature, the first signsture is not applicable to the second signature.

It would be nice if you'd looked at my conditional signing drafts
before guessing (wrong) about what they say.

Here's the 2014 version:

https://datatracker.ietf.org/doc/draft-levine-may-forward/

And the improved 2018 version:

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-20 Thread John Levine 
In article  you write:
>For example, a water tight opt-in protocol ...

There's no such thing, unless you can somehow ensure that the list
never sends anything that any of the subscribers don't expect.

> Without that, we're back to depending on
>reputation, for which simple whitelisting suffices.

No, please see my message a few days ago about why ARC works the way
it does.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-20 Thread Hector Santos 

Pete, you should see my draft folder! 

On 6/19/2020 5:20 PM, Pete Resnick wrote:

On 19 Jun 2020, at 16:15, Pete Resnick wrote:


[Offlist]


Crap. My deepest apologies to Dave. I am very embarrassed by fat
fingering that. It is not the worst private thing I've ever sent to a
list, but still.

(*Sigh*)

pr


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-20 Thread Douglas E. Foster 
If conditional signatures require the participatuon of the author's MTA, then 
the consent of the domain owner is implied.   DKIM scopes already provide a 
solution for delegating authority, but the MLM problem stems from not wanting 
to seek domain owner involvement.

Just as significantly, tbe MLM does not want to sign the same document as what 
was signed by the author.  If the document is unchanged, a conditional 
signature is not needed.  If tbe document is alrered after the first signature, 
the first signsture is not applicable to the second signature.

On Jun 20, 2020 7:13 AM, Alessandro Vesely  wrote:On Sat 
20/Jun/2020 02:52:55 +0200 John Levine wrote:
> On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
>
>> A number of drafts were floated, as I recall.  I had a couple.
>
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.


Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.


Best
Ale
--


























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-20 Thread Alessandro Vesely 
On Fri 19/Jun/2020 23:11:27 +0200 Pete Resnick wrote:
> On 19 Jun 2020, at 15:07, Dave Crocker wrote:
>> On 6/19/2020 12:02 PM, Pete Resnick wrote:
>>> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>>>
 But typical mediators are trying to maintain a sense and ability
 for the original author and the final recipient to experience an
 end-to-end message exchange.
>>>
>>> Yep. That's the point I was trying to make.
>>
>> Except you seem to be pressing this as essentially a requirement
>> they have
> 
> Ah, no, I think that's the crux of the misunderstanding: I was
> responding to Alessandro, who I interpreted to be saying that *all*
> mailing lists were, by definition, publishers, defining a publisher
> like a newspaper, where the true author of the content are the folks
> in the masthead, even though they acknowledge individual authors in
> the by-line. I disagree with that view. Indeed, I think for most of
> the mailing lists we have been referring to in this discussion, they
> are not publishers in Alessandro's sense, but rather view themselves
> as redistributors of author messages. As 5598 points out, there is
> variance in how much "editing" is done by any given mailing list, but
> again, for the discussion we've been having about how the From: field
> should be used, we've been talking about mailing lists which do the
> sort of minimal editing of messages.


First, although the emphasis was on publishers, I didn't mean *all*
mailing lists.  Options 1.2 (Turn off all message modifications) and
4.5 (Have author domains sign camera-ready posts), with all in-between
variations (e.g. have users manually add the subject tag on new
messages, or attach a footer) are all valid alternatives.  And there
may be more (for this list in particular, it'd be enough for me to
convert the body to base64 before signing.)

Second, looking closely a the roles, what all mailing list do is
keeping the list of recipients.  Authors have no say on that, albeit
they can add a few "direct" recipients themselves.  Defining the end
points is an essential point in communication, which prevents from
considering the authors as agents.  Also consider that authors have to
keep on-topic, or they'd get reproached by the chairs.


> (For mailing lists that do more substantial editing, I may not be as
> motivated to keep the From: field unchanged. If we get more deeply
> into the discussion, it might be useful to start drawing more distinct
> circles around types of mailing lists.)


100% agreed.  We should also loosely consider that in most countries
there are legal constraints which practically force the addition of a
footer.  There are "informal" mailing list which ignore that pressure.

There will always also be mailing lists which ignore DMARC.  I don't
think the latter should be among the possibilities specified in a
standard.

>> That most seek to preserve essentially all of the author's text is
>> fine, but whether and how much is more of a 'business' decision than
>> a technical one.
> 
> We appear to be in violent agreement, as the quip goes. Importantly, I
> think we agree that if a mailing list decides to preserve the original
> From: field, in an attempt to preserve all of the author's semantics,
> they are not "doing it wrong", as Alessandro's message appears to claim.


What is wrong is to wittingly break DMARC.  I just try for rationale.


Best
Ale
-- 

























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-20 Thread Alessandro Vesely 
On Sat 20/Jun/2020 02:52:55 +0200 John Levine wrote:
> On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:
> 
>> A number of drafts were floated, as I recall.  I had a couple.
> 
> There's always my conditional signing hack, in which one puts a very
> weak signature on the message which says it only counts if it's
> resigned by X, where X is the expected mediator.


Conditional signatures should be paired with a mechanism that tells
the author's MTA when to apply them.  For example, a water tight
opt-in protocol whereby author, MLM, and author's MTA can do a
three-hand handshake.  Without that, we're back to depending on
reputation, for which simple whitelisting suffices.


Best
Ale
-- 


























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Dave Crocker 

On 6/19/2020 5:48 PM, Murray S. Kucherawy wrote:

I wish in hindsight I'd tried it
anyway as an experiment, with maybe a couple of senders, receivers,
and mailing lists as participants.


While I can imagine devising something that would look appealing, I 
believe it would have had a foundation of sand, in terms of operational 
realities, since none of what it would be relying on was documented 
standards and, again, there was (and I suspect remains) a view that 
mailing list operators did not make good candidates for reliable 
adherence to IETF 'standards'.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation and controlled forwarding

2020-06-19 Thread John R Levine 

On Fri, 19 Jun 2020, Murray S. Kucherawy wrote:

There's a chance that it is possible to specify a small range of
modifications and arrange a style of signing that could survive them.



A number of drafts were floated, as I recall.  I had a couple.


There's always my conditional signing hack, in which one puts a very weak 
signature on the message which says it only counts if it's resigned by X, 
where X is the expected mediator.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Murray S. Kucherawy 
On Fri, Jun 19, 2020 at 5:09 PM John Levine  wrote:
> >There's a chance that it is possible to specify a small range of
> >modifications and arrange a style of signing that could survive them.
> >So for originating and mediating sites that conform to that range, a
> >'preserved' original authentication might be possible.
> >
> >However...
> >
> >I don't remember enough detail from the original dmarc discussions, so I
> >don't remember how much of this was discussed, but I vaguely think it
> >was covered.
>
> It definitely came up in DKIM.  It rapidly became clear that there
> are many things that lists do that have simple user semantics but
> are hopeless to describe in terms of bytes in the message, e.g.,
> reordering or deleting MIME parts.

A number of drafts were floated, as I recall.  I had a couple.

In one case, I think it was a new DKIM signature tag.  The idea was to
place a small annotation on the message of some kind that effectively
meant something like "MTA X asserts that it added '[foobar]' to the
Subject: field".  Another might be the usual "--" followed by a short
signature added to a plain text (or maybe non-MIME) body.  A validator
could then try undoing that and repeating validation to see if the
author signature then verified.  At the time, the feedback was that
this was too fragile to get right, but I don't think anyone ever
looked at it in the 80-20 sense.  I wish in hindsight I'd tried it
anyway as an experiment, with maybe a couple of senders, receivers,
and mailing lists as participants.

-MSK

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread John Levine 
In article <3efe1445-4a58-cdf2-9c06-d8ffb3ce1...@gmail.com> you write:
>There's a chance that it is possible to specify a small range of 
>modifications and arrange a style of signing that could survive them.  
>So for originating and mediating sites that conform to that range, a 
>'preserved' original authentication might be possible.
>
>However...
>
>I don't remember enough detail from the original dmarc discussions, so I 
>don't remember how much of this was discussed, but I vaguely think it 
>was covered.

It definitely came up in DKIM.  It rapidly became clear that there
are many things that lists do that have simple user semantics but
are hopeless to describe in terms of bytes in the message, e.g.,
reordering or deleting MIME parts.

>That leaves just a staged trust model, establishing a basis of 
>accountability (and reputation) for the mediator sequence. Hence, ARC.

Agreed, it seems unlikely we can do any better.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Dave Crocker 

On 6/19/2020 3:13 PM, Brandon Long wrote:
There were several attempts to come up with alternative signing 
schemes that would
allow messages to pass through mailing lists and still be verified as 
"untampered" with,

and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, 
and that would have been
sufficient and a better solution than From header rewriting. Everyone 
has their opinion on the must
haves for mailing list message modification, and it becomes quickly 
intractable.



There's a chance that it is possible to specify a small range of 
modifications and arrange a style of signing that could survive them.  
So for originating and mediating sites that conform to that range, a 
'preserved' original authentication might be possible.


However...

I don't remember enough detail from the original dmarc discussions, so I 
don't remember how much of this was discussed, but I vaguely think it 
was covered.


Anyhow, there is a long track record of difficulties getting mailing 
list systems and operators to adopt external standards, and it isn't 
clear (to me) that the small range would be useful enough.  These risk 
factors do not encourage pursuing the complexities and costs of a global 
standard.


That leaves just a staged trust model, establishing a basis of 
accountability (and reputation) for the mediator sequence. Hence, ARC.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Dave Crocker 

On 6/19/2020 2:20 PM, Pete Resnick wrote:
Crap. My deepest apologies to Dave. I am very embarrassed by fat 
fingering that. It is not the worst private thing I've ever sent to a 
list, but still.



A bigger concern should be with thinking that such paternalism is 
appropriate.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

2020-06-19 Thread Brandon Long 
On Fri, Jun 19, 2020 at 12:03 PM Pete Resnick  wrote:

> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>
> > The description of what a Mediator might do is not incompatible with
> > also viewing it as having characteristics of a publisher:
> >>
> >> ### [5.3](). Mailing
> >> Lists
> >>
> >>
> >>...
> >>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.
>
> Fair enough, but as you mention below, in the case of the common mailing
> list, the intent is simply to redistribute the message with minimal
> change (hence the retention of the Message-ID: and the From:). That
> said, I do disagree with the reasoning given with regard to why
> 5321.MailFrom has changed: It's not because of the authorship, but
> rather because it is responsible for the submission onto the network,
> just as the ReSender is in 5.2.
>
> > Note that in terms of email transport, it is posting a new message.
>
> Strictly in terms of transport, yes. But in terms of the layer above
> (the 5322 layer), it is usually the same message; see the second Note:
> in RFC 5322 section 3.6.4:
>
>Note: There are many instances when messages are "changed", but
>those changes do not constitute a new instantiation of that
>message, and therefore the message would not get a new message
>identifier.  For example, when messages are introduced into the
>transport system, they are often prepended with additional header
>fields such as trace fields (described in section 3.6.7) and
>resent fields (described in section 3.6.6).  The addition of such
>header fields does not change the identity of the message and
>therefore the original "Message-ID:" field is retained.  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.
>
> > Mediators really have complete freedom to do whatever they want.  If
> > describing the full range of what a publisher might do, it would cover
> > the same range.
>
> Well, "complete freedom" in the sense that no Internet police prevent
> such actions. But for most mediators, large substantive (for interesting
> definitions of "substantive") changes are outside of the scope of their
> definitions, and would probably invite someone to say, "That's not being
> a mediator." Certainly that would happen in the case of an alias or a
> resender.
>

And if we knew how to encode and verify that the mediator sticks to that,
we could
enforce it with policy.

There were several attempts to come up with alternative signing schemes
that would
allow messages to pass through mailing lists and still be verified as
"untampered" with,
and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, and
that would have been
sufficient and a better solution than From header rewriting.  Everyone has
their opinion on the must
haves for mailing list message modification, and it becomes quickly
intractable.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

2020-06-19 Thread Pete Resnick 

On 19 Jun 2020, at 15:05, Douglas E. Foster wrote:

Why is the state of the message-id important?   You have mentioned 
it twice.


So, we've been talking about the semantics of messages sent by a mailing 
list. My contention has been that for many mailing lists, and 
particularly the ones we've been talking about, the intent is that the 
mailing list is simply resending messages on to the subscribers to the 
list. The semantics of the message are revealed in the headers: The 
From: header indicates who the author of the message is. And the 
message-id is a way for the resender of a message to indicate that it is 
"the same message" as a previous one that it received, and can used when 
"threading" messages in a conversation view or deleting duplicates for 
display purposes.



It is not a required header.


Well, kinda sorta. My apologies if you already know this; perhaps useful 
to others:


Be careful about MUST/SHOULD/MAY in IETF documents. Of Message-ID:, RFC 
5322 says:


   Though listed as optional in the table in section 3.6, every message
   SHOULD have a "Message-ID:" field.  Furthermore, reply messages
   SHOULD have "In-Reply-To:" and "References:" fields as appropriate
   and as described below.

And if you have a look at RFC 2119:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Which is to say, "SHOULD" means "MUST unless you really know what you're 
doing". We don't do requirements the way other standards folks do. Also 
from 2119:


   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

We don't do "conformance" in IETF by using MUSTs and SHOULDs and MAYs. 
It's all about interoperability.


In this case, read the sentence as, "Use a Message-ID:, because if you 
don't you may screw up what the receiver of the message needs to do. 
That said, there might be circumstances where you simply can't produce 
one, and the recipient is going to have deal with that possibility, but 
you had better have a pretty good reason."



It often uses a domain portion that is not a registered name.


It needn't be registered to be useful; only unique. That said, I'm not 
sure about "often".


The recipient has no way to know whether or not it has been changed 
during forwarding.


It could be signed, could it not?

I have tried to imagine a way to use message-id in message evaluation, 
but have given up.


Back to your original question: My comment about Message-ID: was not 
about whether it was particularly useful for DKIM/DMARC, but more about 
how its semantics are reflected in mailing list email messages.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Pete Resnick 

On 19 Jun 2020, at 16:15, Pete Resnick wrote:


[Offlist]


Crap. My deepest apologies to Dave. I am very embarrassed by fat 
fingering that. It is not the worst private thing I've ever sent to a 
list, but still.


(*Sigh*)

pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Pete Resnick 

[Offlist]

On 19 Jun 2020, at 15:07, Dave Crocker wrote:


Please re-read my text...


If there is a specification ... I apologize that I don't know what it 
is.


These little passive-aggressive turns of phrase are not useful habits to 
teach to others on the list.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Pete Resnick 
We seem to be having a discussion with some premises misunderstood, so 
let me attempt to answer your message upside down, in hopes of undoing 
that:


On 19 Jun 2020, at 15:07, Dave Crocker wrote:


On 6/19/2020 12:02 PM, Pete Resnick wrote:

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

But typical mediators are trying to maintain a sense and ability for 
the original author and the final recipient to experience an 
end-to-end message exchange.


Yep. That's the point I was trying to make.


Except you seem to be pressing this as essentially a requirement they 
have


Ah, no, I think that's the crux of the misunderstanding: I was 
responding to Alessandro, who I interpreted to be saying that *all* 
mailing lists were, by definition, publishers, defining a publisher like 
a newspaper, where the true author of the content are the folks in the 
masthead, even though they acknowledge individual authors in the 
by-line. I disagree with that view. Indeed, I think for most of the 
mailing lists we have been referring to in this discussion, they are not 
publishers in Alessandro's sense, but rather view themselves as 
redistributors of author messages. As 5598 points out, there is variance 
in how much "editing" is done by any given mailing list, but again, for 
the discussion we've been having about how the From: field should be 
used, we've been talking about mailing lists which do the sort of 
minimal editing of messages.


(For mailing lists that do more substantial editing, I may not be as 
motivated to keep the From: field unchanged. If we get more deeply into 
the discussion, it might be useful to start drawing more distinct 
circles around types of mailing lists.)


So the purpose of pointing to 5598 was simply to explain to Alessandro 
that redistribution of messages through the transport system does not 
ipso facto make something a publisher.



whereas I'm pressing it as a business decision


I'm not really sure what that means or how it is relevant to the 
discussion, but again, I think we've been talking past eachother for the 
last two messages.



not something inherent in the nature of mailing list behavior.


No, sorry. I meant to simply point out the converse: That becoming a 
publisher is not in the nature of mailing list behavior.


That said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.


I did not anything about MailFrom, or for that matter anything about 
any field with an identifier.


I didn't say you had. I brought it up only because I re-read the section 
in 5598 on mailing lists, and it makes this claim. Just objecting in 
passing (because it seems to support Alessandro's view), not because I 
thought you were making some claim about it.


I'm guessing that your reference is to the fact that a mailing list 
service might put its own address into the MailFrom, so it gets 
handling error messages?  That issue and behavior predates DMARC by a 
lot.  Probably two decades. Maybe more.


I agree. Which is why I thought it relevant to the overall discussion. 
It was not directed at a particular statement of yours.


But in terms of the layer above (the 5322 layer), it is usually the 
same message; see the second Note: in RFC 5322 section 3.6.4:


  Note: There are many instances when messages are 
"changed", but
  those changes do not constitute a new instantiation of 
that

  message,


Except that there are many instances when messages might be changed 
that DO constitute a new instantiation of that message, and 5322 gives 
no guidance about what determine one versus the other.


That's not true. In what you elided:

  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.

It doesn't give any algorithmic guidance, if that's what you meant.

None of which is relevant to the point that a mailing list service has 
its own agency and is free to do what it wishes to and with the 
messages it is re-posting.


Well, it seems exactly to that point. See above.

That most seek to preserve essentially all of the author's text is 
fine, but whether and how much is more of a 'business' decision than a 
technical one.


We appear to be in violent agreement, as the quip goes. Importantly, I 
think we agree that if a mailing list decides to preserve the original 
From: field, in an attempt to preserve all of the author's semantics, 
they are not "doing it wrong", as Alessandro's message appears to claim.


I didn't mean anything so nit-picky.  I mean that they are providing 
a value-added service to users and have their own agency to deci

Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

2020-06-19 Thread Douglas E. Foster 
Why is the state of the message-id important?   You have mentioned it twice.It is not a required header.  It often uses a domain portion that is not a registered name.   The recipient has no way to know whether or not it has been changed during forwarding.  I have tried to imagine a way to use message-id in message evaluation, but have given up.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation

2020-06-19 Thread Dave Crocker 

On 6/19/2020 12:02 PM, Pete Resnick wrote:

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:


### [5.3](). 
Mailing Lists

   ...
   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.


Fair enough, but as you mention below, in the case of the common 
mailing list, the intent is simply to redistribute the message with 
minimal change (hence the retention of the Message-ID: and the From:). 


While, yes, that's the goal of some and probably most lists, that isn't 
quite what I said.


Please re-read my text, which notably did not contain the word 'minimal' 
and frankly had a different focus. That focus doesn't exclude 
minimality, but it wasn't the point.



That said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.


I did not anything about MailFrom, or for that matter anything about any 
field with an identifier.


I'm guessing that your reference is to the fact that a mailing list 
service might put its own address into the MailFrom, so it gets handling 
error messages?  That issue and behavior predates DMARC by a lot.  
Probably two decades. Maybe more.




Note that in terms of email transport, it is posting a new message.


Strictly in terms of transport, yes. But in terms of the layer above 
(the 5322 layer), it is usually the same message; see the second Note: 
in RFC 5322 section 3.6.4:


  Note: There are many instances when messages are "changed", but
  those changes do not constitute a new instantiation of that
  message, 


Except that there are many instances when messages might be changed that 
DO constitute a new instantiation of that message, and 5322 gives no 
guidance about what determine one versus the other.


None of which is relevant to the point that a mailing list service has 
its own agency and is free to do what it wishes to and with the messages 
it is re-posting.  That most seek to preserve essentially all of the 
author's text is fine, but whether and how much is more of a 'business' 
decision than a technical one.



Mediators really have complete freedom to do whatever they want.  If 
describing the full range of what a publisher might do, it would 
cover the same range.


Well, "complete freedom" in the sense that no Internet police prevent 
such actions.


I didn't mean anything so nit-picky.  I mean that they are providing a 
value-added service to users and have their own agency to decide what 
that service looks like. If they want to do assorted message 
modifications that are substantial, and if users of the service like the 
nature of those modification, the service is free to do them.  There is 
no specifications that dictate or even suggest, what one of the services 
must, or even should, do. So your reference to Internet police is 
ironic, because there is nothing to guide enforcement.



But for most mediators, large substantive (for interesting definitions 
of "substantive") changes are outside of the scope of their 
definitions, and would probably invite someone to say, "That's not 
being a mediator." Certainly that would happen in the case of an alias 
or a resender.


If there is a specification that would move such a declaration out of 
people's personal opinions and into objective, technical assessment, I 
apologize that I don't know what it is.



But typical mediators are trying to maintain a sense and ability for 
the original author and the final recipient to experience an 
end-to-end message exchange.


Yep. That's the point I was trying to make.


Except you seem to be pressing this as essentially a requirement they 
have whereas I'm pressing it as a business decision, not something 
inherent in the nature of mailing list behavior.



The degree to which the mediator asserts itself more visibly to the 
recipient is probably the degree to which it looks more like a 
publisher and less like a simple relaying service.


And eventually, I would contend, less like a mediator.


I probably wouldn't like it either, but we don't have objective criteria 
for accurately and reliably applying or withholding the term, do we?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

2020-06-19 Thread Pete Resnick 

On 19 Jun 2020, at 13:38, Dave Crocker wrote:

The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:


### [5.3](). Mailing 
Lists



   ...
   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.


Fair enough, but as you mention below, in the case of the common mailing 
list, the intent is simply to redistribute the message with minimal 
change (hence the retention of the Message-ID: and the From:). That 
said, I do disagree with the reasoning given with regard to why 
5321.MailFrom has changed: It's not because of the authorship, but 
rather because it is responsible for the submission onto the network, 
just as the ReSender is in 5.2.



Note that in terms of email transport, it is posting a new message.


Strictly in terms of transport, yes. But in terms of the layer above 
(the 5322 layer), it is usually the same message; see the second Note: 
in RFC 5322 section 3.6.4:


  Note: There are many instances when messages are "changed", but
  those changes do not constitute a new instantiation of that
  message, and therefore the message would not get a new message
  identifier.  For example, when messages are introduced into the
  transport system, they are often prepended with additional header
  fields such as trace fields (described in section 3.6.7) and
  resent fields (described in section 3.6.6).  The addition of such
  header fields does not change the identity of the message and
  therefore the original "Message-ID:" field is retained.  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.

Mediators really have complete freedom to do whatever they want.  If 
describing the full range of what a publisher might do, it would cover 
the same range.  


Well, "complete freedom" in the sense that no Internet police prevent 
such actions. But for most mediators, large substantive (for interesting 
definitions of "substantive") changes are outside of the scope of their 
definitions, and would probably invite someone to say, "That's not being 
a mediator." Certainly that would happen in the case of an alias or a 
resender.


But typical mediators are trying to maintain a sense and ability for 
the original author and the final recipient to experience an 
end-to-end message exchange.


Yep. That's the point I was trying to make.

The degree to which the mediator asserts itself more visibly to the 
recipient is probably the degree to which it looks more like a 
publisher and less like a simple relaying service.


And eventually, I would contend, less like a mediator.

pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

2020-06-19 Thread Dave Crocker 

On 6/19/2020 9:40 AM, Pete Resnick wrote:

On 19 Jun 2020, at 10:38, Alessandro Vesely wrote:


consider a mailing list as a publishing organization, which is what it
is.


No, it isn't. It is a Mediator. See RFC 5598.



The description of what a Mediator might do is not incompatible with 
also viewing it as having characteristics of a publisher:




  5.3 . Mailing Lists

...
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.


Note that in terms of email transport, it is posting a new message.

Mediators really have complete freedom to do whatever they want. If 
describing the full range of what a publisher might do, it would cover 
the same range.


But typical mediators are trying to maintain a sense and ability for the 
original author and the final recipient to experience an end-to-end 
message exchange.  The degree to which the mediator asserts itself more 
visibly to the recipient is probably the degree to which it looks more 
like a publisher and less like a simple relaying service.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc