Re: [dmarc-ietf] Objections to Sender header as override

2020-09-29 Thread Murray S. Kucherawy
On Tue, Sep 29, 2020 at 5:55 PM Brandon Long wrote: > Shouldn't be separate as defined: > The Sender header proposal is also an adjunct directly to DMARC itself, > changing the existing dmarc policy evaluation in a direct way. I don't > think that should be done by a separate spec, if we do

[dmarc-ietf] Trying to understand DMARC in light of Sender/indicators

2020-09-29 Thread Brandon Long
Although I'm not fully convinced by Dave's point on whether indicators are useless (they certainly are not of large value, I'm less certain in the margins).. I think I need to work through what DMARC is without that. DMARC is composed of three things: alignment, policy and reporting. I think the

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

2020-09-29 Thread Dave Crocker
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] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-29 Thread Seth Blank
On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker wrote: > On 9/29/2020 3:08 PM, Seth Blank wrote: > > I don't know of any receiver that checks DMARC, but then doesn't check > > alignment > > It's not a matter of field statistics: > > Since checking alignment is an obvious part of the DMARC >

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

2020-09-29 Thread Dave Crocker
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] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-29 Thread Dave Crocker
On 9/29/2020 3:08 PM, Seth Blank wrote: I don't know of any receiver that checks DMARC, but then doesn't check alignment It's not a matter of field statistics: Since checking alignment is an obvious part of the DMARC procedure, if someone does not follow the specification, they are not

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

2020-09-29 Thread Hector Santos
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] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-29 Thread Seth Blank
On Tue, Sep 29, 2020 at 2:55 PM Kurt Andersen (b) wrote: > On Tue, Sep 29, 2020 at 3:15 AM Alessandro Vesely wrote: > >> >> +1. The rationale, AIUI, is that if the receiver successfully evaluated >> alignment, then "pass" is fine. If the receiver didn't evaluate anything >> after >> it saw

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-29 Thread Kurt Andersen (b)
On Tue, Sep 29, 2020 at 3:15 AM Alessandro Vesely wrote: > > +1. The rationale, AIUI, is that if the receiver successfully evaluated > alignment, then "pass" is fine. If the receiver didn't evaluate anything > after > it saw p=none, then "none" is fine. and should agree. > If a receiver

Re: [dmarc-ietf] DMARC bis: revisiting ticket 66

2020-09-29 Thread Kurt Andersen (b)
On Mon, Sep 28, 2020 at 8:47 PM Seth Blank wrote: > At a minimum, per Dave's comments here: > https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/ > I still believe there's some clear consistent language that needs to be > agreed upon to drive the appropriate specificity in

[dmarc-ietf] I

2020-09-29 Thread Dave Crocker
On 9/29/2020 10:56 AM, Dave Crocker wrote: Sigh, yes. It has caused this misunderstanding, from the start. It was imposed on the working group by an IETF Area Director and was agreed to as an expedient. But, sigh, no. It does not carry any of the semantic import being claimed in the current

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

2020-09-29 Thread Dave Crocker
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

2020-09-29 Thread Alessandro Vesely
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

2020-09-29 Thread Dotzero
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

2020-09-29 Thread Dave Crocker
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] Issue submission - Mailing list security and potential solutions using DMARC

2020-09-29 Thread Alessandro Vesely
On Sun 13/Sep/2020 03:43:07 +0200 Murray S. Kucherawy wrote: > While I'm thinking of it: > > On Sat, Sep 12, 2020 at 6:11 PM Murray S. Kucherawy wrote: >> On Thu, Sep 10, 2020 at 3:51 PM Douglas E. Foster wrote: >> >>> The Alternative >>> >>> All of these problems can be avoided if the subscriber

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

2020-09-29 Thread Hector Santos
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] DMARC bis: ticket 38: reporting the proper DKIM key(s)

2020-09-29 Thread Alessandro Vesely
On Tue 29/Sep/2020 05:45:40 +0200 Dave Crocker wrote: On 9/28/2020 8:42 PM, Seth Blank wrote: Are there any objections to recording consensus that [1], that the domain and selector of the key used to evaluate the DMARC status MUST be included, and [2] opening a ticket to discuss how

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-29 Thread Alessandro Vesely
On Tue 29/Sep/2020 05:40:13 +0200 Seth Blank wrote: I'm hearing consensus that an aggregate report should retain a disposition of "none" when the dmarc policy is "none", but when the policy is quarantine or reject, "pass" should be used to disambiguate the use cases. Further, there's been one