Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Douglas Foster]

 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 all evaluators operate,
there is a strong incentive to keep SPF PASS in place.   I note that
Gmail.com still has an SPF Policy.

Adding a flag to evaluate DMARC without SPF allows a sender to navigate the
market differences between DMARC-aware and DMARC-ignorant evaluators.

Doug



On Fri, Jun 23, 2023 at 3:30 PM John R Levine  wrote:

> > 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 SPF is so
> unreliable that you don't want people to use it for your DMARC alignment,
> why would you want them to use it otherwise?
>
> I worry this is encouraging security theater, look I have super secure
> DMARC p=reject and, we won't get our deliverability numbers without a big
> fuzzy SPF record.
>
> R's,
> John
> >
> > 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 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 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 wouldn't otherwise, except you just said they shouldn't.
> >> Still not making sense to me.
> >>
> >> Regards,
> >> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> >> Please consider the environment before reading this e-mail.
> https://jl.ly
> >>
> >> ___
> >> dmarc mailing list
> >> dmarc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmarc
> >
> >
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Barry Leiba]

> > 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 SPF is so
> unreliable that you don't want people to use it for your DMARC alignment,
> why would you want them to use it otherwise?

Because it's not better than DKIM and adds no value over DKIM... but
it's better than *nothing*, so if you don't check DKIM, I'm providing
SPF for you.

> I worry this is encouraging security theater, look I have super secure
> DMARC p=reject and, we won't get our deliverability numbers without a big
> fuzzy SPF record.

If the alternative to DMARC p=reject, for recipients who don't handle
that, is nothing at all, I don't see that providing SPF is bad.  And
if you don't want that, don't publish an SPF record.  But for now,
DMARC isn't deployed widely enough that we can fully deprecate SPF,
and SPF does still provide value when a receiver isn't implementing
DMARC.

If the DMARC spec makes that clear, I think we win.  And recipients
can still do what they want: if DMARCbis goes out with "use DKIM only"
and a recipient wants to use SPF anyway, they can do that... just as a
recipient that decides to use best-guess-SPF in the absence of actual
SPF records is free to make that choice.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

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 my understanding.
> 
>> 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 wouldn't otherwise, except you just said they shouldn't. Still not 
> making sense to me.

I believe because the domain may still want the restrictive SPF -ALL  and DMARC 
p=reject or p=quarantine for normal direct messages but they recognize users 
will be contacting people where a SPF will fail due to a forward.

If you remove the SPF record or weaken it with ~ALL or ?ALL, then it weakens 
the majority of non-forwarded direct transactions. The proposed tag `auth=dkim` 
will indicate to gmail that SPF failing is ok as long as the first party DKIM 
signature is still intact.   It’s weaker but would be less problematic than it 
is today.

Today, we can modify the return path for the forward or don’t allow for forward 
and make the (gmail) user pick up the mail via POP3/IMAP.  No forwarding.

—
HLS

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[John R Levine]

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 SPF is so 
unreliable that you don't want people to use it for your DMARC alignment, 
why would you want them to use it otherwise?


I worry this is encouraging security theater, look I have super secure 
DMARC p=reject and, we won't get our deliverability numbers without a big 
fuzzy SPF record.


R's,
John


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 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 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 wouldn't otherwise, except you just said they shouldn't.
Still not making sense to me.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc





Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Barry Leiba]

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 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 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 wouldn't otherwise, except you just said they shouldn't.
> Still not making sense to me.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> 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 you what authentication worked, I don't even 
> see that as a benefit.  There's also the question how many people would even 
> look at a DMARC v2 tag which would be a prerequisite for the auth tag.

DMARC v1 supports extended tags.  See section 3.1.3 in RFC 7489:

https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.3



3.1.3 .  Alignment 
and Extension Technologies

   If in the future DMARC is extended to include the use of other
   authentication mechanisms, the extensions will need to allow for
   domain identifier extraction so that alignment with the RFC5322 
.From
   domain can be verified.





> 
> The idea is that auth=dkim means you'd publish SPF records but hope people 
> will ignore them, or vice versa for auth=dkim?  I still don't get it.
> 

The immediate benefit would be forwarders. I believe Wei labeled this form of 
forwarding REM in the PDF analysis posted recently.

With REM forwarders, in SMTP transport terms, it is a passthru message 
forwarded to a recorded address given by the local domain or locally hosted 
domain Recipient , untouched data.  MTA inbound to MTA outbound. The MDA, like 
gmail.com , would see an SPF failure so the DMARC auth=dkim 
relaxed option tells GMAIL that the hard fail with SPF is acceptable, ignore 
it, but expect the DKIM to be valid from the author signer domain.

Who sets this tag?  The initial sender that unbeknownst to this sender, the MX 
Is not the final MDA.  We will never know that information of where a contact 
can be reached.  The Hosted Domain market is very big and important.

So it will be a matter of training system admins that domains with any chance 
of being indirect, it will probably be a good idea to use a relaxed SPF 
evaluation for DMARC1.

We will not need a version bump. 

—
HLS



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

>
> > 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 wouldn't otherwise, except you just said they shouldn't.
> Still not making sense to me.
>

DKIM Replay is still an issue. If you don't publish any SPF record then
your mail will look fairly similar to replay attacks. In this case the SPF
isn't helping recipients accept mail that has a broken DKIM, it's helping
recipients additionally reject/spam-folder replayed mail which will
according to the spec have a DMARC pass.

But putting aside DKIM Replay I think most senders would still want to
publish an SPF record since SPF has been around for a while and many
reputation systems use it as one of the factors. You just wouldn't be
publishing an SPF record to help from a DMARC perspective.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[John R Levine]

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 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 wouldn't otherwise, except you just said they shouldn't. 
Still not making sense to me.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

>
> > 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, or vice versa for auth=dkim?  I still don't get it.
>

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.

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. I will still keep an updated
SPF record, but if you see a message that's only SPF aligned then don't
consider that a DMARC pass."
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

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 additional security value.  I would like to note that some DNS 
Zone Managers with DMARC record support will add the complete tags 
available for the protocol with the default conditions making the 
record look more complex than it really it.


Other system integration options would (forgive me for I have sinned):

atps=1 # we support ATPS protocol for 3rd party signer.
rewrite=1  # we are perfectly fine with Author Rewrite

--
HLS





On 6/22/2023 10:18 PM, John Levine wrote:

It appears that Emil Gustafsson   said:

I don't know if there is a better way to encode that, but I'm supportive of
making a change that that would allow domains to tell us (gmail) that they
prefer us to require both dkim and spf for DMARC evaluation (or whatever
combination of DKIM and SPF they desire).

I really don't understand what problem this solves. More likely people
will see blog posts telling them auth=dkim+spf is "more secure",
they'll add that without understanding what it means, and all that
will happen is that more of their legit mail will disappear.

If you're worried about DKIM replay attacks, let's fix that rather
than trying to use SPF, which as we know has all sorts of problems of
its own, as a band-aid.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc





--
Hector Santos,
https://santronics.com
https://winserver.com



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal

[Alessandro Vesely]

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 of their DMARC 
authentication methods to avoid the SPF upgrade vulnerability.


After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, 
besides or and one only, for domains that want that extra security.  Possible 
values, for example, auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, 
auth=spf.


Possibility of choosing policy based on evaluation of the SPF, SPF and DKIM, SPF 
or DKIM event. DKIM itself in DMARC2 will be really helpful. In case of DKIM 
and SPF need to pass, seems to be little bit different results than previous. 
This will definitely satisfy me for thousands of domains.



Requiring both DKIM and SPF to be aligned and verified is very harsh. 
Forwarding would be disallowed, except for specific agreements.  It wouldn't be 
handy for general purpose mail domains, but could beat replay in some cases.


Albeit reckless users would have the possibility to shoot their own feet, DMARC 
aggregate reports should provide a good forecast of the results.



Best
Ale
--






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[John R Levine]

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.  There's also the question how many people 
would even look at a DMARC v2 tag which would be a prerequisite for the 
auth tag.



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, or vice versa for auth=dkim?  I still don't get it.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Douglas Foster]

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 important to me.

Doug

On Fri, Jun 23, 2023, 12:43 AM Emanuel Schorsch  wrote:

>
>
> On Thu, Jun 22, 2023 at 7:18 PM John Levine  wrote:
>
>> It appears that Emil Gustafsson   said:
>> >I don't know if there is a better way to encode that, but I'm supportive
>> of
>> >making a change that that would allow domains to tell us (gmail) that
>> they
>> >prefer us to require both dkim and spf for DMARC evaluation (or whatever
>> >combination of DKIM and SPF they desire).
>>
>> I really don't understand what problem this solves. More likely people
>> will see blog posts telling them auth=dkim+spf is "more secure",
>> they'll add that without understanding what it means, and all that
>> will happen is that more of their legit mail will disappear.
>>
>> If you're worried about DKIM replay attacks, let's fix that rather
>> than trying to use SPF, which as we know has all sorts of problems of
>> its own, as a band-aid.
>>
>> R's,
>> John
>>
>
> 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
> but it's not worth that complexity). If we leave out `dkim+spf` as an
> option then we can still solve >90% of the problem at hand without having
> 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"
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc