Count| Bytes | Who
++---
89 ( 100%) | 839060 ( 100%) | Total
15 (16.9%) | 100275 (12.0%) | Scott Kitterman
11 (12.4%) | 88013 (10.5%) | Murray S. Kucherawy
11 (12.4%) | 65112 ( 7.8%) | Alessandro Vesely
5 ( 5.6%) | 53320 ( 6.4%) | Dotzero
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
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
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 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
-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, Oct 28, 2023 at 1:38 PM 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 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 , 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
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
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
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
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
-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
14 matches
Mail list logo
