> On Apr 7, 2024, at 6:20 PM, Scott Kitterman wrote:
>
>
>
>> On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz
>> wrote:
>>
>>
On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>>>
>>>
>>>
On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
Scott Kitterman writ
On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz
wrote:
>
>
>> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>>
>>
>>
>>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>>>
>>> Scott Kitterman writes:
I hear you. Your operational issue is my system working as designed.
> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote:
>
>
>
>> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>>
>> Scott Kitterman writes:
>>> I hear you. Your operational issue is my system working as designed.
>>> DMARC works on top of SPF, it doesn't change it.
>>
>> Yes, DMARC work
We can complain about people treating SPF Fail as definitive, but DMARC
perpetuates the very same myth, which is:
“If Sender Authentication test X produces FAIL, then the message is
malicious and should be blocked.”
It does not matter whether "X" is SPF Fail, DKIM Fail, ADSP Fail, DMARC
Fail, or
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
This WG should have finished a year ago. Unless you think something is so
broken that it's worth more months of delay, forget it.
To be clear I was suggesting considering deprecating the hardfail modifier only
as it’s archaic. I was not saying depr
> On Apr 7, 2024, at 9:27 AM, John R Levine wrote:
>
> On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
>> I think clear statement and supporting text explaining clearly that SPF is
>> no longer the policy layer would be a good idea. While it might be slightly
>> out of scope, I have encountered
On Sun, 7 Apr 2024, Neil Anuskiewicz wrote:
I think clear statement and supporting text explaining clearly that SPF is no
longer the policy layer would be a good idea. While it might be slightly out of
scope, I have encountered people who think best practice is to enforce with
-ALL.
We had a
> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote:
>
> Scott Kitterman writes:
>> I hear you. Your operational issue is my system working as designed.
>> DMARC works on top of SPF, it doesn't change it.
>
> Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
> are trying to
Scott Kitterman writes:
> I hear you. Your operational issue is my system working as designed.
> DMARC works on top of SPF, it doesn't change it.
Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We
are trying to change the fact that people rely purely on SPF, and try
to get them
That would probably be a question better placed on the SPFbis list, and
(IETF veterans, keep me honest) it probably wouldn't be able to be
addressed fully unless SPFter becomes a thing at some point.
Outside of unnecessary/unexpected uses of it (due to reasons outlined
previously in the thread
Forgive me if this a dumb idea but, Scott and others, any discussion of just
deprecating SPF hardfail at some point?
> On Apr 6, 2024, at 1:40 PM, John Levine wrote:
>
> It appears that Scott Kitterman said:
>> I hear you. Your operational issue is my system working as designed. DMARC
>> w
> On Apr 6, 2024, at 1:40 PM, John Levine wrote:
>
> It appears that Scott Kitterman said:
>> I hear you. Your operational issue is my system working as designed. DMARC
>> works on top of SPF, it doesn't change it.
>>
>> Anything like this belongs in an operational guidance document, no
It appears that Scott Kitterman said:
>I hear you. Your operational issue is my system working as designed. DMARC
>works on top of SPF, it doesn't change it.
>
>Anything like this belongs in an operational guidance document, not in the
>protocol description. I have no problem describing th
I hear you. Your operational issue is my system working as designed. DMARC
works on top of SPF, it doesn't change it.
Anything like this belongs in an operational guidance document, not in the
protocol description. I have no problem describing the trade offs in an
appropriate document, but
You’re not hearing me— this is something that comes up frequently for
organizations working to implement DMARC. Others have confirmed on list.
This is not an academic concern, it’s an operational one as elevated by the
charter.
Your other examples you cited do not come up in practice as issues for
The same thing can be said for every step of email processing that comes
before DMARC. If I reject your mail due to your IP being on a block list, you
also don't get DMARC feedback about it.
It was long enough ago that I don't remember if it was RFC 7489 or early in
this working group, but we
Scott, I disagree.
SPF hardfail in a DMARC context is an operational issue that comes up with
some frequency for domain owners.
We should have some minimal amount of clarifying text.
S, individually
Seth Blank | Chief Technology Officer
Email: s...@valimail.com
This email and all data transmi
On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote:
> Greetings.
>
> Issue 141 has been opened to collect ideas around the discussion about what
> to say in DMARCbis (if anything) about honoring SPF records that end in
> -all when SPF fails.
>
> https://github.com/ietf-wg-dmarc/draft-ietf-dm
Greetings.
Issue 141 has been opened to collect ideas around the discussion about what
to say in DMARCbis (if anything) about honoring SPF records that end in
-all when SPF fails.
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141
--
Todd Herr | Technical Director, Standards
19 matches
Mail list logo
