> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely wrote:
>
> On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely
>>> wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-only
On a theoretical level, probabilistic tools like spam assassin will be
predictably wrong some of the time. Accurate disposition requires audits
and overrides using static rules based on confirmed evidence. I cannot
find much sympathy for sites that enforce SPF without considering DKIM and
withou
On Sun 29/Oct/2023 21:03:17 +0100 Mark Alley wrote:
Giving this some more thought from the opposite point of view... the benefits
to an auth=DKIM method in DMARC itself would remove the need for domain owners
to do SPF tinkering for any upgrade mitigation, and shared mail infrastructure
where o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Douglas Foster
writes
>By contrast, the new tag cannot be effective until DMARCbis is published
>and filtering software updated. This involves years.
Hard to say ... there is some self-interest here in having shiny new
features (such
Murray S. Kucherawy writes:
> On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated. This involves years. Even then, domain
> owners
On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated. This involves years. Even then, domain
> owners will never have confidence that the new token
Giving this some more thought from the opposite point of view... the
benefits to an auth=DKIM method in DMARC itself would remove the need for
domain owners to do SPF tinkering for any upgrade mitigation, and shared
mail infrastructure where one could potentially be affected by SPF upgrade
could in
Reporting allows certainty within the limits of the reporting mechanism.
My inference is that many domains stop at p=none for an extended period or
forever because the reporting mechanism does not provide that certainty.
For my part, I backed away from reject when I received fail-with-reject
repor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Douglas Foster writes
>* auth=DKIMOnly requires that the domain owner have high confidence
> that every message source is applying DKIM signatures.
which of course the reporting mechanism allows them to acquire
- --
richard
I have become persuaded to Scott's approach, as long as it is documented
clearly.
For DMARC-enabled evaluators:
- auth=DKIMOnly requires that the domain owner have high confidence that
every message source is applying DKIM signatures.
- ?include=hostingservice only requires knowledge tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Wei Chuang writes
>I don't think the SPF '?' qualifier approach works because as Richard
>Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
>Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
>
>
On Sat 28/Oct/2023 16:51:27 +0200 Scott Kitterman wrote:
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely wrote:
You're the only one strongly opposing the idea, AFAICS, and I still don't know
why.
As to why, I don't think there's a valid use case and the proponents for this
haven't r
The intended purpose of using it in the referenced scenario is to avoid the
negative connotation of ~ or - on their shared infrastructure mechanism(s)
in SPF evaluation, while also producing a non-pass for SPF to DMARC.
Many receivers use the failure SPF results as additional signals to
spam/junk
On Sat 28/Oct/2023 17:28:50 +0200 Scott Kitterman wrote:
We need to add a subsection in Security Consideration, discussing an
example of an include mechanism with a neutral qualifier and its effect on
DMARC outcome; that is, how that avoids spurious authentications.
I disagree. It's already
On Sun 29/Oct/2023 07:39:09 +0100 Wei Chuang wrote:
I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
A "neutral" result MUST be t
I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
A "neutral" result MUST be treated exactly like the "none" result;
the distincti
On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote:
> > As to why, I don't think there's a valid use case and the proponents for
> > this haven't really thought it through. As an example, someone (I don't
> > recall who) cited the issue of domain owners that publish SPF, but can't
For the shared provider SPF upgrade example, I think Scott's previously
mentioned method of using SPF '?' qualifier on the relevant shared
mechanism mitigates the upgrade problem, and ensures only DKIM can provide
passing authentication.
Thinking back earlier this year to the well-publicized SPF u
>
> As to why, I don't think there's a valid use case and the proponents for
> this haven't really thought it through. As an example, someone (I don't
> recall who) cited the issue of domain owners that publish SPF, but can't be
> bothered to set up DKIM. The implication is that this minimum effo
Fwiiw, Lurker opinion:
I ideally vote to make DMARCBis Experimental Status and begin to explore the
“required” integration between envelope (5321 only) protocols and payload
(5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling
with 3rd party signature support.
But reali
On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton
wrote:
> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.
>
Why does it have to be infe
On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote:
> In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
> writes
>
> >What's your plan for when easily getting a DMARC pass due to bad SPF
> >records doesn't work anymore, so the bad guys focus more on DKIM replay?
>
> At
On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote:
> >Even if we don't add the feature, we should address the vulnerability.
Currently there is only a bullet in Section 4.8, Organizational Domain
Discovery, saying:
> > * The domain found in the RFC5321.MailFrom header if there i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
writes
>What's your plan for when easily getting a DMARC pass due to bad SPF records
>doesn't work anymore, so the bad guys focus more on DKIM replay?
At $DAYJOB$, DKIM replay is simply not
On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote:
> In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
> Vesely writes
>
> >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
> >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely
wrote:
> >>>If we
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely wrote:
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
Vesely writes
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>>>If we add the feature, we should in any
On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-only feature, which seems to be the
case, I agree, wrap up the few minor editoria
On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
>> It appears that Scott Kitterman said:
That is unfortunately true, but if we could decouple the DMARC from SPF,
then at least we could fix the situation at some poin
On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
It appears that Scott Kitterman said:
That is unfortunately true, but if we could decouple the DMARC from
SPF, then at least we could fix the situation at some point...
I propose that we not repeat this discussion and instead, try to focus
I concur with what Doug mentioned. As someone on the receiving end of bad
press due to an exploit of what I perceive to be weaknesses in the DMARC
standards particularly around depending on SPF [1], and then had to drop
everything to mitigate, I would suggest taking this opportunity to
strengthen
On Thu, Oct 26, 2023 at 8:25 PM Scott Kitterman
wrote:
>
>
>
> I propose that we not repeat this discussion and instead, try to focus on
> finishing.
>
> Scott K
>
Agreed. +1
Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/
It appears that Scott Kitterman said:
>>That is unfortunately true, but if we could decouple the DMARC from
>>SPF, then at least we could fix the situation at some point...
>
>I propose that we not repeat this discussion and instead, try to focus on
>finishing.
If there isn't a consensus to do
Like Ale, I thought the group had agreed to implement an auth=DKIM-only
option of some type.
I understood the motivation to be false pass created by malicious
forwarding through a legitimate hosting platform. Therefore SPF precision
is an unrelated issue.
Doug
On Thu, Oct 26, 2023, 5:46 PM Ter
On October 26, 2023 9:46:04 PM UTC, Tero Kivinen wrote:
>John Levine writes:
>> It appears that Scott Kitterman said:
>> >>* Is there consensus on moving ahead with the idea of a way to indicate
>> >>which authentication method(s) the Domain Owner wants Receivers to use? If
>> >>so, it doesn
John Levine writes:
> It appears that Scott Kitterman said:
> >>* Is there consensus on moving ahead with the idea of a way to indicate
> >>which authentication method(s) the Domain Owner wants Receivers to use? If
> >>so, it doesn't seem to be in the document yet.
> >
> >I haven't seen any vali
On Wed 25/Oct/2023 16:01:01 +0200 Scott Kitterman wrote:
On October 25, 2023 1:37:55 PM UTC, John Levine wrote:
It appears that Scott Kitterman said:
I haven't seen any valid case for it yet. It adds complexity to little or no benefit.
[...]
There's the counterargument "so don't publis
On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman writes
>
> >>> My reading of the discussion is:
> >>>
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
> sadly so, it would have been the right thing to do
>
>
On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> >
> > checklists
> >
> > >that even though that would be a fine idea, it's not practical.
> >
> > Diving into the SPF angle, if someone has a 'legi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Scott
Kitterman writes
>>> My reading of the discussion is:
>>>
>>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
sadly so, it would have been the right thing to do
>>> 2. We did not have rough consensus to
>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant
On October 25, 2023 1:37:55 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>>so, it doesn't seem to be in the document
It appears that Scott Kitterman said:
>>* Is there consensus on moving ahead with the idea of a way to indicate
>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>so, it doesn't seem to be in the document yet.
>
>I haven't seen any valid case for it yet. It adds comp
On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman
wrote:
>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
> * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s) the
On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use?
If so, it doesn't
On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use? If
so, it doesn't seem to be in the document yet.
My recall is that we want to limit DMARC evalu
On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba wrote:
> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use? If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we wa
> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use? If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases o
On Wed 25/Oct/2023 05:38:01 +0200 Murray S. Kucherawy wrote:
On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba wrote:
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
A few questions, but they don't demand in-person time if we want to
On Tue 24/Oct/2023 20:15:22 +0200 Barry Leiba wrote:
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
IMHO this one.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.i
On October 25, 2023 3:38:01 AM UTC, "Murray S. Kucherawy"
wrote:
>On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
>wrote:
>
>> Now that we have a consensus call on the main issue that has remained open:
>>
>> 1. Do we need to retain our session at IETF 118 and discuss this (or
>> something else)
On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
wrote:
> Now that we have a consensus call on the main issue that has remained open:
>
> 1. Do we need to retain our session at IETF 118 and discuss this (or
> something else) further?
>
> ...or...
>
> 2. Do we have what we need to finish up the DMARCb
On 10/24/2023 2:15 PM, Barry Leiba wrote:
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
should
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
Oh,
54 matches
Mail list logo
