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
I'd vote for discussing the "auth=" tag proposal at IETF-118, and I can
participate remotely. Discussing this on the mailing list is easier, but
will be drawn out as it's harder to understand if there is consensus one
way or the other. The advantage is that this will time box the discussion
and I
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 October 28, 2023 5:38:00 PM UTC, Barry Leiba wrote:
>I'm starting this in a separate thread that I want to keep for ONLY
>the following question:
>
>Do we want to use the session we have scheduled at IETF 118 to talk
>about the issue that clearly is still in discussion about adding a tag
>to
I'm starting this in a separate thread that I want to keep for ONLY
the following question:
Do we want to use the session we have scheduled at IETF 118 to talk
about the issue that clearly is still in discussion about adding a tag
to specify which authentication mechanism(s) to use when evaluating
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
16 matches
Mail list logo