Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> Il 06/10/2020 01:57 Jesse Thompson > ha scritto: > > e.g. I find it hard to imagine that an ISP would have the willingness to > exempt a boutique MLM for all of their customers, so ARC, in and of itself, > doesn't really help MLMs move away from From munging. Does it make sense to >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

g Sent: 10/5/20 8:22 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field On 9/28/20 10:35 AM, Kurt Andersen (b) wrote: > On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman <mailto:skl...@kitterman.com>> wrote: > > On Su

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/28/20 10:35 AM, Kurt Andersen (b) wrote: > On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman > wrote: > > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > Agreed.  Maybe it would help if someone who takes the latter view would >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Dave, disengage from this thread. Continuing to publicly attack a participant who's been asked to disengage and so far has done so is not acceptable. This is a formal warning. The chairs and ADs will be in touch. Feel free to reach out to us directly in the meantime if you so wish. Seth, as

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/30/2020 9:37 PM, Seth Blank wrote: Hector, the chairs hear your frustration, thank you for not escalating further, and would be happy to speak with you off list on the matter. Seth, Please reread the post you responded to.  It is, in fact, an escalation.  The tone you've set with your

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/30/2020 9:37 PM, Seth Blank wrote: Hector, the chairs hear your frustration, thank you for not escalating further, and would be happy to speak with you off list on the matter. Seth, Please reread the post you responded to.  It is, in fact, an escalation.  The tone you've set with your

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Hector, the chairs hear your frustration, thank you for not escalating further, and would be happy to speak with you off list on the matter. On Wed, Sep 30, 2020 at 8:05 PM Hector Santos wrote: > Seth, Selectively quoting of comments and not answering any technical > comments or questions

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Seth, Selectively quoting of comments and not answering any technical comments or questions should also not be tolerated. It waste people time especially which rudely told we lack substance and credibility. This damages people's reputation when he torts engineers in these IETF forums. Did

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Hector, please constrain your comments to the technical matters at hand, not the actions of others. This thread is veering towards ad hominem attacks which will not be tolerated. Seth, as Chair On Wed, Sep 30, 2020 at 7:12 PM Hector Santos wrote: > On 9/29/2020 6:54 PM, Dave Crocker wrote: >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/30/2020 7:12 PM, Hector Santos wrote: I've no idea what any of your note has to do with the DKIM protocol specification. wow. I'll stop now.  As far as I can tell, this really has nothing to do with the existing DKIM specification, nor really anything to do with DMARC. Perhaps

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 6:54 PM, Dave Crocker wrote: On 9/29/2020 3:41 PM, Hector Santos wrote: Do you have an algorithm that replaces the current one? I've no idea what any of your note has to do with the DKIM protocol specification. wow. By way of a small example, DKIM does not have o=. Right,

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 3:41 PM, Hector Santos wrote: Do you have an algorithm that replaces the current one? I've no idea what any of your note has to do with the DKIM protocol specification. By way of a small example, DKIM does not have o=. But really, nothing in your note concerns the published

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 3:41 PM, Hector Santos wrote: Do you have an algorithm that replaces the current one? I've no idea what any of your note has to do with the DKIM protocol specification. By way of a small example, DKIM does not have o=. But really, nothing in your note concerns the published

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 1:26 PM, Dave Crocker wrote: On 9/29/2020 6:40 AM, Hector Santos wrote: On 9/27/2020 11:44 PM, Dave Crocker wrote: DKIM has a single signature binding requirement, the 5322.From DMARC establishes the relationship. I don't read it that way. DKIM binds the signer d= domain and the

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 10:46 AM, Alessandro Vesely wrote: On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote: On 9/29/2020 6:40 AM, Hector Santos wrote: On 9/27/2020 11:44 PM, Dave Crocker wrote: DKIM has a single signature binding requirement, the 5322.From DMARC establishes the relationship. I

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote: On 9/29/2020 6:40 AM, Hector Santos wrote: On 9/27/2020 11:44 PM, Dave Crocker wrote: DKIM has a single signature binding requirement, the 5322.From DMARC establishes the relationship. I don't read it that way. DKIM binds the signer d=

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Tue, Sep 29, 2020 at 1:26 PM Dave Crocker wrote: > On 9/29/2020 6:40 AM, Hector Santos wrote: > > On 9/27/2020 11:44 PM, Dave Crocker wrote: > > DKIM has a single signature binding requirement, the 5322.From > >> DMARC establishes the relationship. > > I don't read it that way. > > > > DKIM

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/29/2020 6:40 AM, Hector Santos wrote: On 9/27/2020 11:44 PM, Dave Crocker wrote: DKIM has a single signature binding requirement, the 5322.From DMARC establishes the relationship. I don't read it that way. DKIM binds the signer d= domain and the from.domain with no enforcement on it nor

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/27/2020 11:44 PM, Dave Crocker wrote: On 9/27/2020 11:22 AM, Scott Kitterman wrote: This seems to me to be an odd view because no RFC is needed to use From and it's relationship to either DKIM signing domain or SPF validated Mail From. The DKIM d= value establishes no relationship with

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/28/2020 5:32 PM, Scott Kitterman wrote: but pretending like DMARC policy doesn't exist is not. Claims of pretending seem to be popular just now.  the problem seems to be adequately explaing  the pretending. So to contribute the response portion of this ritual: 1. No one is

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Monday, September 28, 2020 11:35:58 AM EDT Kurt Andersen (b) wrote: > On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman > > wrote: > > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > > > Agreed. Maybe it would help if someone who takes the latter view would > > > >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Sep 28, 2020 at 10:46 AM Dave Crocker wrote: > . . .given that 'disposing of' the message is a domain owner goal, > frequently, perhaps changing "disposed of" to "processed" would be less > inviting of misunderstanding? > Yes, I think that, at least in American English usage, "disposal"

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/28/2020 8:35 AM, Kurt Andersen (b) wrote: >   6.  Apply policy.  Emails that fail the DMARC mechanism check are >        disposed of in accordance with the discovered DMARC policy of the >        Domain Owner.  See Section 6.3 for details. I don't think that says "then

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman wrote: > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > > Agreed. Maybe it would help if someone who takes the latter view would > explain what they think RFC 7489, Section 6.6.2, Step 6 is for: > > >6. Apply policy.

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sunday, September 27, 2020 11:44:11 PM EDT Dave Crocker wrote: > On 9/27/2020 11:22 AM, Scott Kitterman wrote: > > This seems to me to be an odd view because no RFC is needed to use From > > and > > it's relationship to either DKIM signing domain or SPF validated Mail > > From. > > The DKIM d=

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sunday, September 27, 2020 11:58:40 PM EDT Dave Crocker wrote: > On 9/27/2020 8:53 PM, Scott Kitterman wrote: > > So we agree that you claim DMARC practice is in variance with what is > > specified and we should base the update to the specification on the usage > > you have claimed is popular?

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun 27/Sep/2020 15:06:24 +0200 Dave Crocker wrote: On 9/27/2020 2:20 AM, Alessandro Vesely wrote: On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote: On 9/26/2020 3:31 AM, Alessandro Vesely wrote: A pointer to a better aimed report circulated on this list: An unrefereed presentation

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/27/2020 8:53 PM, Scott Kitterman wrote: So we agree that you claim DMARC practice is in variance with what is specified and we should base the update to the specification on the usage you have claimed is popular? Depends on the analysis of that behavior, but it's silly to ignore the

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sunday, September 27, 2020 11:44:11 PM EDT Dave Crocker wrote: > On 9/27/2020 11:22 AM, Scott Kitterman wrote: > > This seems to me to be an odd view because no RFC is needed to use From > > and > > it's relationship to either DKIM signing domain or SPF validated Mail > > From. > > The DKIM d=

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/27/2020 11:22 AM, Scott Kitterman wrote: This seems to me to be an odd view because no RFC is needed to use From and it's relationship to either DKIM signing domain or SPF validated Mail From. The DKIM d= value establishes no relationship with any other identifer, such as the From:

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote: > In article <4004580.HQKp4RnRq6@zini-1880> you write: > >I don't think this his helpful. If something like this is going to be > >standardized, it shouldn't be called DMARC because it's not. > > We (the generic we) seem to have a

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

- If it is true that the From address serves no purpose to the user, then is header munging really a problem? DF From: Dave Crocker Sent: 9/27/20 1:26 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Heade

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/27/2020 10:16 AM, John Levine wrote: I suppose both are right to some extent, but they have very different implications for the design. Except they aren't both right. We know that it is used by filtering engines. There is no evidence it is used by end-users. And there is a pretty long

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

In article <4004580.HQKp4RnRq6@zini-1880> you write: >I don't think this his helpful. If something like this is going to be >standardized, it shouldn't be called DMARC because it's not. We (the generic we) seem to have a fundamendal disconnect about what DMARC is for. One group appears to

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/27/2020 2:20 AM, Alessandro Vesely wrote: On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote: On 9/26/2020 3:31 AM, Alessandro Vesely wrote: A pointer to a better aimed report circulated on this list: An unrefereed presentation (not paper) about a single experiment is better than a

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote: On 9/26/2020 3:31 AM, Alessandro Vesely wrote: A pointer to a better aimed report circulated on this list: An unrefereed presentation (not paper) about a single experiment is better than a summary of an industry-wide effort that failed?

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/26/2020 7:23 PM, Seth Blank wrote: The goal of DMARCbis is to take the independent stream informational RFC 7489 and drive it to an IETF stream standards track document that represents IETF consensus. So this work is explicitly around DMARC as a protocol that describes how a domain owner

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sat, Sep 26, 2020 at 3:50 PM Scott Kitterman wrote: > Is the context in terms of the protocol specified by RFC 7489? > Yes. > That may sound like a silly question, but I think fundamentally if "DMARC" > is > just an input to a filter or if "DMARC" is a protocol to reject/quarantine > email

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Saturday, September 26, 2020 3:56:44 PM EDT Seth Blank wrote: > Thank you, everyone, for backing off the personal attacks and apologizing. > > Now let's get back to the technical merits of the open tickets, please-- > we'd like to close the current 3 out and open the next batch early next >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

... Well, ok, here's one that shows lack of efficacy, and it's a big one:  EV-certs /Google to bury indicator for Extended Validation certs in Chrome because users barely took notice/ https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ "The reason is

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/26/2020 8:41 AM, Scott Kitterman wrote: On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote: Perhaps you have not noticed but the demonstrated field use of DMARC, to date, tends to be contrary to the design, to the extent anyone thinks that the design carries a mandate that

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

would have any desire >> to implement them, and because Mailing List Operators would have no way of >> knowing which mailing lists had implemented the new feature. >> >> If you have solutions to these problems, please put them forward. >> Otherwise, why are we dragging

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

: Dave Crocker Sent: 9/25/20 11:04 PM To: Scott Kitterman Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:I think the o

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sat, 26 Sep 2020, John Levine wrote: In article you write: Chairs? [ something ] My apologies, that wasn't supposed to go to the list. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/26/2020 10:19 AM, John Levine wrote: I thought he was already in everone's kill file. John, That's also an ad homen. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

In article you write: >On 9/26/2020 5:55 AM, Douglas E. Foster wrote: >> but you apparently choose not to hear. > > >that's an ad hominem. > >Chairs? I thought he was already in everone's kill file. ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

-- > *From*: Dave Crocker > *Sent*: 9/25/20 11:04 PM > *To*: Scott Kitterman > *Cc*: IETF DMARC WG > *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the > RFC5322.Sender Header Field > > On 9/25/2020 4:21 PM, Scott Kitterman wrote: > > On Friday

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote: > On 9/25/2020 4:21 PM, Scott Kitterman wrote: > > On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote: > > I think the obligation to justify is on the advocate for change. > > That means you are demanding I prove

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/26/2020 5:55 AM, Douglas E. Foster wrote: but you apparently choose not to hear. that's an ad hominem. Chairs? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/26/2020 3:31 AM, Alessandro Vesely wrote: A pointer to a better aimed report circulated on this list: An unrefereed presentation (not paper) about a single experiment is better than a summary of an industry-wide effort that failed? And the presentation cited SMTP Mail From, as if that

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

. Otherwise, why are we dragging this back up? From: Dave Crocker Sent: 9/25/20 11:04 PM To: Scott Kitterman Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field On 9/25/2020 4:21 PM, Scott Kitterman

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/25/2020 4:21 PM, Scott Kitterman wrote: On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote: I think the obligation to justify is on the advocate for change. That means you are demanding I prove  negative.  Which, of course, is an impossible assignment. Rather, the

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote: > On 9/25/2020 4:00 PM, Scott Kitterman wrote: > > In my view the linkage between the identity in From to domains > > authenticated by DKIM and SPF (d= and mail from) is a fundamental > > property of DMARC. If you change that, it's

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/25/2020 4:00 PM, Scott Kitterman wrote: In my view the linkage between the identity in From to domains authenticated by DKIM and SPF (d= and mail from) is a fundamental property of DMARC. If you change that, it's not DMARC anymore. It doesn't change that.  It doesn't alter the current

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Friday, September 25, 2020 5:25:38 PM EDT Dave Crocker wrote: > On 9/25/2020 1:46 PM, Scott Kitterman wrote: > > If something like this is going to be > > > > standardized, it shouldn't be called DMARC because it's not. > > That was cryptic. Please elaborate on your concerns. In my view

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 9/25/2020 1:46 PM, Scott Kitterman wrote: If something like this is going to be standardized, it shouldn't be called DMARC because it's not. That was cryptic. Please elaborate on your concerns. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

I'm sorry this came up during a period when I wasn't following the list. Having caught up recently, I completely agree with the allusions to Sender ID. I don't think this his helpful. If something like this is going to be standardized, it shouldn't be called DMARC because it's not. Scott K

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Dave Crocker reminded me that we were going to adopt this document as Experimental. I was remiss in not mentioning that. Even though the WG adopted this document, it was said during the call that the WG may not be able to come to a consensus to move the document forward. Adoption does not mean

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

All This call for adoption ended a few weeks ago, I have been recalcitrant in following up. The chairs feel there is enough consensus to adopt this work in DMARC. While there were issues raised, the chairs feel they can be addressed through the document process. thanks tim On Mon, Aug 24,

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/21/2020 3:09 PM, Jim Fenton wrote: On 8/15/20 3:53 PM, John Levine wrote: Assurances that are provided by ADSP are generally obtained out of band in the real Internet, and not through ADSP. Current deployment of ADSP is not recommended. Is that not exactly the same situation with

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

I think the DMARC RFC does a good job explaining why DMARC is better than ADSP, even if the same mailing list issue is still there: https://tools.ietf.org/html/rfc7489#appendix-A.5 And if you read the archives on the move to historic for adsp, there were others then who objected to the reason put

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/15/20 3:53 PM, John Levine wrote: > Not really. DKIM was deliberately designed not to be tied to any > visible part of the message. ADSP was a poorly designed hack that was > never implemented other than small experiments, and that I don't think > many people understood. I got a lot of grief

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

During IETF 108, the chairs realized that there was interest in Dave's RFC5322.Sender draft. This starts a Call for Adoption for draft-crocker-dmarc-sender The draft is available here:

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> On 19 Aug 2020, at 00:21, Brandon Long > wrote: > > > > On Mon, Aug 17, 2020 at 5:22 AM Laura Atkins > wrote: > > >> On 17 Aug 2020, at 12:25, Alessandro Vesely > > wrote: >> >> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Still as just me: On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster wrote: > Based on the discussions here, it appears that the notion of From address > validation was envisioned from the beginning Sender Authentication > discussions.We have written evidence that Form address validation was

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/17/2020 11:53 AM, Dotzero wrote: Apology accepted. ;-) nein. maaf. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 2:28 PM Dave Crocker wrote: > On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote: > >> Michael Hammer (Inaccurately referred to by you as Herr Hammer) > > > > Talking about precise language, Dave, I think you owe Michael an apology > ;-) > > > to mix languages, au contraire.

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

>> On 17 Aug 2020, at 16:47, Dotzero wrote: >  > > >>> On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker wrote: > On 8/17/2020 7:33 AM, Dotzero wrote: DMARC fixes one thing and one thing only, direct domain abuse. >>> >>> It does no such thing. Domains can still be 'directly' abused

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon 17/Aug/2020 16:00:42 +0200 Laura Atkins wrote: >> On 17 Aug 2020, at 14:18, Dotzero wrote: >> >> >> You raise an interesting point, Laura. Whatever "solutions" we put in place, >> the abusers/bad guys will evolve. One of the problems for the good guys (for >> some definition of good) is

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon 17/Aug/2020 14:48:31 +0200 Dotzero wrote: On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely wrote: Gmail has a visual perspective that allows them to know each and every email domain worldwide, and employs a number of people who help continuously upgrading domain reputation. In order

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker wrote: > On 8/17/2020 7:33 AM, Dotzero wrote: > > DMARC fixes one thing and one thing only, direct domain abuse. > > > It does no such thing. Domains can still be 'directly' abused in all > sorts of ways that DMARC does not affect. > Mea Culpa. You

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 10:27 AM Dave Crocker wrote: > On 8/17/2020 7:00 AM, Laura Atkins wrote: > > I think the most > useful thing we can say about the FTC workshops is that they were a > forcing mechanism that instigated a lot of effort and innovation in the > space. Some of those efforts

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/17/2020 7:33 AM, Dotzero wrote: DMARC fixes one thing and one thing only, direct domain abuse. It does no such thing.  Domains can still be 'directly' abused in all sorts of ways that DMARC does not affect. A continuing and in my view fundamental problem with discussion in

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 10:01 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 14:18, Dotzero wrote: > >> >> And, 17 years on, we know that domain level authentication doesn’t >> actually help filter spam nor does it provide law enforcement with a potent >> tool for locating and identifying

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/17/2020 7:00 AM, Laura Atkins wrote: I think the most  useful thing we can say about the FTC workshops is that they were a forcing mechanism that instigated a lot of effort and innovation in the space. Some of those efforts fell by the wayside and some still persist. You think? I’m not

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> On 17 Aug 2020, at 14:18, Dotzero wrote: > > And, 17 years on, we know that domain level authentication doesn’t actually > help filter spam nor does it provide law enforcement with a potent tool for > locating and identifying spammers. It was promising, it didn’t live up to the > promise.

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 6:24 AM Laura Atkins wrote: > > > The DMARC proponents have asserted that DMARC prevents domain specific > spoofing and phishing. The amount of harm DMARC authentication has caused, > however, seems disproportional to this small benefit. Phishing is still > happening

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 8:22 AM Laura Atkins wrote: > > > On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: > > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > > The forum page is off the FTC website, but the document links are > still accessible: > > > > A copy is here: > >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/17/2020 2:57 AM, Alessandro Vesely wrote: Reference to that event as if it 'established' anything is misguided, at best.  The meetings were helpful, but not definitive.  And the efforts at domain level authentication were wholly independent of these events. Would it be still correct to

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 5:58 AM Alessandro Vesely wrote: > On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: > > > > If I put my gmail address into the from field, there is no > > pretending, no matter what platform I am using. > > > That conflicts with the

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Aug 16, 2020 at 2:17 PM John R Levine wrote: > > No, it was just some political theatre. We were already working on SPF > and DKIM. > DKIM didn't exist until that approximate time frame. There was Domain Keys (DK) and there was Internet Identified Mail (IIM) > > > DMARC took that

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely wrote: > > >> That conflicts with the coarse-grained authentication strategy, > >> established at the FTC Email Authentication Summit in November > >> 2004, as Doug^W Michael recalled. > > > There was no such strategy established regardless of

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Aug 16, 2020 at 11:31 AM Dave Crocker wrote: > > > 2. There was nothing 'established' at that event. There were > interesting discussions, but that's all. > In fact, some of the most interesting discussions took place outside the formal event. > > 3. I'm not finding the reference in

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> On 17 Aug 2020, at 12:25, Alessandro Vesely wrote: > > On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: >> >> The forum page is off the FTC website, but the document links are >> still accessible: > > > A copy is here: >

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote: > > The forum page is off the FTC website, but the document links are > still accessible: A copy is here: https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/ A sentence says: The Report,

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> On 17 Aug 2020, at 10:57, Alessandro Vesely wrote: > > On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: >> If I put my gmail address into the from field, there is no pretending, >> no matter what platform I am using. > > > That conflicts with the coarse-grained

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote: If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. That conflicts with the coarse-grained authentication strategy, established at the FTC Email Authentication Summit in November

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> On 16 Aug 2020, at 19:16, John R Levine wrote: > > On Sun, 16 Aug 2020, Alessandro Vesely wrote: > If I put my gmail address into the from field, there is no pretending, no > matter what platform I am using. That conflicts with the coarse-grained authentication strategy,

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, 16 Aug 2020, Alessandro Vesely wrote: If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. That conflicts with the coarse-grained authentication strategy, established at the FTC Email Authentication Summit in November 2004, as

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. That conflicts with the coarse-grained authentication strategy, established at the FTC Email Authentication Summit in November 2004, as Doug^W Michael recalled. > 1. I was making a

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun 16/Aug/2020 17:31:47 +0200 Dave Crocker wrote: On 8/16/2020 1:23 AM, Alessandro Vesely wrote: On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote: On 8/15/2020 3:32 AM, Alessandro Vesely wrote: If X pretends to be Y, If I put my gmail address into the from field, there is no

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. That conflicts with the coarse-grained authentication strategy, established at the FTC Email Authentication Summit in November 2004, ... No, it doesn't. It probably won't surprise you

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/16/2020 1:23 AM, Alessandro Vesely wrote: On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32 AM, Alessandro Vesely wrote: If X pretends to be Y, If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. That

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun 16/Aug/2020 04:18:56 +0200 John Levine wrote: In article you write: This morning I had a conversation with the CEO of a company that was hit by ransomware which arrived with the help of a single email. He is slowly getting his company back after paying a lot of money to people who

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun 16/Aug/2020 10:23:45 +0200 I wrote: FTC Email Authentication Summit in November 2004, as Doug recalled. Sorry, of course I meant Michael. Best Ale -- ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32 AM, Alessandro Vesely wrote: If X pretends to be Y, If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. That conflicts with the coarse-grained authentication

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

In article you write: >-=-=-=-=-=- >But are your really arguing that no one in the Mailing List business paid >attention to > the concerns about the fraud and spoofing problems with email? I am unaware of any mailing lists causing fraud and spoofing problems in email, so no more than anyone

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On 8/15/2020 3:33 PM, Douglas E. Foster wrote: Consequently, the real problem before us becomes the existence of users who are unhappy because the From address on some mail does not meet their preferences.    I have to ask why that is a problem worthy of a standards body? Who, exactly, do

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

. This WG is playing the fiddle while Rome burns. Doug From: "John Levine" Sent: 8/15/20 6:53 PM To: dmarc@ietf.org Cc: fost...@bayviewphysicians.com Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

In article <6755d0cef49e465bbf2bd170dbdc6...@bayviewphysicians.com> you write: >Based on the discussions here, it appears that the notion of From address >validation was envisioned from the >beginning Sender Authentication discussions.We have written evidence that >Form address validation

  1   2   >