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
Murray S. Kucherawy writes:
> Some sort of contract or agreement between sender and receiver
> seems to me to be unavoidable if we want to leverage ARC without
> having a global domain reputation system. We don't have a
> precise method to do that. We need to experiment and
>
Seth Blank writes:
> In order from most to least contentious:
>
> 1. 8.6. Interoperability Considerations
>
> "It is therefore critical that domains that host users who might
> post messages to mailing lists SHOULD NOT publish p=reject."
>
> While this advice represents consensus, it does not
Alessandro Vesely writes:
> On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
> > On SPF, our document should say simply,
> > " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
> > result,
> > prior to receiving the Data section and checking for aligned and verifiable
>
John Levine writes:
> It appears that Todd Herr said:
> >I agree that clarifying it can't hurt, obviously, ...
>
> I disagree, it does hurt.
>
> If we say you're allowed to use CNAMEs to point to DMARC records,
> people are to say uh oh, is there something special here? What about
> DKIM
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
>
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
Hector Santos writes:
> o Concerning p=reject:
>
>- Our focus on p=reject should be expanded to include p=quarantine
> as they're both challenging. We should perhaps categorize these under
> 'Restrictive Policies'.
I will repeat the point I made in the mic in IETF: I think DMARC
should
Douglas Foster writes:
> Baptiste's proposal is clearly the easiest to implement: Admins inform the
> group that IETF is going to stop munging on a specific date. After that date,
> subscribers are switched to digest mode if the MLM or the user detects
> problems. Admins switch them back when
Wei Chuang writes:
> 2) The proposed language calls out "“alumni forwarders”, role-based email
> aliases, and mailing lists" for consideration by receivers. How should
> receivers be aware that traffic failing authentication should be reconsidered?
> Mailing-lists sometimes uses RFC2919 List-id
Barry Leiba writes:
> > 2) As others have observed, the mailing list problem is
> > exclusively an evaluator error. An evaluator's job is to allow
> > safe and wanted messages while blocking unsafe or unwanted
> > messages.
>
> I disagree. As I and others have observed, those creating the
Murray S. Kucherawy writes:
> On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> Consequently, the problem remains: How does an evaluator distinguish
> between a legitimate list and a malicious attack?
>
> If we had a reliable answer to
Scott Kitterman writes:
> You can equally argue that these receivers are merely following the
> policy advice provided by the sending domain (it has reject right in
> the name) and this problem is entirely generated by sender's
> inappropriate use of p=reject.
True, thats why the proposed text
Brotman, Alex writes:
> I suspect the portion that instructs receivers to not act solely on
> p=reject may be ignored by a fair set of receivers. I'm not
> necessarily opposed to the language below, just that it seems odd to
> create language that we know will be ignored.
If receivers ignore
Jan Dušátko writes:
> Scott, Barry,
> as far as I understand, SPF are historic technology, but still have a
> reason why to use it. In my opinion (and concerns), it is also necessary
> to be aware of the extension of the individual protection methods
> provided by senders (amount of domains).
Alessandro Vesely writes:
> On Mon 26/Jun/2023 19:32:53 +0200 Douglas Foster wrote:
> > DKIM+SPF says "our domain, including subdomains covered by this policy,
> > will never use an ESP". (Since most ESP messages pass SPF based on the ESP
> > domain)
That is incorrect. It would also mean we will
Tero Kivinen writes:
> > What are those 0.75%, some 30k SPF - DKIM messages? Are there
> > cases of DKIM random failure salvaged by SPF?
>
> My current analysis script does not try to calculate that, I would
> need to need to add that step there and rerun the script. If I
&
Alessandro Vesely writes:
> On Tue 13/Jun/2023 23:33:50 +0200 Tero Kivinen wrote:
> > [...]
> >
> > As you can see 85.75% of incoming email was already signed by DKIM,
> > and 86.5% of emails had SPF records that passed. So they both have
> > about same amount
Murray S. Kucherawy writes:
> On Tue, Jun 13, 2023 at 10:34 PM Tero Kivinen wrote:
>
> DKIM failures
>
> 36.34% 26619 invalid DKIM record
>
> This is staggering. Can
Barry Leiba writes:
> > DKIM only: ~99.5%
> > DKIM + SPF: ~100%
> > SPF only: ~100%
>
> That's interesting and disturbing if it remains consistent.
The statistics I have are quite different. The failure rate is much
bigger both in DKIM and SPF.
Following statistics is random subset of emails
20 matches
Mail list logo
