> 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
It appears that Neil Anuskiewicz said:
>Do you all think we should mention the decline and fall of the failure report?
>I think that Yahoo! is the only major MBP that still sends
>failure reports. I think the others may have stopped over PII concerns.
I still get a dozen a day. They're not
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 Mar 17, 2024, at 9:12 AM, Alessandro Vesely wrote:
>
> On Sun 17/Mar/2024 16:50:40 +0100 internet-drafts wrote:
>> Internet-Draft draft-ietf-dmarc-failure-reporting-10.txt is now available. It
>> is a work item of the Domain-based Message Authentication, Reporting &
>> Conformance
> 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
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,
On April 7, 2024 4:32:06 PM UTC, "John R. Levine" wrote:
>On Sat, 6 Apr 2024, Scott Kitterman wrote:
>> As a side effect of the switch to the tree walk approach in DMARCbis, this is
>> no longer true. For any subdomain without a DMARC record, the domains above
>> it in the tree are also
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
> 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 Sat, 6 Apr 2024, Scott Kitterman wrote:
As a side effect of the switch to the tree walk approach in DMARCbis, this is
no longer true. For any subdomain without a DMARC record, the domains above
it in the tree are also checked, so you can specify a different policy/
reporting address for
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
> 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
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
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
>>
> 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,
Count| Bytes | Who
++---
103 ( 100%) | 943897 ( 100%) | Total
17 (16.5%) | 99355 (10.5%) | Alessandro Vesely
16 (15.5%) | 151624 (16.1%) | Murray S. Kucherawy
10 ( 9.7%) | 134619 (14.3%) | Seth Blank
10 ( 9.7%) | 67352 ( 7.1%) | Scott
17 matches
Mail list logo