Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/17/20 3:00 PM, Luis E. Muñoz wrote: > DMARC can be quite useful even with p=none. Agreed. People commonly request that we accept-list their IP/domain from inbound spam scanning. We now tell them to send DMARC-aligned mail (SPF or DKIM pass, aligned with From), and we'll use that as

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Mon, Aug 17, 2020 at 1:00 PM Luis E. Muñoz wrote: > On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote: > > Under 50% of companies have any DMARC record. Of those who deploy > > DMARC, > > about ~2% have p=quarantine and ~5% p=reject, though some industries > > such > > as finance it looks

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

In article <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> you write: >> Why is adoption low? Is that a big problem? Why so few aggressive >> policies? Is that a big problem? > >DMARC can be quite useful even with p=none. This use case provides >insight on what's going on and sometimes, that's

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote: Under 50% of companies have any DMARC record. Of those who deploy DMARC, about ~2% have p=quarantine and ~5% p=reject, though some industries such as finance it looks like it's closer to 15% p=reject. I'm sure these numbers aren't perfect but

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/15/2020 3:59 PM, John R Levine wrote: On Sat, 15 Aug 2020, Dave Crocker wrote: My comment was not about your opinion of either of the drafts but of your impatience with considering one you don't like. Um, if one thinks something is a bad idea, why should we spend more time on it? Out

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Sat, 15 Aug 2020, Dave Crocker wrote: On 8/15/2020 12:48 PM, John Levine wrote: Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/15/2020 12:48 PM, John Levine wrote: Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year apart. John -- your response is oddly

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

In article <603b1699-6a99-0fc3-3fc8-a037126a7...@dcrocker.net> you write: >Also, I'm sorry to hear that the wg isn't capable of discussing two >drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year apart. R's,

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/12/2020 1:09 PM, John Levine wrote: Let's work on your Sender draft which doesn't try to change what MUAs display. and which won't fully fix the user-level problems, because... legacy DMARC. Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time.

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/13/2020 2:38 PM, Kurt Andersen (b) wrote: Passing DMARC is not a be-all-end-all. That's what local policy is for. I fail to see why local policy would not solve your problem (as described). We tend to use the term 'local policy' to refer to exceptional behavior. (I'm not suggesting you

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

Steve, et al, On 8/12/2020 8:16 AM, Steve Atkins wrote: On 12/08/2020 04:32, Dave Crocker wrote: Here's why I think it won't:  They already have From:. The real value in DMARC is not what is displayed to the end-user but in having a required field that cites the originating domain name. 

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton wrote: > On 8/14/20 11:30 AM, Kurt Andersen (b) wrote: > > On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote: > >> >> Is this an interoperability problem that is solved by IETF standards or >> is it an organizational problem that requires an

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 11:15 AM Dotzero wrote: > > > On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz > wrote: > >> >> >> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) >> wrote: >> >>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: >>> I've been involved in setting up DMARC

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/14/20 11:30 AM, Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 9:23 AM Dotzero > wrote: > > >  Is this an interoperability problem that is solved by IETF > standards or is it an organizational problem that requires an > organizational solution?

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote: > > Is this an interoperability problem that is solved by IETF standards or > is it an organizational problem that requires an organizational solution? > Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-) > I think that it

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz wrote: > > > On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) > wrote: > >> On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: >> >>> >>> I've been involved in setting up DMARC with a policy of p=reject for >>> somewhere North of 6,000 domains. As

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > >> >> I've been involved in setting up DMARC with a policy of p=reject for >> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >> in getting buy-in across the

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 11:13 AM Kurt Andersen (b) wrote: > On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > >> >> I've been involved in setting up DMARC with a policy of p=reject for >> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is >> in getting buy-in across the

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote: > > I've been involved in setting up DMARC with a policy of p=reject for > somewhere North of 6,000 domains. As a sending domain, the heavy lifting is > in getting buy-in across the organization that it is a worthwhile effort, > getting control of

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz wrote: > > > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> If I followed Neil’s discussion of MajorCRM: >> >> >> >> The current DMARC architecture supports authorizing a vendor to mail on >>

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote: > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy or > delegates a DKIM scope to them and they use it. > > > > I agree that SPF is too limiting

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz wrote: > > Tunable! You said the magic word I have a client now getting spoofing. > Receiving spoofed mail or having their domain *being* spoofed? > My point is that it sure would be nice to be able to tune so that BigCRM > and BigCRM

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

If I followed Neil’s discussion of MajorCRM: The current DMARC architecture supports authorizing a vendor to mail on behalf of their clients if the client includes them in their SPF policy or delegates a DKIM scope to them and they use it. I agree that SPF is too limiting (including hard

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 12:21 PM Dotzero wrote: > > > On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz > wrote: > >> >> >> Tunable! You said the magic word I have a client now getting spoofing. >> Tightening above p=none is a non starter as about 100% of MajorCRM emails >> fail SPF

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz wrote: > > > Tunable! You said the magic word I have a client now getting spoofing. > Tightening above p=none is a non starter as about 100% of MajorCRM emails > fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails > DKIM, and

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Thu, Aug 13, 2020 at 1:57 AM Alessandro Vesely wrote: > On 2020-08-12 5:16 p.m., Steve Atkins wrote: > > On 12/08/2020 04:32, Dave Crocker wrote: > >> > >> Here's why I think it won't: They already have From:. > >> > >> The real value in DMARC is not what is displayed to the end-user but >

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 2020-08-12 5:16 p.m., Steve Atkins wrote: On 12/08/2020 04:32, Dave Crocker wrote: Here's why I think it won't:  They already have From:. The real value in DMARC is not what is displayed to the end-user but in having a required field that cites the originating domain name. That doesn't

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

In article <0c8afc68-bc51-702a-c794-610b2d355...@dcrocker.net> you write: >Here's why I think it won't: They already have From:. I was going to answer but Steve Atkins said it better. Let's work on your Sender draft which doesn't try to change what MUAs display. R's, John

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 12/08/2020 04:32, Dave Crocker wrote: Here's why I think it won't:  They already have From:. The real value in DMARC is not what is displayed to the end-user but in having a required field that cites the originating domain name.  That doesn't change if there are additional fields that

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Wed, Aug 12, 2020 at 6:32 AM Dave Crocker wrote: > On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote: > > IETF are more relaxed than I expected. > > Don't believe it. The advice was warranted. > > Well, it's good to mostly lurk for a while as a courtesy unless and until I have something useful to

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote: IETF are more relaxed than I expected. Don't believe it. The advice was warranted. d/; -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker wrote: > On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > > wrote: > > > > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote: > > > Mr. Crocker, is there a document

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker wrote: > On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: > > > > > > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > > wrote: > > > > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote: > > > Mr. Crocker, is there a document

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote: On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > wrote: On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote: > Mr. Crocker, is there a document that describes some of these proposals > and perhaps the best

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker wrote: > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote: > > Mr. Crocker, is there a document that describes some of these proposals > > and perhaps the best arguments for an against somewhere? The firehose of > > learning would a bit easier if there

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote: Mr. Crocker, is there a document that describes some of these proposals and perhaps the best arguments for an against somewhere? The firehose of learning would a bit easier if there were a FAQ. I think it might even help the participants if this

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

Mr. Crocker, is there a document that describes some of these proposals and perhaps the best arguments for an against somewhere? The firehose of learning would a bit easier if there were a FAQ. I think it might even help the participants if this was all documented. Yes, I know there's the archived

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

I was quite surprised -- at the level of astonished -- to see the pushback on the Author header-field proposal, since it is such a simple and straightforward mechanism. The different bits in the message are simple enough. The problem is that it might as well be called Really-From, and then

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

In article you write: >Folks, > >I was quite surprised -- at the level of astonished -- to see the >pushback on the Author header-field proposal, since it is such a simple >and straightforward mechanism. The different bits in the message are simple enough. The problem is that it might as

[dmarc-ietf] draft-crocker-dmarc-author-00 ?

Folks, I was quite surprised -- at the level of astonished -- to see the pushback on the Author header-field proposal, since it is such a simple and straightforward mechanism. I'd like to ask for clarity from the group on both concerns about it and desires for it. d/ -- Dave Crocker

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 7/14/2020 6:48 AM, Hector Santos wrote: It will modify all specs related to DKIM where there is an Author (5322.From) design requirement. It does not need to affect DKIM at all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 7/13/2020 12:29 PM, Alessandro Vesely wrote: I'd support making that a WG I-D. I am having trouble with it, so ~1 IMHO, it could be standard track and modify RFC 5322 if accepted. It will modify all specs related to DKIM where there is an Author (5322.From) design requirement. I

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 7/13/2020 8:23 PM, Dave Crocker wrote: On 7/13/2020 12:08 PM, Joseph Brennan wrote: We already have a field for author, called From. Why add another one? Simple summary: These days, the original From: field is tending to get corrupted and we need some place to put author information

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 7/13/2020 12:08 PM, Joseph Brennan wrote: We already have a field for author, called From. Why add another one? 1. Note that the From: field typically serves two different semantic roles, author and 'handling agent' (ie, Sender:) 2. Pars 3 &6 of the Introduction lay the foundation for

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

We already have a field for author, called From. Why add another one? "The only required header fields are the origination date field and the originator address field(s)." By this, RFC 5322 refers to the From field. I think client software developers would be inclined to ignore creating the

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 7/13/2020 11:29 AM, Alessandro Vesely wrote: IMHO, it could be standard track and modify RFC 5322 if accepted. The mail header is extensible.  Addition of header fields does not require modifying the base specification. Restricting From: to be single-address, or at least having all domain

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 13/07/2020 19:27, Dave Crocker wrote: On 7/13/2020 9:29 AM, Alessandro Vesely wrote: On 13/07/2020 05:10, Dave Crocker wrote: I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 7/13/2020 9:29 AM, Alessandro Vesely wrote: On 13/07/2020 05:10, Dave Crocker wrote: I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted a second draft, I'd strike considerations

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

On 13/07/2020 05:10, Dave Crocker wrote: I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ Dave, since you also posted a second draft, I'd strike considerations about the Sender: from this one. In

[dmarc-ietf] draft-crocker-dmarc-author-00

FYI, I've just submitted an initial draft to define an RFC5322.Author field: https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org