John, you have a solid theoretical argument, but mail senders are
pragmatists, not theorists.
There are still filtering products in use that evaluate SPF but not DMARC.
In the products that I have seen up close, they only act on SPF FAIL, and
ignore SPF NONE. But without certainty about how
> > Presumably, a sender who uses DMARC might publish SPF to cover
> > recipients who don't use DMARC, but would prefer that recipients use
> > DMARC (authenticated by DKIM only).
>
> I get that, but that's still simultaneously saying "use SPF to
> authenticate me" and "don't use SPF to
On Jun 23, 2023, at 1:54 PM, John R Levine wrote:
>
>> My understanding is that if `auth=dkim` then SPF would be ignored from the
>> perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and
>> only SPF is DMARC aligned then it would still be treated as a DMARC fail.
>
> That's
Presumably, a sender who uses DMARC might publish SPF to cover
recipients who don't use DMARC, but would prefer that recipients use
DMARC (authenticated by DKIM only).
I get that, but that's still simultaneously saying "use SPF to
authenticate me" and "don't use SPF to authenticate me." If
Presumably, a sender who uses DMARC might publish SPF to cover
recipients who don't use DMARC, but would prefer that recipients use
DMARC (authenticated by DKIM only).
Barry
On Fri, Jun 23, 2023 at 1:54 PM John R Levine wrote:
>
> > My understanding is that if `auth=dkim` then SPF would be
> On Jun 23, 2023, at 12:52 PM, John R Levine wrote:
>
> On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
>> I agree with John's point that dkim+spf doesn't make sense in the context
>> of strict DMARC enforcement (I think it provides value for p=none domains
>
> Since the aggregate reports tell
>
> > It would be a way for senders to say "yes I checked that all my DKIM
> > signatures are working and aligned, I don't need you to look at SPF and
> > don't want to have the risk of SPF Upgrades.
>
> So why do you publish an SPF record? Presumably so someone will accept
> your mail who
My understanding is that if `auth=dkim` then SPF would be ignored from the
perspective of DMARC. So if a receiver sees DKIM is not DMARC aligned and
only SPF is DMARC aligned then it would still be treated as a DMARC fail.
That's my understanding.
It would be a way for senders to say "yes I
>
> > confused users misusing that option. I would support allowing the
> following
> > options for the auth tag:
> > "auth=dkim|spf (default value: same as current state), auth=dkim,
> auth=spf"
>
> The idea is that auth=dkim means you'd publish SPF records but hope people
> will ignore them,
Levine makes a good point. A less complex option would be:
auth=dkim # apply dkim only, ignore spf, dkim failure is
dmarc=fail
auth=spf# apply spf only, ignore dkim, spf failure is
dmarc=fail
the default auth=dkim,spf SHOULD NOT be explicitly be required. It
adds no
On Thu 22/Jun/2023 19:34:43 +0200 Jan Dušátko wrote:
Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a):
On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF and DKIM
support, and to support senders that want to drop SPF as one
On Thu, 22 Jun 2023, Emanuel Schorsch wrote:
I agree with John's point that dkim+spf doesn't make sense in the context
of strict DMARC enforcement (I think it provides value for p=none domains
Since the aggregate reports tell you what authentication worked, I don't
even see that as a benefit.
Is there a use case for "SPF only"?
1) "We use ESPs but we never sign, so don't expect one."
2) "We have so many problems with DKIM reply that you should ignore
signatures even if they verify."
3) "We never sign, so if you see a failed signature, it is a fraud attempt."
None of these seem
13 matches
Mail list logo
