Emphatically hatless:
On Fri, Jun 26, 2020 at 4:42 AM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> Two weeks ago, John Levine reminded us that DMARC v1 was already deployed
> and this effort was to perfect the wording. Suddenly, we have a small but
> powerful group insisting tha
Scott, Thank you!
>>I think the bar to convince me that it's okay to throw away aligning to
>>5322.From is in scope for the working group is really
>>high when the charter defines DMARC as "Domain-based Message Authentication,
>>Reporting & Conformance (DMARC) uses
>>existing mail authentication
On Thu 25/Jun/2020 15:42:35 +0200 Dave Crocker wrote:
> On 6/25/2020 3:14 AM, Alessandro Vesely wrote:
>> Frequently, an inbound message has one or more valid DKIM signatures,
>> and/or passes SPF, yet it fails DMARC; that is, the authenticated
>> domain(s) are not aligned with From:. Now it's obv
> -Original Message-
> From: dmarc On Behalf Of John Levine
> Sent: 25 June 2020 20:13
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] What if... Sender:
>
> In article
> .PROD.OUTLOOK.COM>,
> David I wrote:
> >Without forcing alignment to &
The "Sender" vs "From" discussion reminds me of SenderID and its
companion RFC4407 protocol:
Purported Responsible Address (PRA)
https://tools.ietf.org/html/rfc4407
"This document defines a new identity associated with an e-mail
message, called the Purported Responsible Add
On June 25, 2020 11:04:43 PM UTC, Dave Crocker wrote:
>On 6/25/2020 3:58 PM, Scott Kitterman wrote:
>> Why would I be expressing an interpretation of the charter that I
>didn't think is correct?
>
>That's not what i said.
>
>I mean that you are asserting a requirement as if it were established,
On 6/25/2020 3:58 PM, Scott Kitterman wrote:
Why would I be expressing an interpretation of the charter that I didn't think
is correct?
That's not what i said.
I mean that you are asserting a requirement as if it were established,
based on your interpretation. the requirement is not establi
On June 25, 2020 10:53:40 PM UTC, Dave Crocker wrote:
>On 6/25/2020 3:33 PM, Scott Kitterman wrote:
>> True, but I think it's on topic for a DMARC replacement working
>group, not this one.
>
>You have just crossed over from expressing a personal interpretation of
>
>the charter, to declaring yo
On 6/25/2020 3:33 PM, Scott Kitterman wrote:
True, but I think it's on topic for a DMARC replacement working group, not this
one.
You have just crossed over from expressing a personal interpretation of
the charter, to declaring your interpretation as correct, in spite of
having a competing i
On June 25, 2020 10:18:21 PM UTC, Jim Fenton wrote:
>On 6/25/20 2:20 PM, Scott Kitterman wrote:
>>
>> Even before you get to those:
>>
>>> The working group will seek to preserve interoperability with the
>>> installed base of DMARC systems, and provide detailed justification
>>> for any non-in
On 6/25/20 2:20 PM, Scott Kitterman wrote:
>
> Even before you get to those:
>
>> The working group will seek to preserve interoperability with the
>> installed base of DMARC systems, and provide detailed justification
>> for any non-interoperability.
The paragraph goes on to say:
> As the workin
On 6/25/2020 5:20 PM, Scott Kitterman wrote:
On Thursday, June 25, 2020 5:16:43 PM EDT Dave Crocker wrote:
This entire thread is about making something that's not DMARC.
I agree, but I am willing to see an algorithm, not just subjective
administration considerations. The Sender is only added
On 6/25/20 12:12 PM, John Levine wrote:
> Any sensible mail provider will do its usual reputation checks on the
> validated identity, whichever header it is, and decide whether to
> deliver the message or not. I believe that Dave's point is if you're
> going to do that, validating the sender gives
On Thursday, June 25, 2020 5:16:43 PM EDT Dave Crocker wrote:
> On 6/25/2020 2:10 PM, Scott Kitterman wrote:
> > I would encourage people to review the working group charter. I think
> > dumping 5322.From and aligning to something else is well outside of it.
> > Not saying we couldn't recharter,
On 6/25/2020 2:10 PM, Scott Kitterman wrote:
I would encourage people to review the working group charter. I think dumping
5322.From and aligning to something else is well outside of it. Not saying we
couldn't recharter, but I'm skeptical of the value of this entire thread.
What is it about
On Tuesday, June 23, 2020 2:49:11 PM EDT Dave Crocker wrote:
> Folks,
>
> This note is partially triggered by Mike's note this morning, but isn't
> specifically responding to it. Rather it tries to elaborate on a
> premise I've been implying but haven't been explicating:
>
> What if the rf
In article
,
David I wrote:
>Without forcing alignment to 'From', an attacker can set their own 'Sender',
>set a 'From' they're not entitled to use that's of a trusted
>contact, and the DMARC associated with the abused domain in the 'From' has no
>effect and can't be used for filtering. So whi
On 6/25/20 8:17 AM, Dave Crocker wrote:
> On 6/24/2020 12:24 PM, Jim Fenton wrote:
>> You have explained why Sender: is better than From: (which I agree with)
>> but not why specifically Sender needs to be used.
>
> Existing practice is less risky than new practice. The existence and
> semantics o
> -Original Message-
> From: Dave Crocker
> Sent: 25 June 2020 16:29
> To: David I
> Cc: IETF DMARC WG
> Subject: Re: [dmarc-ietf] What if... Sender:
>
> On 6/25/2020 8:10 AM, David I wrote:
> >> Why is it useful in the From:? Seriously.
> > Bec
On 6/25/2020 8:10 AM, David I wrote:
From: Dave Crocker
set a 'From' they're not entitled to use that's of a trusted contact, and the
DMARC associated with the abused domain in the 'From' has no effect and
can't be used for filtering. So while you could so a similar filter on Sender,
it
wouldn'
On 6/24/2020 12:24 PM, Jim Fenton wrote:
You have explained why Sender: is better than From: (which I agree with)
but not why specifically Sender needs to be used.
Existing practice is less risky than new practice. The existence and
semantics of Sender: has been around for 45 years. Its sema
> -Original Message-
> From: Dave Crocker
> Sent: 25 June 2020 14:36
> To: David I
> Cc: IETF DMARC WG
> Subject: Re: [dmarc-ietf] What if... Sender:
>
> On 6/25/2020 1:54 AM, David I wrote:
> > Without forcing alignment to 'From', an attacker c
]ARGH! Accidentally hit send. I was going to continue with... It is
unlikely that an organization would do so even if all it's users were
subscribers because now any mail sent through the list is validated for the
organization. We go round and round because of a mismatch in granularity.
Ultimately,
On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker wrote:
> On 6/24/2020 8:09 AM, Dotzero wrote:
>
> Sender: is completely irrelevant to the use of DMARC now.
>
> Actually, I'm claiming it isn't.
>
> Or rather, I'm claiming there is a failure to appreciate that it is really
> Sender information that is
On 6/25/2020 3:14 AM, Alessandro Vesely wrote:
Frequently, an inbound message has one or more valid DKIM signatures,
and/or passes SPF, yet it fails DMARC; that is, the authenticated
domain(s) are not aligned with From:. Now it's obvious that any of
those authenticated domain(s) could as well ha
On 6/25/2020 1:54 AM, David I wrote:
Without forcing alignment to 'From', an attacker can set their own 'Sender',
set a 'From' they're not entitled to use that's of a trusted contact, and the
DMARC associated with the abused domain in the 'From' has no effect and can't
be used for filtering. S
On Wed 24/Jun/2020 19:37:46 +0200 Dave Crocker wrote:
> On 6/24/2020 9:31 AM, Alessandro Vesely wrote:
>> On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
>>> So if Sender: wouldn't be as useful as From:, why not?
>>
>> The assertion that "DMARC protects the domain name in the address part
>>
> -Original Message-
> From: Dave Crocker
> Sent: 24 June 2020 14:48
> To: David I ; IETF DMARC WG
> Subject: Re: [dmarc-ietf] What if... Sender:
>
> On 6/24/2020 2:56 AM, David I wrote:
> > Specifically, alignment on 'From' allows automated checks ag
In article you write:
>The core issue is that most of us want senders to prove their right to send on
>behalf of any asserted
>identities, of which From is the most important.
Could you be more specific about "us" in "most of us"?
It sure doesn't include me.
R's,
John
The core issue is that most of us want senders to prove their right to send on behalf of any asserted identities, of which From is the most important.SPF did not solve the problem because validating an invisble field was insufficient for detecting unauthorized identity claims.Turning DMARC into ano
On 6/24/2020 4:12 PM, Douglas E. Foster wrote:
If DMARC settles on Sender, what tool will validate the relationship
between Sende and From?
None.
Please explain why you think it has to. Not in terms of theory but in
terms of observable practice.
d/
--
Dave Crocker
Brandenburg InternetWork
If DMARC settles on Sender, what tool will validate the relationship between
Sende and From?
On Jun 24, 2020 2:53 PM, Dave Crocker wrote:On 6/24/2020
11:35 AM, Jim Fenton wrote:
> On 6/23/20 9:19 PM, Dave Crocker wrote:
>> On 6/23/2020 4:14 PM, Jim Fenton wrote:
>>> I do have a concern about Se
On 6/24/20 11:52 AM, Dave Crocker wrote:
> On 6/24/2020 11:35 AM, Jim Fenton wrote:
>> On 6/23/20 9:19 PM, Dave Crocker wrote:
>> Please explain why it is important that specifically the Sender:
>> header field be used for this.
>
> From: is demonstrably problematic. Sender: isn't.
>
> Sender: is
On 6/24/2020 11:35 AM, Jim Fenton wrote:
On 6/23/20 9:19 PM, Dave Crocker wrote:
On 6/23/2020 4:14 PM, Jim Fenton wrote:
I do have a concern about Sender:. It has existing semantics defined in
RFC 5322 Section 3.6.2, and this proposal might conflict with that
I don't think it conflicts at all
I doubt that tbe end result is the right one, but you need to articulate
the transition process.
Your proposal requires that all commercial mail systems be changed so that
their DMARC-enabled clients can send this missing field. Simultaneously,
all mail filters must be rewritten to use the new
On 6/23/20 9:19 PM, Dave Crocker wrote:
> On 6/23/2020 4:14 PM, Jim Fenton wrote:
>> I do have a concern about Sender:. It has existing semantics defined in
>> RFC 5322 Section 3.6.2, and this proposal might conflict with that
>
>
> I don't think it conflicts at all. So it will help for you to expl
On 6/24/2020 9:31 AM, Alessandro Vesely wrote:
On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
So if Sender: wouldn't be as useful as From:, why not?
I'm a bit skeptic.
The assertion that "DMARC protects the domain name in the address part
of the From:" would have to be dropped.
Of cou
On 6/24/2020 8:09 AM, Dotzero wrote:
Sender: is completely irrelevant to the use of DMARC now.
Actually, I'm claiming it isn't.
Or rather, I'm claiming there is a failure to appreciate that it is
really Sender information that is important, not author information.
The fact that DMARC only h
On Tue 23/Jun/2020 20:49:11 +0200 Dave Crocker wrote:
> So if Sender: wouldn't be as useful as From:, why not?
I'm a bit skeptic.
The assertion that "DMARC protects the domain name in the address part
of the From:" would have to be dropped. The requirement that From:
domain be "the identifier u
On 6/23/2020 2:49 PM, Dave Crocker wrote:
The would produce obvious possibilities:
From: someone@goodplace.example
Sender: someone@goodplace.example
and
From: somone@goodplace.example
Sender: some...@mlm.example.com
where there might be a dmarc record for mlm.example.com
Th
On 6/24/2020 10:07 AM, Dave Crocker wrote:
On 6/24/2020 7:04 AM, Jesse Thompson wrote:
Wouldn't MUAs need to consistently display Sender?
They don't consistently display From:
More importantly, MUAs are essentially -- or completely -- irrelevant
to the use of DMARC now. I don't see why that
On Wed, Jun 24, 2020 at 10:07 AM Dave Crocker wrote:
> On 6/24/2020 7:04 AM, Jesse Thompson wrote:
> > On 6/23/20 1:49 PM, dcroc...@gmail.com wrote:
> >> So... what if DMARC's semantic were really for the Sender: field? If a
> message has no separate Sender: field, then of course the domain in t
On 6/24/2020 7:04 AM, Jesse Thompson wrote:
On 6/23/20 1:49 PM, dcroc...@gmail.com wrote:
So... what if DMARC's semantic were really for the Sender: field? If a message
has no separate Sender: field, then of course the domain in the From: field is
used.
Wouldn't MUAs need to consistently dis
On 6/23/20 1:49 PM, dcroc...@gmail.com wrote:
> So... what if DMARC's semantic were really for the Sender: field? If a
> message has no separate Sender: field, then of course the domain in the From:
> field is used.
Wouldn't MUAs need to consistently display Sender?
Jesse
On 6/24/2020 2:56 AM, David I wrote:
Specifically, alignment on 'From' allows automated checks against addresses of
known, trusted contacts from addressbooks
So does alignment on Sender. Yes, the addresses in From: vs. Sender:
might be different, but that doesn't mean the same assessment mec
> -Original Message-
> From: dmarc On Behalf Of Dave Crocker
> Sent: 23 June 2020 19:49
> To: IETF DMARC WG
> Subject: [dmarc-ietf] What if... Sender:
>
> [...]
> So if Sender: wouldn't be as useful as From:, why not?
>
Hi Dave,
I don't think this a
On 6/23/2020 4:14 PM, Jim Fenton wrote:
I do have a concern about Sender:. It has existing semantics defined in
RFC 5322 Section 3.6.2, and this proposal might conflict with that
I don't think it conflicts at all. So it will help for you to explain
your concern in detail.
d/
--
Dave Crocke
On 6/23/20 11:49 AM, Dave Crocker wrote:
> So... what if DMARC's semantic were really for the Sender: field? If
> a message has no separate Sender: field, then of course the domain in
> the From: field is used.
>
> The would produce obvious possibilities:
>
> From: someone@goodplace.example
>
Folks,
This note is partially triggered by Mike's note this morning, but isn't
specifically responding to it. Rather it tries to elaborate on a
premise I've been implying but haven't been explicating:
What if the rfc5322.Sender field were typically/always present?
Or at least, wha
49 matches
Mail list logo
