Re: [dmarc-ietf] Mediation

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

Re: [dmarc-ietf] Mediation and controlled forwarding

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

Re: [dmarc-ietf] Mediation

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 authentica

Re: [dmarc-ietf] Message-ID, was Mediation

In article <4b20eff9-0979-4695-a984-133e330e9...@email.android.com> you write: >Why is the state of the message-id important? You have mentioned it twice. A great deal of mail software assumes that if two messages have the same message-ID, they're the same message. We use this to avoid showing t

Re: [dmarc-ietf] Mediation

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' orig

Re: [dmarc-ietf] Mediation

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 constrain

Re: [dmarc-ietf] Mediation

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 Crock

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

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](

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

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 b

Re: [dmarc-ietf] Mediation

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 worl

Re: [dmarc-ietf] Mediation

[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://ww

Re: [dmarc-ietf] Mediation

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 typi

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

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 mess

Re: [dmarc-ietf] Mediation

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

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

On Fri, Jun 19, 2020 at 2:22 PM Jim Fenton wrote: > On 6/19/20 10:41 AM, Todd Herr wrote: > > On Fri, Jun 19, 2020 at 1:23 PM Dotzero wrote: > >> >> >> On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton >> wrote: >> >>> >>> A verified identity is established by DKIM and/or SPF. What is DMARC >>> adding

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

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

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

On 6/19/2020 11:22 AM, Jim Fenton wrote: That comes back to the question of whether the domain in the From header is visible in the MUA, and if visible, does it alter user behavior (e.g., discourage users from clicking phish links). Different people have different opinions on that. A small

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

On 6/19/2020 10:41 AM, Todd Herr wrote: Not only that, but DMARC is the only one of the three that is necessarily tied to the domain in the (usually) visible in the MUA From header. Todd, There is no evidence that end-users are relevant to manipulated/fraudulent From: fields or that DMARC's

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

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 v

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

On 6/19/20 10:41 AM, Todd Herr wrote: > On Fri, Jun 19, 2020 at 1:23 PM Dotzero > wrote: > > > > On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton > wrote: > > On 6/19/20 6:06 AM, Douglas E. Foster wrote: > > DMARC helps es

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

> On 19 Jun 2020, at 18:08, Jim Fenton wrote: > > On 6/19/20 6:06 AM, Douglas E. Foster wrote: >> DMARC helps establish a verified identity. Delivery is based on >> reputation. The two are very different. >> >> Unwanted mail with DMARC validation will be blocked on the same basis >> is unwa

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

On Fri, Jun 19, 2020 at 1:23 PM Dotzero wrote: > > > On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton wrote: > >> On 6/19/20 6:06 AM, Douglas E. Foster wrote: >> > DMARC helps establish a verified identity. Delivery is based on >> > reputation. The two are very different. >> > >> > Unwanted mail wit

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

On Fri, Jun 19, 2020 at 1:09 PM Jim Fenton wrote: > On 6/19/20 6:06 AM, Douglas E. Foster wrote: > > DMARC helps establish a verified identity. Delivery is based on > > reputation. The two are very different. > > > > Unwanted mail with DMARC validation will be blocked on the same basis > > is u

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

Pete;you have not explained how my inbox filter recignizes a legitimate forward of a legitimate message instead of an illegitimate forward or a fraudulently manufactured Received-header sequence. We only have this problem with lists that alter the original to destroy DKIM validity. When this

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

On 6/19/20 6:06 AM, Douglas E. Foster wrote: > DMARC helps establish a verified identity.  Delivery is based on > reputation.  The two are very different.  > > Unwanted mail with DMARC validation will be blocked on the same basis > is unwanted mail without it. > > But a verified identity is helpful

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

On 19 Jun 2020, at 11:40, Pete Resnick wrote: The presumption of all Mediator-type transactions was that the receiving email client was to deal with the message (the thing with the identical Message-ID) with its original semantics, adding only Resent-*: or List-*: fields to add the semantic of

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

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. If article submission happened via HTTP, say, like in web fora, there would be no reason to talk about From: rewriting.

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

On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins wrote: > On 19 Jun 2020, at 07:59, Murray S. Kucherawy wrote: > > So to those of you with access to such (e.g., M3AAWG regulars among > us), is there evidence in the wild of spammers and phishers using > discardable (ahem) domains to achieve alignmen

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

Hector, consider a mailing list as a publishing organization, which is what it is. If article submission happened via HTTP, say, like in web fora, there would be no reason to talk about From: rewriting. The fortuitous circumstance that both article submission and the final distribution happen th

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

On Fri, Jun 19, 2020 at 9:13 AM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > DMARC helps establish a verified identity. Delivery is based on > reputation. The two are very different. > Laura Atkins wrote: > DMARC alignment alone is not sufficient for reaching the inbox. Ask all

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

DMARC helps establish a verified identity. Delivery is based on reputation. The two are very different. Unwanted mail with DMARC validation will be blocked on the same basis is unwanted mail without it. But a verified identity is helpful for ensuring that wanted mail is not blocked. There

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

On 6/18/2020 10:16 PM, Jim Fenton wrote: On 6/18/20 7:35 PM, Dave Crocker wrote: vulnerability? Yes. When bad actors (your choice of words) can work around an aspect of the specification that is depended upon to enable differential handling by a receiving filtering engine (again your choice of

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

> On 19 Jun 2020, at 07:59, Murray S. Kucherawy wrote: > > So to those of you with access to such (e.g., M3AAWG regulars among > us), is there evidence in the wild of spammers and phishers using > discardable (ahem) domains to achieve alignment and improve their > delivery success stories? The

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

On Thu, Jun 18, 2020 at 3:24 PM Jim Fenton wrote: > We need to consider not just what's a useful correlation today, but what > will continue to be so. As soon as the {spammers, phishers, etc.} catch > on that they can achieve alignment at will, it will cease to be a useful > correlation. History t