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

On Wed, Jun 24, 2020 at 9:43 AM wrote: > Hi, > > just answering this one bit, which I believe is at the heart of the > disagreement: > > > > IMHO "phishing and spam messages" is way too broad a concept to permit > useful discussion. DMARC nowadays addresses a whole range of problems of >

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

Hi, just answering this one bit, which I believe is at the heart of the disagreement: Le 22/06/2020 à 21:44, Brandon Long a écrit : [...]  It's the majority which are routinely subjected to phishing and spam messages... IMHO "phishing and spam messages" is way too broad a concept to

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

On Sun, Jun 21, 2020 at 1:32 PM Dave Crocker wrote: > > When first specified, Sender: was to cover the case of someone doing the > online work, on behalf of authors who weren't online, or at least not > online for processing the message. Back in those days, that was not > uncommon. Even if

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

To the chairs: It has become clear that we do not have consensus on the issue of content-altering mailing lists. Despite the diversity of viewpoints the number of persons involve in the discussion is fairly small. Have you identified the stakeholder groups that should be represented in the

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

On 6/22/20 6:23 AM, Alessandro Vesely wrote: > The fact that it cannot be set by a MUA implies Sender: already lost > its menial meaning. So it became a Mediator sort of thing. This list > sets it to "dmarc" . Does anybody use it, or > ever happened o take a look at it? Yes, and I assume

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

On 6/21/2020 3:44 PM, Douglas E. Foster wrote: Dave Crocker writes: The practical problem with From: field munging by MLMs that are otherwise trying to relay a largely-unmodified messages, is that they effective destroy author information, by putting in a different email

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

Hi, Le 21/06/2020 à 21:44, Douglas E. Foster a écrit : > > There is no legal corollary for "largely-unmodified".  [...] Then what? An overwhelming majority of users need e-mail for day-to-day communication, not for binding legal contracts. "Largely-unmodified" as mailing-lists have been doing

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

On 2020-06-21 7:32 p.m., Dave Crocker wrote: > On 6/18/2020 12:46 AM, Alessandro Vesely wrote: >> "Authoring" can have subtly different acceptations, though.  The >> exact sentence is: >> >> The "From:" field specifies the author(s) of the message, >>    that is, the mailbox(es) of

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

Dave Crocker writes:The practical problem with From: field munging by MLMs that are otherwise trying to relay a largely-unmodified messages, is that they effective destroy author information, by putting in a different email address. This is helpful for identifying the three key stakeholder

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

On 6/18/2020 12:46 AM, Alessandro Vesely wrote: "Authoring" can have subtly different acceptations, though.  The exact sentence is: 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

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

On 6/19/2020 2:22 PM, 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 couple of

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

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

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

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

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

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

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

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

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

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

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

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

On 6/18/20 7:35 PM, Dave Crocker wrote: > On 6/18/2020 4:01 PM, Jim Fenton wrote: >> It would be remarkable for IETF to achieve rough consensus on a >> specification with a known vulnerability while we "wait for the bad >> actors to catch on." Particularly when that vulnerability relates to an >>

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

On 6/18/2020 6:28 PM, Tim Wicinski wrote: On Thu, Jun 18, 2020 at 6:26 PM Dave Crocker wrote: Oh good. Let's predict the future. That should be fun. Have to agree with Dave here. We have to accept it's a constantly moving target. We, as engineers, do believe we are making the proper

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

On 6/18/2020 4:01 PM, Jim Fenton wrote: It would be remarkable for IETF to achieve rough consensus on a specification with a known vulnerability while we "wait for the bad actors to catch on." Particularly when that vulnerability relates to an aspect of the specification that has caused

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

On 6/17/2020 3:11 PM, Pete Resnick wrote: On 17 Jun 2020, at 13:27, Dave Crocker wrote: The nature of the hack that mailing lists do, when altering the From: field, makes this clear: They alter information about the operator handling the message, destroying the original information about

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

On 6/18/20 3:42 PM, Dave Crocker wrote: > > And now I'll note that when DMARC moved from being a way to > authenticate a tightly controlled mail stream, as was originally > discussed during its development, into its broader role, I expressed > the same concern that a correlation not inherently

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

On 6/18/20 2:29 PM, Dave Crocker wrote: > On 6/18/2020 2:10 PM, Jim Fenton wrote: >> On 6/17/20 12:11 PM, Pete Resnick wrote: >>> On 17 Jun 2020, at 13:27, Dave Crocker wrote: DMARC has nothing to do with display of author information to a recipient, and everything to do with

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

On 6/18/2020 2:10 PM, Jim Fenton wrote: On 6/17/20 12:11 PM, Pete Resnick wrote: On 17 Jun 2020, at 13:27, Dave Crocker wrote: DMARC has nothing to do with display of author information to a recipient, and everything to do with differential handling by a receiving filtering engine.  Were the

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

There are some basic principles that need to be considered:. DMARC did not break mailing list privileges, unwanted mail did. A fully legitimate message has these characteristics: Intended by the originatorAcceptable to the policies of the domain owner, which are partially implemented in its

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

On 6/17/20 12:11 PM, Pete Resnick wrote: > On 17 Jun 2020, at 13:27, Dave Crocker wrote: > >> DMARC has nothing to do with display of author information to a >> recipient, and everything to do with differential handling by a >> receiving filtering engine.  Were the Sender: field always present, >>

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

Alessandro, There are long time solid reasons why the "Local.From" field needs to be stable. In particular, with local messaging, unless the local system allows for anonymous entry of the Local.From field when creating a Local message, there is a MUST for a 1 to 1 association with the

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

On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote: On 17 Jun 2020, at 13:27, Dave Crocker wrote: On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. [...] So, really, DMARC has altered the semantics of the From: field to be the Sender: field.

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

On 17 Jun 2020, at 13:27, Dave Crocker wrote: On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want.

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

On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. The two sentences seem to be in conflict. If

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

In article <0f22234a-5a43-4473-8e67-b76c01cda...@episteme.net> you write: >No, the semantics of From: have not changed generally. It's that some >mailing lists have to change the semantics of From: in the face of the >inability of DMARC to express the semantics that they want. ... I'm with Pete

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

On 6/17/20 4:23 AM, Alessandro Vesely wrote: > On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote: >> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote: >> >>> Even if you ignore my line of reasoning, I think that Ale made in the OP a >>> compelling case that the practice of From

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

On 17 Jun 2020, at 4:23, Alessandro Vesely wrote: There are a few shortcomings of From: rewriting, which could be mitigated adopting suitable conventions. For example, MUAs' replying to author, or storing rewritten addresses in address books. As soon as you start down that path, you have

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

On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote: On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote: Even if you ignore my line of reasoning, I think that Ale made in the OP a compelling case that the practice of From rewriting is here to stay. As a practical matter, that's

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

On Tuesday, June 16, 2020 2:53:22 PM EDT ned+dm...@mrochek.com wrote: > > In article you write: > > >I for one am always amazed how much people use web forums, which are > > >almost > > >all universally worse at providing a reading interface or keeping people > > >up-to-date on new messages...

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

> In article > you > write: > >I for one am always amazed how much people use web forums, which are almost > >all universally worse at providing a reading interface or keeping people > >up-to-date on new messages... which might be why most of the one's I look > >at are nearly dead, maybe there

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

In article you write: >I for one am always amazed how much people use web forums, which are almost >all universally worse at providing a reading interface or keeping people >up-to-date on new messages... which might be why most of the one's I look >at are nearly dead, maybe there are better ones

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

On Mon, Jun 15, 2020 at 11:01 PM Murray S. Kucherawy wrote: > On Sun, Jun 14, 2020 at 7:09 AM wrote: > > Thanks for you honesty. Then the relevant question is whether open and > > interoperable standards still matter, or if they should be replaced by > > proprietary web apps one feature at a

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

On Sun, Jun 14, 2020 at 7:09 AM wrote: > Thanks for you honesty. Then the relevant question is whether open and > interoperable standards still matter, or if they should be replaced by > proprietary web apps one feature at a time. Both have been around for a long time now and I've seen no

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

Other uses of indirect mail: My university offered an alumni account implemented as a relay to whatever hosting service I was using at the moment. Never took them up on it, and glad that I did not. Perhaps RFC 7960 talked about that scenario, because I think I have seen it mentioned in an

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

On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski wrote: > > On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman > wrote: > >> >> To follow-up on Brandon's note about Google's use of ARC, it's bigger >> than >> mailing lists and so is this problem. It's any intermediary that >> modifies a >> message

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

On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman wrote: > > To follow-up on Brandon's note about Google's use of ARC, it's bigger than > mailing lists and so is this problem. It's any intermediary that modifies > a > message in such a manner that DKIM fails (SPF is only useful for direct >

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

On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote: > On 6/15/20 12:44 PM, John Levine wrote: > > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: > > They both claim they're working on ARC. > > > >> So, solution 1.3 has been naturally selected. Does it need to be

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

(no hats) On Mon, Jun 15, 2020 at 2:18 PM Brandon Long wrote: > > We sometimes use a different solution that isn't listed, which is > basically where internal groups have access to the > domain DKIM key, so they just re-sign. Those aren't really an interesting > case, though. > > I used to

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

On 6/15/20 12:44 PM, John Levine wrote: > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: > They both claim they're working on ARC. > >> So, solution 1.3 has been naturally selected. Does it need to be >> standardized, or is a BCP good enough? >> I'd still like to see a

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

In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: >On 6/15/20 2:33 AM, Alessandro Vesely wrote: >> Let me quote a list of nineteen usable solutions: >>     1.2 Turn off all message modifications >>     1.3 Replace address with a generic one >>     1.5 Rewrite

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

On 6/15/20 2:33 AM, Alessandro Vesely wrote: > Let me quote a list of nineteen usable solutions: > >     1 Sending side workarounds >     1.1 Exclude domains that require alignment >     1.2 Turn off all message modifications >     1.3 Replace address with a generic one >     1.4

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

In article you write: >Let me quote a list of nineteen usable solutions: I wouldn't call them all usable. Proposed, perhaps. > [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail] > >That page hasn't been updated since 2016. If anyone has any new bright ideas, let

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

On 6/14/2020 10:29 PM, Jim Fenton wrote: On 6/13/20 8:17 PM, Dave Crocker wrote: On 6/13/2020 7:53 PM, Jim Fenton wrote: Alas, others do, Other groups do all sorts of things.  They once mandated OSI, for example. Please explain how that is relevant, here and now. The WG needs to consider

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

On Sun 14/Jun/2020 19:18:43 +0200 Scott Kitterman wrote: On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote: Le 13/06/2020 à 17:19, Douglas E. Foster a écrit : About this comment If you teach users that "Joe User by Random Intermediary" is the same as "Joe

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

On 6/13/20 8:17 PM, Dave Crocker wrote: > On 6/13/2020 7:53 PM, Jim Fenton wrote: >> Alas, others do, > > Other groups do all sorts of things.  They once mandated OSI, for > example. > > Please explain how that is relevant, here and now. The WG needs to consider the operational impact of DMARC

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

On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote: > Le 13/06/2020 à 17:19, Douglas E. Foster a écrit : > > About this comment > > > > If you teach users that "Joe User by Random Intermediary" is the same > > as "Joe User", this expectation is doomed.> > >

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

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman wrote: > > On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" > wrote: > >I would like to understand what you mean by: > > > >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely > >wrote: > > > >> . . . ARC chains can be forged. > > Not sure

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

Le 13/06/2020 à 17:19, Douglas E. Foster a écrit : About this comment If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed. Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of

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

On 6/13/2020 11:17 PM, Dave Crocker replied to Jim Fenton wrote: Are you perhaps suggesting that the technical work of the IETF should worry less about technical quality and more about possible use/abuse by other agencies? Dave, It didn't look good when the IETF officially abandoned the ADSP

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

On 6/13/2020 7:53 PM, Jim Fenton wrote: Alas, others do, Other groups do all sorts of things.  They once mandated OSI, for example. Please explain how that is relevant, here and now. Are you perhaps suggesting that the technical work of the IETF should worry less about technical quality and

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

On 6/13/20 1:13 PM, John Levine wrote: > In particular, there is no chance whatsoever that any DMARC policy > will become mandatory, because the IETF doesn't do mandatory. Alas, others do, apparently because they see that DMARC has an RFC number (even though it's informational). For example, in

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

On 2020-06-13 22:13, John Levine wrote: In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write: The "mailing list problem" was introduced into this discussion as an objection to DMARCs progress, by implication suggesting that DMARC must be delayed until a solution is

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

On 2020-06-13 18:42, John Levine wrote: In article you write: I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.) I can think of no purpose served by a public mailing list, like this one, which is not be

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

In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write: >The "mailing list problem" was introduced into this discussion as an objection >to DMARCs >progresss, by implication suggesting that DMARC must be delayed until a >solution is found which >creates no inconvenience to

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

The "mailing list problem" was introduced into this discussion as an objection to DMARCs progresss, by implication suggesting that DMARC must be delayed until a solution is found which creates no inconvenience to mailing list operators. That concerns me, First, a a new solution has not really

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

In article you write: >I suggest that the "Mailing List Problem" is a problem that does not need to >be solved (and evidence suggests that it cannot be solved.) I >can think of no purpose served by a public mailing list, like this one, which >is not be better solved by a community forum

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

the desired features of incoming mail filters. DF From: devel2...@baptiste-carvello.net Sent: 6/13/20 8:04 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem Hi, I'm but a mere user, but I cannot let this be presented as an obvious or

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

Hi, I'm but a mere user, but I cannot let this be presented as an obvious or consensual solution. Header munging is inadequate because: 1) It makes the wrong tradeoffs. DMARC started as a solution for a very specific problem (phishing targetting high impact domains) and made tradeoffs

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

On Sat 13/Jun/2020 07:19:21 +0200 Hector Santos wrote: On 6/12/2020 4:02 AM, Alessandro Vesely wrote: *From rewriting is the real thing* == Rewriting From: is the de-facto standard. I don't support it. In a (science-fictitious) scenario where all mailing

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

On 6/13/2020 1:19 AM, Hector Santos wrote: A DKIM Policy compliant list server simply needs to do two things: 1) Prohibit new subscribers using addresses with restrictive domains, just like it is done here: https://secure.winserver.com/public/code/html-subscribe?list=winserver 2) Prohibit

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

On 6/12/2020 4:02 AM, Alessandro Vesely wrote: Hi all, *From rewriting is the real thing* == Rewriting From: is the de-facto standard. I don't support it. In a (science-fictitious) scenario where all mailing lists rewrite the From: header field, DMARC

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

On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" wrote: >I would like to understand what you mean by: > >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely >wrote: > >> . . . ARC chains can be forged. Not sure what is confusing about that. There's no requirement that signatures from

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

I would like to understand what you mean by: On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely wrote: > . . . ARC chains can be forged. > --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc