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

[Tero Kivinen]

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). This is not a deep analysis. It 
> is possible that the numbers given will not be accurate.
> SPF    87%
> DKIM    13%
> DMARC 63%
> ARC         5%

How were those values calculated? They are very different compared to
the actual mails going through different servers. Is this calculated
from the domains used, not from emails processed? How many emails was
used to calculate this statistics, how many domains were there in
total?

> In terms of provability, each DKIM signed email will be sent from the 
> owner of the authorized servers. Ideally, therefore, it is not necessary 
> to combine SPF and DKIM, only DKIM could be sufficient.

Yes.

> However, the following situations are a problem. As a rule,
> DKIM+DMARC is not fully implemented, part of the domains are
> protected by DKIM, part by DKIM + SPF, part by SPF only.

Thats why I think it is important that we get more DKIM
implementations for DMARC. 

> - Only DKIM and DMARC are implemented, yet the SPAM distributor sends an 
> email without the DKIM signature and without the key information.

SPAM distributors are not interesting here, DMARC/DKIM/SPF are not
protecting against spam, there is no way they could ever be efficient
for that.

If there is no DKIM signature the message is not authenticated to
originate from the domain where it claims to be, thus it will not gain
from the possible whitelisting, better reputation etc associated with
the domain.

> - Only DKIM and DMARC are implemented, and a signed email is available. 
> The SPAM distributor starts repeatedly sending the same email 
> (equivalent to a DOS attack).

It is very easy to filter identical emails, especially when they are
actually signed with same dkim signature, thus you can safely mark
later emails as duplicates, and not deliver them to mailbox.

I do not think there is ever need to deliver duplicate emails to same
mailbox, thus you can safely remove them.

If the RCPT TO is different than the To-header inside the body, that
is one of the checks that spam checking software quite often use to
check whether the email is spam. I.e., if the To-header does not have
actual address of the mailbox the message is supposed to be delivered
to, then give some positive spam points to the message.

If this is forwarded email (i.e. the to-address contains something
like kivi...@iki.fi, instead the address where my emails finally gets
forwarded to) then the user who set up the forwarding most likely
already added those addresses as "valid recipient addresses" to their
mail settings, thus forwarded emails do not get marked as spam.

And of course if thousands of different mailboxes in your system are
getting same DKIM signed message, and some of the users start marking
it as spam, that is good indication that others are too, thus your
spam checking software can learn from that and start processing those
emails differently. 

> - Only DKIM and DMARC are implemented, and a signed email based on 
> RSA+SHA1 is available. Because it is possible to find collisions for 
> SHA1, and the digital signature is actually an "encrypted hash," it is 
> possible to send counterfeit mail with a signature that looks genuine. 
> The solution is to use explicitly h=sha2, but if not specified, it is 
> also possible to "downgrade the signature" against another key on this 
> domain supporting SHA1 (any SHA1-based signature will be used).

In stackexchange there was question about this:
https://crypto.stackexchange.com/questions/99767/how-easy-is-it-in-2022-to-find-a-sha1-collision

The first answer was that using single GPU it would take about 5.3
years to find collision (year 2022). Getting 30 GPUs would drop that
to 2 months, and those GPUs would cost about $20k, and the electricity
for those GPUs would cost you about $2k for 2 months.

Using AWS it would still take months and cost you few hundred dollars.

And you need to do that for every single email you want to
counterfeit.

For phishing attacks this would be feasible, i.e., if you want to take
real email from the CEO, change it and find collsion and send it
forward taking few months and costing hundreds or thousands of dollars
would be ok.

So companies who actually care about the security in DKIM should NOT
USE SHA1. For spammers this is not a feasible solution. Also if you
are using unsecure crypto parameters for DKIM (short keys, broken
hashes) you should also change those keys every now and then...

> These attacks are the first that came to my mind. How we can mitigate 
> that threat? According to owner authorization of IP addresses, they 
> protect against a different kind of attack than the digital signature by 
> using DKIM.

You did not describe any threat th

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

[Hector Santos]

A small follow up about my DMARC view:

> On Jun 30, 2023, at 4:02 PM, Hector Santos 
>  wrote:
> 
> Overall, imo, it is never a good idea to exerted changes on domains with bis 
> specs, requiring them to change their current DMARC record to reinforce the 
> security level they want using SPF in DMARC evaluation. 
> 


I don’t want surprises. Higher support cost.   But is DMARC that “messed up?”   
I mean, just like ADSP, it is abandonment material, honestly, easy.

But DMARC is big and it did one thing for the mail industry — the Lookup added 
to the SMTP process.  Moat SMTP receivers will do the the _dmarc.from-domain 
lookup.

DMARC is the #1 lookup record for this purpose,  a DKIM Policy Model.

We said very early on that but will take a while to get traction for a DKIM 
Policy model where lookups come with a good payoff, otherwise it is just wasted 
calls. 

Let’s leverage the lookup using a protocol language for a wide security 
coverage that offers dynamic rejection to clean the mail stream before passing 
it to local proprietary reputation databases.

Happy July 4th, Be safe.

—
HLS

___
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 30, 2023, at 3:32 PM, Murray S. Kucherawy  wrote:
> 
> On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko 
> mailto:40dusatko@dmarc.ietf.org>> 
> wrote:
>> Scott, Barry,
>> as far as I understand, SPF are historic technology,
> 
> Not in any official capacity.  RFC 7208 is a Proposed Standard.  In fact, in 
> IETF terms, it enjoys higher status than DMARC does right now.
> 
> The status of these protocols is not under discussion.  The only question is 
> whether DMARC should continue to factor SPF results into its output.


If I am reading the group right, using the suggested `auth=` tag for 
explanation, it appears the editor wants the new DMARCbis default to be:

auth=dkim

And it would required an explicit tag like;

auth=spf,dkim

to express a desire for spf to be in the evaluation.  This offers DMARCbis 
backward compatibility.   This would be the one “upgrade” change a domain would 
need to make, an optional “extended behavior” to make it behave like DMARC 
today.  The default behavior today is auth=spf,dkim.  DMARCbis’s default would 
be auth=dkim.

I am saying it sounds like this.  

Overall, imo, it is never a good idea to exerted changes on domains with bis 
specs, requiring them to change their current DMARC record to reinforce the 
security level they want using SPF in DMARC evaluation. 

—
HLS

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

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

[Murray S. Kucherawy]

On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko  wrote:

> Scott, Barry,
> as far as I understand, SPF are historic technology,
>

Not in any official capacity.  RFC 7208 is a Proposed Standard.  In fact,
in IETF terms, it enjoys higher status than DMARC does right now.

The status of these protocols is not under discussion.  The only question
is whether DMARC should continue to factor SPF results into its output.

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

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

[Alessandro Vesely]

On Fri 30/Jun/2023 04:07:46 +0200 Tero Kivinen wrote:

Alessandro Vesely writes:

[...]



ESPs can provide include files for those who wish otherwise.


I know that some companies in finland has included the iki.fi 
IP-addresses ranges to their SPF records, because they had several 
complains from people of SPF failures when they were sending emails to 
iki.fi addresses. We even added _spf.iki.fi DNS record for them to use 
for their include when it was requested, but I do not consider that 
good practice for solving issues of the SPF.



Agreed.  Before -all, tana.it's SPF record sports a directive like so:

?exists:%{ir}.list.dnswl.org

Neither this is a good practice, as receivers should consult a whitelist of 
their choice without having to obey an explicit request.  And dnswl.org count 
the queries they receive from each host.


IMHO, forwarding agreements should be set up at the very moment when the 
senders fixes the target address in a dot-forward recipe.



Best
Ale
--






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

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

[Jan Dušátko]

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). This is not a deep analysis. It 
is possible that the numbers given will not be accurate.

SPF    87%
DKIM    13%
DMARC 63%
ARC         5%
As technologies are deployed not in a technological continuity, but 
according to the needs of system owners, they are therefore set 
intersections. For this reason, relying only on the combination of 
DKIM+DMARC technology could be unfortunate.
In terms of provability, each DKIM signed email will be sent from the 
owner of the authorized servers. Ideally, therefore, it is not necessary 
to combine SPF and DKIM, only DKIM could be sufficient. However, the 
following situations are a problem. As a rule, DKIM+DMARC is not fully 
implemented, part of the domains are protected by DKIM, part by DKIM + 
SPF, part by SPF only.
- Only DKIM and DMARC are implemented, yet the SPAM distributor sends an 
email without the DKIM signature and without the key information.
- Only DKIM and DMARC are implemented, and a signed email is available. 
The SPAM distributor starts repeatedly sending the same email 
(equivalent to a DOS attack).
- Only DKIM and DMARC are implemented, and a signed email based on 
RSA+SHA1 is available. Because it is possible to find collisions for 
SHA1, and the digital signature is actually an "encrypted hash," it is 
possible to send counterfeit mail with a signature that looks genuine. 
The solution is to use explicitly h=sha2, but if not specified, it is 
also possible to "downgrade the signature" against another key on this 
domain supporting SHA1 (any SHA1-based signature will be used).


These attacks are the first that came to my mind. How we can mitigate 
that threat? According to owner authorization of IP addresses, they 
protect against a different kind of attack than the digital signature by 
using DKIM.


On the other hand, SPF can bring beside of advancing security particular 
security reduction. Simply because most of services are "shared in 
cloud" right now. Cloud service providers generally provide the extent 
to which virtual services can operate. It is not a question of who has 
or does not have the ability to use the service (in meaning that service 
are approved to send e-mails beside of domain). In this case, it is not 
a problem to create a system in the cloud technology that starts mimic 
and send junk mail instead of an authorized organization. The methods of 
correction are reactive, so it will take some time before such an attack 
is detected and mitigated. However, even a limitation of scope can be 
supported by DKIM, as it limits the space from which an attacker can 
operate.


The whole problem is a single one. What tools to provide the domain 
owner with to set up a policy to protect the reputation of its mail 
services. From this, another question arises:

- To what extent can domain service managers' knowledge be trusted?
- Is it possible to set up policy processing rules so that non-standard 
situations like missing signature can be handled, or allow the owner to 
define how signatures will be used?
- Is it possible to unambiguously describe the rules to avoid 
implementation errors?

- How will the problem of mail forwarders and mailing lists be addressed?

regards

Jan


Dne 28. 6. 2023 v 21:43 Scott Kitterman napsal(a):

I think it's quite relevant.

The assumption that this is based on is there's a need to specify because SPF 
data is not reliable enough for everyone.  If that premise is correct (I don't 
agree with it, but it's a separate issue), then I think telling people that 
they should use DKIM because it IS reliable, when it's got its own issues isn't 
a great idea.

I've been mulling this whole topic over and I think I'm close to having mulled 
it enough to have a useful proposal.  SPF bad, DKIM good is a gross 
over-simplification, but so is if it passed SPF, it's authorized, so go whine 
at the provider.

Scott K

On June 28, 2023 6:32:41 PM UTC, Barry Leiba  wrote:

I think DKIM replay is largely irrelevant to this discussion (about
the sender specifying which authentication to use), because if that's
your biggest concern with respect to DMARC, then "SPF only" is the
answer.  "SPF *and* DKIM" is not any better than that.


You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply

(Assuming you mean "replay".)  "SPF and DKIM" does not give any
benefit beyond "SPF only" in this case.

Look, either SPF fails because the message was relayed illegitimately...
...or SPF passes because the replayer used the sender's legitimate
infrastructure to do the replay.

Barry

On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely  wrote:

Thank you for your analysis.  However, it doesn't touch on DKIM replay.

I know this topic belongs to the ot

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

[Tero Kivinen]

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 NEVER send email to
anybody who would want to forward that email to some other place. How
is that adminstrator putting the DKIM+SPF policy be sure of that? If
they ever send any emails to customers, contractors, friends etc, they
can never be sure those emails are not forwarded, thus they can't say
DKIM+SPF.

I can easyly see some big companies wanting to lock in their customers
by making it hard to change email addresses, but we should build or
protocols for those companies, but instead allow freedom of movement
where people are reading their emails. 

> ESPs can provide include files for those who wish otherwise.

I know that some companies in finland has included the iki.fi
IP-addresses ranges to their SPF records, because they had several
complains from people of SPF failures when they were sending emails to
iki.fi addresses. We even added _spf.iki.fi DNS record for them to use
for their include when it was requested, but I do not consider that
good practice for solving issues of the SPF.
-- 
kivi...@iki.fi

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

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

[Barry Leiba]

Chair speaking and agreeing.  While I do not think it's out of scope
to think about how DKIM replay attacks affect DMARC, I think it is out
of scope to design DMARC to address DKIM replay attacks.  These two
things are very close to each other, and we're going to have to be
careful about it.  But if we find ourselves saying that we have to do
(x) in DMARC because DKIM replay attacks are a problem, and would not
need to do it otherwise, we're almost certainly on the wrong side of
that boundary.

Barry

On Thu, Jun 29, 2023 at 2:38 PM John Levine  wrote:
>
> It appears that Emanuel Schorsch   said:
> >> We are talking about SPF AND DKIM because of the problems with DKIM
> >> replay. ...
>
> I hope we agree that applying bandaids to sort of fix DKIM replay is
> out of scope for the DMARC WG.
>
> If you want to work on replay, they're down the virtual hall.
>
> https://datatracker.ietf.org/wg/dkim/about/
>
> R's,
> John
>
> ___
> 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

[John Levine]

It appears that Emanuel Schorsch   said:
>> We are talking about SPF AND DKIM because of the problems with DKIM
>> replay. ...

I hope we agree that applying bandaids to sort of fix DKIM replay is
out of scope for the DMARC WG.

If you want to work on replay, they're down the virtual hall.

https://datatracker.ietf.org/wg/dkim/about/

R's,
John

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

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

[Murray S. Kucherawy]

On Thu, Jun 29, 2023 at 4:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> But I don't have a solution for ESP messages that use DKIM to authorize
> the From, but use their own domain for SPF Pas on Mail From.   That
> requires tying the signature to the server and/or Mail From domain using a
> signature token
>

What's a signature token?

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

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

[Douglas Foster]

But I don't have a solution for ESP messages that use DKIM to authorize the
From, but use their own domain for SPF Pas on Mail From.   That requires
tying the signature to the server and/or Mail From domain using a signature
token

On Thu, Jun 29, 2023, 1:25 AM Murray S. Kucherawy 
wrote:

> On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> We are talking about SPF AND DKIM because of the problems with DKIM
>> replay.   Can someone summarize the state of the DKIM update options that
>> have been ruled in or ruled out?
>>
>
> There's a document over in that working group that takes a run at doing so.
>
> I'm worried about the complexity and assumptions in the proposal that
> follows:
>
> Given a received sequence of
>>
>>- Msg Date
>>- Rcv Date 1
>>- Rcv Date 2
>>- 
>>- Rcv Date N
>>
>> A signature should have a start time between one of these date boundaries.
>>
>
> There's no reason to trust the dates, IP addresses, or any other detail in
> these header fields beyond infrequent manual diagnostic efforts.  They are
> trivially forged and rarely signed.   You definitely should not attempt to
> couple anything you infer from them with the semantics of a passing
> cryptographic signature.
>
> The first global IP after the signature server becomes the perimeter
>> server which must demonstrate that it's domain has the right to act on
>> behalf of the signing domain.
>>
>
> That sounds like the very definition of SPF.
>
> By "global" I presume you mean "publicly routed".  Do we really want to
> start teaching mail software how to determine which IP addresses are
> publicly routed?  It's not as simple as the RFC 1918 question.
>
> Improvements within control of the signing server:
>>
>> If the message is not created by the originating server, the message
>> should contain one or more Received headers.   The header list on the
>> signature should contain "Received" entries to match the number of Received
>> headers at the time of signing.   This further identifies the signature's
>> position in the Received chain.
>>
>
> The original DKIM RFC (RFC 4871) specified a list of header fields that
> SHOULD and SHOULD NOT be signed, and Received was in the latter group.
> It's common for Received fields to be stripped when they depart a domain in
> order to conceal the topology within that domain.  Less commonly, they can
> get reordered, edited, or re-wrapped.  Any of those would break the
> signature if it covered them.
>
> RFC 6376, the standard, dropped the SHOULD and SHOULD NOT, but still
> discourages paying any attention to Received when signing.
>
>
>> Improvements requiring changes to the DKIM specification
>>
>> They could identify a way to document the signing server's domain in the
>> signature.
>>
>
> Isn't that the "d=" tag?
>
> -MSK, participating
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We are talking about SPF AND DKIM because of the problems with DKIM
> replay.   Can someone summarize the state of the DKIM update options that
> have been ruled in or ruled out?
>

There's a document over in that working group that takes a run at doing so.

I'm worried about the complexity and assumptions in the proposal that
follows:

Given a received sequence of
>
>- Msg Date
>- Rcv Date 1
>- Rcv Date 2
>- 
>- Rcv Date N
>
> A signature should have a start time between one of these date boundaries.
>

There's no reason to trust the dates, IP addresses, or any other detail in
these header fields beyond infrequent manual diagnostic efforts.  They are
trivially forged and rarely signed.   You definitely should not attempt to
couple anything you infer from them with the semantics of a passing
cryptographic signature.

The first global IP after the signature server becomes the perimeter server
> which must demonstrate that it's domain has the right to act on behalf of
> the signing domain.
>

That sounds like the very definition of SPF.

By "global" I presume you mean "publicly routed".  Do we really want to
start teaching mail software how to determine which IP addresses are
publicly routed?  It's not as simple as the RFC 1918 question.

Improvements within control of the signing server:
>
> If the message is not created by the originating server, the message
> should contain one or more Received headers.   The header list on the
> signature should contain "Received" entries to match the number of Received
> headers at the time of signing.   This further identifies the signature's
> position in the Received chain.
>

The original DKIM RFC (RFC 4871) specified a list of header fields that
SHOULD and SHOULD NOT be signed, and Received was in the latter group.
It's common for Received fields to be stripped when they depart a domain in
order to conceal the topology within that domain.  Less commonly, they can
get reordered, edited, or re-wrapped.  Any of those would break the
signature if it covered them.

RFC 6376, the standard, dropped the SHOULD and SHOULD NOT, but still
discourages paying any attention to Received when signing.


> Improvements requiring changes to the DKIM specification
>
> They could identify a way to document the signing server's domain in the
> signature.
>

Isn't that the "d=" tag?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Emanuel Schorsch]

On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We are talking about SPF AND DKIM because of the problems with DKIM
> replay.   Can someone summarize the state of the DKIM update options that
> have been ruled in or ruled out?
>

I'll clarify how I view SPF AND DKIM in relation to DKIM Replay. Let's use
bob.com as the domain:

   - If DK=bob.com and SPF=bob.com then NOT dkim replay.
   - If DK=bob.com and SPF!=bob.com then MAYBE dkim replay (of course
   probability of dkim replay varies widely, and could still be 0 for this
   particular SPF)
   - If DK=bob.com and SPF!=bob.com and DMARC policy is SPF AND DKIM then
   LIKELY dkim replay if seen in large volumes.

So the value of that DMARC policy for DKIM Replay is that bob.com can be
better protected against heavy replays because they have a way to say "I've
checked all my direct flows have SPF AND DK aligned. If you see mail with a
different SPF you can be sure it's an indirect flow and be more aggressive
about quota limiting large volumes."

To be clear, that would be a benefit for protecting aligned domains that
are replayed, but I'm NOT suggesting this is enough benefit to allow users
to set SPF AND DKIM for a DMARC auth policy. I agree with others that it's
a footgun, and it would be better to convey this information in some other
way.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Douglas Foster]

We are talking about SPF AND DKIM because of the problems with DKIM
replay.   Can someone summarize the state of the DKIM update options that
have been ruled in or ruled out?

We have the DARA proposal from Google, which is related to signature
replay, but focused on ARC.  I am guessing that it correlates closely to
the DKIM updates.  Should the discussion move to that draft for a bit?

I also look forward to Scott's ideas.

DARA limits replay by linking the signature to a recipient.   An
alternative approach is to limit replay be linking the signature to a
source server.   It may be less effective, but some benefit can be gained
from this approach, which does not require a DKIM rewrite.   Here are my
thoughts:

Given a received sequence of

   - Msg Date
   - Rcv Date 1
   - Rcv Date 2
   - 
   - Rcv Date N


A signature should have a start time between one of these date boundaries.

   - If the signature start time is equal to, or shortly, after, a Received
   header timestamp, the signing server is the BY server which create the
   Received header.
   - If the signature start time is prior to any Received header timestamp,
   but on or after the message Date header, then the FROM information on the
   first Received header identifies the signing server.
   - If the signature start time is prior to the message Date header, the
   signature looks suspicious

In some cases, clock skew may create ambiguity about the signing server.
Even when this occurs, the ambiguous servers are likely to lie behind the
same perimeter server, so the ambiguity may not need to be resolved.

The first global IP after the signature server becomes the perimeter server
which must demonstrate that it's domain has the right to act on behalf of
the signing domain.

   - We do an SPF test on the perimeter server's IP address and the
   signature domain.  If this test produces SPF PASS, the signature has
   enhanced trust.
   - If the perimeter server domain matches the signature domain, and the
   perimeter server host name can be forward confirmed to its IP address, this
   provides an alternative to SPF PASS.
   - If either test succeeds, the risk of DKIM reply is significantly
   lessened.   If neither test succeeds, then the signature risk of DKIM
   replay is greater

Improvements within control of the signing server:

If the message is not created by the originating server, the message should
contain one or more Received headers.   The header list on the signature
should contain "Received" entries to match the number of Received headers
at the time of signing.   This further identifies the signature's position
in the Received chain.

Improvements requiring changes to the DKIM specification

They could identify a way to document the signing server's domain in the
signature.   Then the perimeter server host names can be tested to see if
they match the signature's server domain and can be forward-confirmed to
the Source IP.   This provides an alternative to SPF for configurations
where the server domain and the signature domain are different
organizations.

Doug Foster



On Wed, Jun 28, 2023 at 3:44 PM Scott Kitterman 
wrote:

> I think it's quite relevant.
>
> The assumption that this is based on is there's a need to specify because
> SPF data is not reliable enough for everyone.  If that premise is correct
> (I don't agree with it, but it's a separate issue), then I think telling
> people that they should use DKIM because it IS reliable, when it's got its
> own issues isn't a great idea.
>
> I've been mulling this whole topic over and I think I'm close to having
> mulled it enough to have a useful proposal.  SPF bad, DKIM good is a gross
> over-simplification, but so is if it passed SPF, it's authorized, so go
> whine at the provider.
>
> Scott K
>
> On June 28, 2023 6:32:41 PM UTC, Barry Leiba 
> wrote:
> >I think DKIM replay is largely irrelevant to this discussion (about
> >the sender specifying which authentication to use), because if that's
> >your biggest concern with respect to DMARC, then "SPF only" is the
> >answer.  "SPF *and* DKIM" is not any better than that.
> >
> >> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM
> reply
> >
> >(Assuming you mean "replay".)  "SPF and DKIM" does not give any
> >benefit beyond "SPF only" in this case.
> >
> >Look, either SPF fails because the message was relayed illegitimately...
> >...or SPF passes because the replayer used the sender's legitimate
> >infrastructure to do the replay.
> >
> >Barry
> >
> >On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely 
> wrote:
> >>
> >> Thank you for your analysis.  However, it doesn't touch on DKIM replay.
> >>
> >> I know this topic belongs to the other list.  Let me briefly recall it,
> if this
> >> doesn't take too many cycles from core matters:  It occurs when a signed
> >> message is replayed by unauthorized hosts to recipients which were not
> >> originally addressed.  So, it is one case of your 3rd proposition

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

[Scott Kitterman]

I think it's quite relevant.

The assumption that this is based on is there's a need to specify because SPF 
data is not reliable enough for everyone.  If that premise is correct (I don't 
agree with it, but it's a separate issue), then I think telling people that 
they should use DKIM because it IS reliable, when it's got its own issues isn't 
a great idea.

I've been mulling this whole topic over and I think I'm close to having mulled 
it enough to have a useful proposal.  SPF bad, DKIM good is a gross 
over-simplification, but so is if it passed SPF, it's authorized, so go whine 
at the provider.

Scott K

On June 28, 2023 6:32:41 PM UTC, Barry Leiba  wrote:
>I think DKIM replay is largely irrelevant to this discussion (about
>the sender specifying which authentication to use), because if that's
>your biggest concern with respect to DMARC, then "SPF only" is the
>answer.  "SPF *and* DKIM" is not any better than that.
>
>> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply
>
>(Assuming you mean "replay".)  "SPF and DKIM" does not give any
>benefit beyond "SPF only" in this case.
>
>Look, either SPF fails because the message was relayed illegitimately...
>...or SPF passes because the replayer used the sender's legitimate
>infrastructure to do the replay.
>
>Barry
>
>On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely  wrote:
>>
>> Thank you for your analysis.  However, it doesn't touch on DKIM replay.
>>
>> I know this topic belongs to the other list.  Let me briefly recall it, if 
>> this
>> doesn't take too many cycles from core matters:  It occurs when a signed
>> message is replayed by unauthorized hosts to recipients which were not
>> originally addressed.  So, it is one case of your 3rd proposition: In some
>> scenarios, DKIM will pass when SPF fails.
>>
>> You say that it is technically unnecessary to test both because DKIM should
>> always pass when SPF passes (1st proposition).
>>
>> You claim:
>> > But where the harm comes is in cases of mis-configuration, because now if
>> > *either* of them is misconfigured, the whole thing fails -- neither of them
>> > serves as a backup for the other; instead, the misconfiguration of either
>> > one causes deliverability problems.
>>
>>
>> I agree.  But what if SPF and DKIM are both configured properly?  You seem to
>> imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your
>> analysis doesn't cover that case explicitly.
>>
>> Perhaps there are better ways to counter that specific problem, and certainly
>> it's not what this WG is tasked to do.  But, just to make the point, I think
>> it's interesting to know.
>>
>>
>> Best
>> Ale
>>
>>
>> On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote:
>> > I don't understand how most of your message fits into this discussion:
>> > you're comparing SPF's policy points with DMARC policy.  we're talking
>> > about SPF as an authentication mechanism together with DKIM (not
>> > DMARC) as an authentication mechanism... and then using those
>> > authentication results in DMARC policy evaluation.
>> >
>> > But here: I've said all this before in separate places, so I'll put it
>> > in one place, here, one more time:
>> >
>> > Given that SPF and DKIM are both configured properly:
>> > 1. If SPF passes, DKIM will always pass.
>> > 2. If DKIM fails, SPF will always fail.
>> > 3. In some scenarios, DKIM will pass when SPF fails.
>> >
>> > Therefore, when everything is configured properly, SPF adds no value
>> > beyond what DKIM does, and DKIM does add value beyond what SPF does.
>> > That's why I am (and others are) arguing that we should remove SPF
>> > *from DMARC evaluation*.  There's no argument that for now, or some,
>> > SPF outside of DMARC still has value.
>> >
>> > What others are arguing is that in the real world, things do get
>> > mis-configured, and if DKIM is misconfigured and fails when it
>> > shouldn't, SPF adds value by providing a working authentication.
>> > (And, of course, similarly the other way around, plus DKIM covers some
>> > cases when messages are relayed or forwarded.)  That speaks for "SPF
>> > *or* DKIM".
>> >
>> > But "SPF *and* DKIM" -- requiring *both* to pass -- is technically
>> > unnecessary at best, because of (1) above: DKIM should always pass
>> > when SPF passes.  But where the harm comes is in cases of
>> > mis-configuration, because now if *either* of them is misconfigured,
>> > the whole thing fails -- neither of them serves as a backup for the
>> > other; instead, the misconfiguration of either one causes
>> > deliverability problems.  DMARC is damaged by requiring an
>> > authentication situation that is unnecessary when things are properly
>> > configured, and that is more fragile than what we've been using, more
>> > susceptible to configuration errors than we've seen before.
>> >
>> > And I'm afraid that people will use it preferentially, *thinking* that
>> > it provides better "security" -- surely, double authentication is
>> > better

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

[Barry Leiba]

I think DKIM replay is largely irrelevant to this discussion (about
the sender specifying which authentication to use), because if that's
your biggest concern with respect to DMARC, then "SPF only" is the
answer.  "SPF *and* DKIM" is not any better than that.

> You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply

(Assuming you mean "replay".)  "SPF and DKIM" does not give any
benefit beyond "SPF only" in this case.

Look, either SPF fails because the message was relayed illegitimately...
...or SPF passes because the replayer used the sender's legitimate
infrastructure to do the replay.

Barry

On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely  wrote:
>
> Thank you for your analysis.  However, it doesn't touch on DKIM replay.
>
> I know this topic belongs to the other list.  Let me briefly recall it, if 
> this
> doesn't take too many cycles from core matters:  It occurs when a signed
> message is replayed by unauthorized hosts to recipients which were not
> originally addressed.  So, it is one case of your 3rd proposition: In some
> scenarios, DKIM will pass when SPF fails.
>
> You say that it is technically unnecessary to test both because DKIM should
> always pass when SPF passes (1st proposition).
>
> You claim:
> > But where the harm comes is in cases of mis-configuration, because now if
> > *either* of them is misconfigured, the whole thing fails -- neither of them
> > serves as a backup for the other; instead, the misconfiguration of either
> > one causes deliverability problems.
>
>
> I agree.  But what if SPF and DKIM are both configured properly?  You seem to
> imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your
> analysis doesn't cover that case explicitly.
>
> Perhaps there are better ways to counter that specific problem, and certainly
> it's not what this WG is tasked to do.  But, just to make the point, I think
> it's interesting to know.
>
>
> Best
> Ale
>
>
> On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote:
> > I don't understand how most of your message fits into this discussion:
> > you're comparing SPF's policy points with DMARC policy.  we're talking
> > about SPF as an authentication mechanism together with DKIM (not
> > DMARC) as an authentication mechanism... and then using those
> > authentication results in DMARC policy evaluation.
> >
> > But here: I've said all this before in separate places, so I'll put it
> > in one place, here, one more time:
> >
> > Given that SPF and DKIM are both configured properly:
> > 1. If SPF passes, DKIM will always pass.
> > 2. If DKIM fails, SPF will always fail.
> > 3. In some scenarios, DKIM will pass when SPF fails.
> >
> > Therefore, when everything is configured properly, SPF adds no value
> > beyond what DKIM does, and DKIM does add value beyond what SPF does.
> > That's why I am (and others are) arguing that we should remove SPF
> > *from DMARC evaluation*.  There's no argument that for now, or some,
> > SPF outside of DMARC still has value.
> >
> > What others are arguing is that in the real world, things do get
> > mis-configured, and if DKIM is misconfigured and fails when it
> > shouldn't, SPF adds value by providing a working authentication.
> > (And, of course, similarly the other way around, plus DKIM covers some
> > cases when messages are relayed or forwarded.)  That speaks for "SPF
> > *or* DKIM".
> >
> > But "SPF *and* DKIM" -- requiring *both* to pass -- is technically
> > unnecessary at best, because of (1) above: DKIM should always pass
> > when SPF passes.  But where the harm comes is in cases of
> > mis-configuration, because now if *either* of them is misconfigured,
> > the whole thing fails -- neither of them serves as a backup for the
> > other; instead, the misconfiguration of either one causes
> > deliverability problems.  DMARC is damaged by requiring an
> > authentication situation that is unnecessary when things are properly
> > configured, and that is more fragile than what we've been using, more
> > susceptible to configuration errors than we've seen before.
> >
> > And I'm afraid that people will use it preferentially, *thinking* that
> > it provides better "security" -- surely, double authentication is
> > better than single, no?
> >
> > No.
> >
> > Barry
> >
> > On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely  wrote:
> >>
> >> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> >>> I'm saying I don't want "and" to be an option, because I think it's
> >>> damaging to DMARC.  There is no reason anyone should ever want to say
> >>> that, and providing the option asks for misconfigurations because
> >>> people think it's somehow "more secure".  It's not more secure.  It
> >>> would be very bad for deliverability of legitimate mail and would
> >>> provide no additional security.  It would be a terrible mistake.
> >>
> >>
> >> I've been sporting spf-all for years, and seldom experienced bounces, 
> >> mostly
> >> due to misconfigured secondary MXes.  Out of 39

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

[Alessandro Vesely]

Thank you for your analysis.  However, it doesn't touch on DKIM replay.

I know this topic belongs to the other list.  Let me briefly recall it, if this 
doesn't take too many cycles from core matters:  It occurs when a signed 
message is replayed by unauthorized hosts to recipients which were not 
originally addressed.  So, it is one case of your 3rd proposition: In some 
scenarios, DKIM will pass when SPF fails.


You say that it is technically unnecessary to test both because DKIM should 
always pass when SPF passes (1st proposition).


You claim:
But where the harm comes is in cases of mis-configuration, because now if 
*either* of them is misconfigured, the whole thing fails -- neither of them 
serves as a backup for the other; instead, the misconfiguration of either 
one causes deliverability problems.



I agree.  But what if SPF and DKIM are both configured properly?  You seem to 
imply that auth=dkim+spf wouldn't be effective against DKIM reply, but your 
analysis doesn't cover that case explicitly.


Perhaps there are better ways to counter that specific problem, and certainly 
it's not what this WG is tasked to do.  But, just to make the point, I think 
it's interesting to know.



Best
Ale


On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote:

I don't understand how most of your message fits into this discussion:
you're comparing SPF's policy points with DMARC policy.  we're talking
about SPF as an authentication mechanism together with DKIM (not
DMARC) as an authentication mechanism... and then using those
authentication results in DMARC policy evaluation.

But here: I've said all this before in separate places, so I'll put it
in one place, here, one more time:

Given that SPF and DKIM are both configured properly:
1. If SPF passes, DKIM will always pass.
2. If DKIM fails, SPF will always fail.
3. In some scenarios, DKIM will pass when SPF fails.

Therefore, when everything is configured properly, SPF adds no value
beyond what DKIM does, and DKIM does add value beyond what SPF does.
That's why I am (and others are) arguing that we should remove SPF
*from DMARC evaluation*.  There's no argument that for now, or some,
SPF outside of DMARC still has value.

What others are arguing is that in the real world, things do get
mis-configured, and if DKIM is misconfigured and fails when it
shouldn't, SPF adds value by providing a working authentication.
(And, of course, similarly the other way around, plus DKIM covers some
cases when messages are relayed or forwarded.)  That speaks for "SPF
*or* DKIM".

But "SPF *and* DKIM" -- requiring *both* to pass -- is technically
unnecessary at best, because of (1) above: DKIM should always pass
when SPF passes.  But where the harm comes is in cases of
mis-configuration, because now if *either* of them is misconfigured,
the whole thing fails -- neither of them serves as a backup for the
other; instead, the misconfiguration of either one causes
deliverability problems.  DMARC is damaged by requiring an
authentication situation that is unnecessary when things are properly
configured, and that is more fragile than what we've been using, more
susceptible to configuration errors than we've seen before.

And I'm afraid that people will use it preferentially, *thinking* that
it provides better "security" -- surely, double authentication is
better than single, no?

No.

Barry

On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely  wrote:


On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:

I'm saying I don't want "and" to be an option, because I think it's
damaging to DMARC.  There is no reason anyone should ever want to say
that, and providing the option asks for misconfigurations because
people think it's somehow "more secure".  It's not more secure.  It
would be very bad for deliverability of legitimate mail and would
provide no additional security.  It would be a terrible mistake.



I've been sporting spf-all for years, and seldom experienced bounces, mostly
due to misconfigured secondary MXes.  Out of 39 domains whose posts to this
list in the past year are still in my inbox, 14 have spf-all.  So, while I'm
not the only one, not many published -all even though it may seem to be somehow
more secure.

I think it can be worth to compare SPF and DMARC.  Another sender policy a
decade and an authentication method after.  What adoption, what hype.

Both policies ask receivers to reject a domain identifier in some cases.  RFC
7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC provides
for overrides but is less clear about how to handle exceptions.  After SPF
broke forwarding, the reaction was split between some changing identifier and
turning to ~all; after DMARC broke mailing lists, between changing identifier
and not altering messages.  In my limited experience, the ratio seems to be
higher for DMARC than SPF, but I may be wrong.

In theory, domains that currently have a strict DMARC policy and spf-all, 6 of
the above, should have their messages bloc

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

[Hector Santos]

Doug,  this is Wildcat! SMTP - one of the oldest SMPT packages around. Summary 
here:

Without some signal at wcSMTP about DMARC,  SPF will most likely remain a hard 
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA

Background:

Since 2003, out of the box, Wildcat! SMTP with add-on tools, wcSAP and wcDKIM, 
the mail flow is:

(Note: for the record, email is a small part of winserver.com, but a supportive 
part for many customer operations)

At SMTP, starting with remote client connection:

1) If Enabled, Check for DNS-RBL IP check, respond at step 8 in order to 
collect envelope data.
2.0) Check for smtpfilter-connect.wcx script, run it if found
2.1) Check for Geo-Location IP Blocks, very unethical practice.
3) HELO/EHLO: Check EHLO/HELO on technical merit like IP Literal matching 
Connect IP (CIP)
4) MAIL FROM: Check for Local domain MAIL FROM spoof
5) MAIL FROM: Accept 250 pending RCPT validation
6) RCPT TO: not valid 550 
7) RCPT TO: Valid starts WCSAP.WCX (p-code) Wait for Response.

At WCSAP (Wildcat! Sender Authorization Protocol):

8)  WCSAP: Record if DNS-RBL IP blocked at 1, exit response 55z
9) WCSAP: Run sysop-defined text-based simple White/Block Accept/Reject If rules
10) WCSAP: Run SPF.  Failure return 55z or 45z
11) WCSAP: Run CBV,  Failure return 55z or 45z
12) WCSAP: return 250

Back to WCSMTP RCPT state

8) RCPT response provided, reject 55z/45z or 250 continue, Receiver-SPF header 
prepended.
9) DATA is transferred, Received: trace line prepended.
10 Before DATA response, run stack of SMTP mail filters written in-house or 3rd 
party:

At  SMTPFILTER-xxx.wcx, specifically SMTPFILTER-DKIM-VERIFY.WCX

11) Check for ADSP + ATPS
12) Check For DMARC + ATPS
13) Record Authentication-Results
14) DMARC Rejection Failures are DISABLED. Auth-Res Prepended.
15) Return any 55z, 45z or 250 based on SMTPFILTER-,wcx filters.

Back to DATA, 

16) DATA response is provided.
17) 250 mail is accepted, router signaled for MDA import or MTA forwarding.
18) Wait 30 seconds for client new transaction command, QUIT and/or DROP

Pretty much it.  

We have too much invested in our integrated Wildcat! Internet Net Server mail 
platform — one of the oldest platforms since the 80s. 

My long time customers, sysops, sysadms, love the flexibility and  p-code and 
low code programmability for operators and 3rd party developers!  

I have provided the DMARC option to the SMTPFILTER-DKIM-VERIFY.WCX to return 
55z response for DMARC p=reject but it is compiler disabled.  However, anyone 
can write a new mail filter script to run at DATA for DMARC, but it has yet to 
happen.  Not surprise there.   If we don’t provide it, I don’t expect them to 
do it.

In WCSAP, the SPF handling of the result can be set to not reply with 55z for a 
SPF hard failure.  

This will allow SMTPFILTER-DKIM-VERIFY.WCX to see a SPF=fail Received-SPF 
header. But at the moment, out of the box, DMARC will never see a SPF reject.

From an innocent IETF implementor, my integration enhancement for DMARC might 
be:

With SUBMITTER enabled, you will MOST DEFINITELY see this from supportive 
clients:

C: MAIL FROM: SUBMITTER=pra 

where pra is Purported Responsible Address, normally 5322.From,  Low volume or 
not, you will see it.

I plan to use the PRA to get DMARC information. 

First I will assume the signer is aligned so the next check is for return-path 
alignment.  

Second, if auth=dkim tag exist,  I could offer an option to relax SPF in both 
WCSAP.WCX and SMTPFILTER-DKIM-VERIFY.WCX.

Without some signal at wcSMTP about DMARC,  SPF will most likely remain a hard 
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA.

—
HLS

> On Jun 27, 2023, at 7:58 AM, Douglas Foster 
>  > wrote:
> 
> Ale, here is an attempt at a formal model.   Application to the current 
> question is at the very end.
> 
> Any test (DKIM, SPF, ARC) has these result possibilities:
> Pass
> No data or uncertain result
> Fail
> 
> The test results are imperfect, so we have to consider these probabilities
> 
> Probability that PASS is a correct result
>Probability that a false PASS will be whitelisted or not blocked in 
> content filtering
>  Net result that a false PASS is delivered to the user
> 
> Probability that a NoData / Uncertain result is correct (presumed 100%).
>   Probability that an Uncertain message is wanted or unwanted.
>   Probability that an unwanted message is or is not blocked by 
> content filtering
>Net probability that an unauthenticated and unwanted message 
> is delivered to the user
> 
> Probability that FAIL is a correct result
>   Probability that a FAIL result is blocked by local policy (presumed 
> 100%)
>Probability that a false FAIL is actually wanted
>   Net probability that false FAIL blocks a wanted message
> 
> My strategy is documented in my "Best Practices" draft submission.   To 
> sum

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

[Hector Santos]

+1

> On Jun 27, 2023, at 11:06 AM, Tobias Herkula 
>  wrote:
> 
> Signing That, nothing to add.
> 
> -Original Message-
> From: dmarc  On Behalf Of Barry Leiba
> Sent: Tuesday, June 27, 2023 4:24 PM
> To: Alessandro Vesely 
> Cc: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
> 
> I don't understand how most of your message fits into this discussion:
> you're comparing SPF's policy points with DMARC policy.  we're talking about 
> SPF as an authentication mechanism together with DKIM (not
> DMARC) as an authentication mechanism... and then using those authentication 
> results in DMARC policy evaluation.
> 
> But here: I've said all this before in separate places, so I'll put it in one 
> place, here, one more time:
> 
> Given that SPF and DKIM are both configured properly:
> 1. If SPF passes, DKIM will always pass.
> 2. If DKIM fails, SPF will always fail.
> 3. In some scenarios, DKIM will pass when SPF fails.

Yes, since SPF comes first, by far, in my empirical field experience, if SPF 
fails, odds are good DKIM will fail.   But if DKIM passes, then it can be 
interesting to see if this can fix a false positive with SPF.

—
HLS

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

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

[Hector Santos]

Since 2003, here is my out of the box, Wildcat! SMTP with wcSAP and wcDKIM 
add-on support, mail flow: 

(Note: for the record, email is a small Part, but a supportive part for many 
customer operations)

At SMTP, starting with connection

1) If Enabled, Check for DNS-RBL IP check, respond at step 8
2.0) Check for smtpfilter-connect.wcx script, run it if found
2.1) Check for Geo-Location IP Blocks, very unethical practice.
3) HELO/EHLO: Check EHLO/HELO on technical merit like IP Literal matching 
Connect IP (CIP)
4) MAIL FROM: Check for Local domain MAIL FROM spoof
5) MAIL FROM: Accept 250 pending RCPT validation
6) RCPT TO: not valid 550 
7) RCPT TO: Valid starts WCSAP.WCX (p-code) Wait for Response.

At WCSAP:

8)  WCSAP: Record if DNS-RBL IP blocked at 1, exit response 55z
9) WCSAP: Run sysop-defined text-based simple White/Block Accept/Reject If rules
10) WCSAP: Run SPF.  Failure return 55z or 45z
11) WCSAP: Run CBV,  Failure return 55z or 45z
12) WCSAP: return 250

Back to WCSMTP RCPT state

8) RCPT response provided, reject 55z/45z or 250 continue, Receiver-SPF header 
prepended.
9) DATA is transferred, Received: trace line prepended.
10 Before DATA response, run stack of SMTP mail filters written in-house or 3rd 
party:

At  SMTPFILTER-xxx.wcx, specifically SMTPFILTER-DKIM-VERIFY.WCX

11) Check for ADSP + ATPS
12) Check For DMARC + ATPS
13) Record Authentication-Results
14) DMARC Rejection Failures are DISABLED. Auth-Res Prepended.
15) Return any 55z, 45z or 250 based on SMTPFILTER-,wcx filters.

Back to DATA, 

16) DATA response is provided.
17) 250 mail is accepted, router signaled for MDA import or MTA forwarding.
18) Wait 30 seconds for client new transaction command, QUIT and/or DROP

Pretty much it.  

We have too much invested in the integrated Wildcat! Internet Net Server 
platform — one of the oldest platforms since the 80s.

My long time customers, sysops, sysadms, love the flexibility and  p-code and 
low code programmability for 3rd party developers!  

I have provided the DMARC option to the SMTPFILTER-DKIM-VERIFY.WCX to return 
55z response for DMARC p=reject but it is compiler disabled.  However, anyone 
can write a new mail filter script to run at DATA for DMARC, but it has yet to 
happen.  Not surprise there.   If we don’t provide it, I don’t expect them to 
do it.

In WCSAP, the SPF handling of the result can be set to not reply with 55z for a 
SPF hard failure.  

This will allow SMTPFILTER-DKIM-VERIFY.WCX to see a SPF=fail Received-SPF 
header. But at the moment, out of the box, DMARC will never see a SPF reject.

From an innocent IETF implementor, my integration enhancement for DMARC might 
be:

With SUBMITTER enabled, you will MOST DEFINITELY see this from supportive 
clients:

C: MAIL FROM: SUBMITTER=pra 

where pra is Purported Responsible Address, normally 5322.From,  Low volume or 
not, you will see it.

I plan to use the PRA to get DMARC information. 

First I will assume the signer is aligned so the next check is for return-path 
alignment.  

Second, if auth=dkim tag exist,  I could offer an option to relax SPF in both 
WCSAP.WCX and SMTPFILTER-DKIM-VERIFY.WCX.

Without some signal at wcSMTP about DMARC,  SPF will most likely remain a hard 
rejection at WCSAP/SMTP (at RCPT state) before DMARC at DATA.

—
HLS

> On Jun 27, 2023, at 7:58 AM, Douglas Foster 
>  wrote:
> 
> Ale, here is an attempt at a formal model.   Application to the current 
> question is at the very end.
> 
> Any test (DKIM, SPF, ARC) has these result possibilities:
> Pass
> No data or uncertain result
> Fail
> 
> The test results are imperfect, so we have to consider these probabilities
> 
> Probability that PASS is a correct result
>Probability that a false PASS will be whitelisted or not blocked in 
> content filtering
>  Net result that a false PASS is delivered to the user
> 
> Probability that a NoData / Uncertain result is correct (presumed 100%).
>   Probability that an Uncertain message is wanted or unwanted.
>   Probability that an unwanted message is or is not blocked by 
> content filtering
>Net probability that an unauthenticated and unwanted message 
> is delivered to the user
> 
> Probability that FAIL is a correct result
>   Probability that a FAIL result is blocked by local policy (presumed 
> 100%)
>Probability that a false FAIL is actually wanted
>   Net probability that false FAIL blocks a wanted message
> 
> My strategy is documented in my "Best Practices" draft submission.   To 
> summarize my experience:
> - The frequency of a true PASS is high, so the probability of a false PASS is 
> low
> - The probability of a false PASS being detected by content filtering is 
> pretty good.
> - The frequency of a true FAIL is low, so the probability of a false FAIL is 
> high.
> - Uncertain messages have a high percentage of unwanted messages, but also a 
> non-trivial volume of wanted messages.
> 

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

[Tobias Herkula]

Signing That, nothing to add.

-Original Message-
From: dmarc  On Behalf Of Barry Leiba
Sent: Tuesday, June 27, 2023 4:24 PM
To: Alessandro Vesely 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

I don't understand how most of your message fits into this discussion:
you're comparing SPF's policy points with DMARC policy.  we're talking about 
SPF as an authentication mechanism together with DKIM (not
DMARC) as an authentication mechanism... and then using those authentication 
results in DMARC policy evaluation.

But here: I've said all this before in separate places, so I'll put it in one 
place, here, one more time:

Given that SPF and DKIM are both configured properly:
1. If SPF passes, DKIM will always pass.
2. If DKIM fails, SPF will always fail.
3. In some scenarios, DKIM will pass when SPF fails.

Therefore, when everything is configured properly, SPF adds no value beyond 
what DKIM does, and DKIM does add value beyond what SPF does.
That's why I am (and others are) arguing that we should remove SPF *from DMARC 
evaluation*.  There's no argument that for now, or some, SPF outside of DMARC 
still has value.

What others are arguing is that in the real world, things do get 
mis-configured, and if DKIM is misconfigured and fails when it shouldn't, SPF 
adds value by providing a working authentication.
(And, of course, similarly the other way around, plus DKIM covers some cases 
when messages are relayed or forwarded.)  That speaks for "SPF
*or* DKIM".

But "SPF *and* DKIM" -- requiring *both* to pass -- is technically unnecessary 
at best, because of (1) above: DKIM should always pass when SPF passes.  But 
where the harm comes is in cases of mis-configuration, because now if *either* 
of them is misconfigured, the whole thing fails -- neither of them serves as a 
backup for the other; instead, the misconfiguration of either one causes 
deliverability problems.  DMARC is damaged by requiring an authentication 
situation that is unnecessary when things are properly configured, and that is 
more fragile than what we've been using, more susceptible to configuration 
errors than we've seen before.

And I'm afraid that people will use it preferentially, *thinking* that it 
provides better "security" -- surely, double authentication is better than 
single, no?

No.

Barry

On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely  wrote:
>
> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> > I'm saying I don't want "and" to be an option, because I think it's 
> > damaging to DMARC.  There is no reason anyone should ever want to 
> > say that, and providing the option asks for misconfigurations 
> > because people think it's somehow "more secure".  It's not more 
> > secure.  It would be very bad for deliverability of legitimate mail 
> > and would provide no additional security.  It would be a terrible mistake.
>
>
> I've been sporting spf-all for years, and seldom experienced bounces, 
> mostly due to misconfigured secondary MXes.  Out of 39 domains whose 
> posts to this list in the past year are still in my inbox, 14 have 
> spf-all.  So, while I'm not the only one, not many published -all even 
> though it may seem to be somehow more secure.
>
> I think it can be worth to compare SPF and DMARC.  Another sender 
> policy a decade and an authentication method after.  What adoption, what hype.
>
> Both policies ask receivers to reject a domain identifier in some 
> cases.  RFC
> 7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC 
> provides for overrides but is less clear about how to handle 
> exceptions.  After SPF broke forwarding, the reaction was split 
> between some changing identifier and turning to ~all; after DMARC 
> broke mailing lists, between changing identifier and not altering 
> messages.  In my limited experience, the ratio seems to be higher for DMARC 
> than SPF, but I may be wrong.
>
> In theory, domains that currently have a strict DMARC policy and 
> spf-all, 6 of the above, should have their messages blocked when 
> either method fails, up to changing identifiers.  Why would it be so 
> bad for deliverability to additionally require DMARC alignment, which 
> is the difference between that and the "and"?
>
> And, it seems to me that an ESP not having a bloated SPF record could 
> stop a good deal of DKIM replay by resorting to auth=dkim+spf.  
> Besides collateral deliverability problems, why wouldn't that work?
>
> Wht would "and" damage DMARC more than -all damaged SPF?
>
> I hope we can discuss detailed criticism rather than vague ostracism.
>
>
> Best
> Ale
> --
>
>
>
>
>

___
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]

I don't understand how most of your message fits into this discussion:
you're comparing SPF's policy points with DMARC policy.  we're talking
about SPF as an authentication mechanism together with DKIM (not
DMARC) as an authentication mechanism... and then using those
authentication results in DMARC policy evaluation.

But here: I've said all this before in separate places, so I'll put it
in one place, here, one more time:

Given that SPF and DKIM are both configured properly:
1. If SPF passes, DKIM will always pass.
2. If DKIM fails, SPF will always fail.
3. In some scenarios, DKIM will pass when SPF fails.

Therefore, when everything is configured properly, SPF adds no value
beyond what DKIM does, and DKIM does add value beyond what SPF does.
That's why I am (and others are) arguing that we should remove SPF
*from DMARC evaluation*.  There's no argument that for now, or some,
SPF outside of DMARC still has value.

What others are arguing is that in the real world, things do get
mis-configured, and if DKIM is misconfigured and fails when it
shouldn't, SPF adds value by providing a working authentication.
(And, of course, similarly the other way around, plus DKIM covers some
cases when messages are relayed or forwarded.)  That speaks for "SPF
*or* DKIM".

But "SPF *and* DKIM" -- requiring *both* to pass -- is technically
unnecessary at best, because of (1) above: DKIM should always pass
when SPF passes.  But where the harm comes is in cases of
mis-configuration, because now if *either* of them is misconfigured,
the whole thing fails -- neither of them serves as a backup for the
other; instead, the misconfiguration of either one causes
deliverability problems.  DMARC is damaged by requiring an
authentication situation that is unnecessary when things are properly
configured, and that is more fragile than what we've been using, more
susceptible to configuration errors than we've seen before.

And I'm afraid that people will use it preferentially, *thinking* that
it provides better "security" -- surely, double authentication is
better than single, no?

No.

Barry

On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely  wrote:
>
> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> > I'm saying I don't want "and" to be an option, because I think it's
> > damaging to DMARC.  There is no reason anyone should ever want to say
> > that, and providing the option asks for misconfigurations because
> > people think it's somehow "more secure".  It's not more secure.  It
> > would be very bad for deliverability of legitimate mail and would
> > provide no additional security.  It would be a terrible mistake.
>
>
> I've been sporting spf-all for years, and seldom experienced bounces, mostly
> due to misconfigured secondary MXes.  Out of 39 domains whose posts to this
> list in the past year are still in my inbox, 14 have spf-all.  So, while I'm
> not the only one, not many published -all even though it may seem to be 
> somehow
> more secure.
>
> I think it can be worth to compare SPF and DMARC.  Another sender policy a
> decade and an authentication method after.  What adoption, what hype.
>
> Both policies ask receivers to reject a domain identifier in some cases.  RFC
> 7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC 
> provides
> for overrides but is less clear about how to handle exceptions.  After SPF
> broke forwarding, the reaction was split between some changing identifier and
> turning to ~all; after DMARC broke mailing lists, between changing identifier
> and not altering messages.  In my limited experience, the ratio seems to be
> higher for DMARC than SPF, but I may be wrong.
>
> In theory, domains that currently have a strict DMARC policy and spf-all, 6 of
> the above, should have their messages blocked when either method fails, up to
> changing identifiers.  Why would it be so bad for deliverability to
> additionally require DMARC alignment, which is the difference between that and
> the "and"?
>
> And, it seems to me that an ESP not having a bloated SPF record could stop a
> good deal of DKIM replay by resorting to auth=dkim+spf.  Besides collateral
> deliverability problems, why wouldn't that work?
>
> Wht would "and" damage DMARC more than -all damaged SPF?
>
> I hope we can discuss detailed criticism rather than vague ostracism.
>
>
> Best
> Ale
> --
>
>
>
>
>

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

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

[Douglas Foster]

Ale, here is an attempt at a formal model.   Application to the current
question is at the very end.

Any test (DKIM, SPF, ARC) has these result possibilities:

   - Pass
   - No data or uncertain result
   - Fail


The test results are imperfect, so we have to consider these probabilities

Probability that PASS is a correct result
   Probability that a false PASS will be whitelisted or not blocked in
content filtering
 Net result that a false PASS is delivered to the user

Probability that a NoData / Uncertain result is correct (presumed 100%).
  Probability that an Uncertain message is wanted or unwanted.
  Probability that an unwanted message is or is not blocked by
content filtering
   Net probability that an unauthenticated and unwanted message
is delivered to the user

Probability that FAIL is a correct result
  Probability that a FAIL result is blocked by local policy (presumed
100%)
   Probability that a false FAIL is actually wanted
  Net probability that false FAIL blocks a wanted message

My strategy is documented in my "Best Practices" draft submission.   To
summarize my experience:
- The frequency of a true PASS is high, so the probability of a false PASS
is low
- The probability of a false PASS being detected by content filtering is
pretty good.
- The frequency of a true FAIL is low, so the probability of a false FAIL
is high.
- Uncertain messages have a high percentage of unwanted messages, but also
a non-trivial volume of wanted messages.

My conclusions:

   - FAIL messages should be submitted to content filtering to collect more
   data
   - Blocking on FAIL alone, despite content filtering PASS, has always
   caused me more harm than good.
   - Treating UNCERTAIN as equivalent to PASS is harmful.  Uncertain
   messages can be as unwanted as FAIL.
   - FAIL and UNCERTAIN messages need to be reviewed and confirmed.   When
   confirmed, the message is allowed or blocked based on local policies which
   are informed but not controlled by the sender's published policies.
   - Quarantine on FAIL or UNCERTAIN is superior to Block, because it
   allows for ambiguity to be removed and policy rules to be updated
   - When FAIL and UNCERTAIN volumes are too high, an arbitrary disposition
   can be applied immediately, but statistical sampling should be used to
   review the disposition decision after the fact, so that local policies can
   be updated.

Application to the current AUTH proposal:

   - I expect SPF AND DKIM will cause sender policies to be less
   believable, because a high rate of FAIL will occur on wanted messages, so I
   expect to treat SPF AND DKIM as SPF OR DKIM by local policy.
   - I trust DKIM more than SPF so I see no reason to honor SPF ONLY. I
   will continue to apply SPF OR DKIM .
   - I see the advantages of DKIM ONLY and will honor that policy when it
   is detected.

Doug Foster



On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely  wrote:

> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> > I'm saying I don't want "and" to be an option, because I think it's
> > damaging to DMARC.  There is no reason anyone should ever want to say
> > that, and providing the option asks for misconfigurations because
> > people think it's somehow "more secure".  It's not more secure.  It
> > would be very bad for deliverability of legitimate mail and would
> > provide no additional security.  It would be a terrible mistake.
>
>
> I've been sporting spf-all for years, and seldom experienced bounces,
> mostly
> due to misconfigured secondary MXes.  Out of 39 domains whose posts to
> this
> list in the past year are still in my inbox, 14 have spf-all.  So, while
> I'm
> not the only one, not many published -all even though it may seem to be
> somehow
> more secure.
>
> I think it can be worth to compare SPF and DMARC.  Another sender policy a
> decade and an authentication method after.  What adoption, what hype.
>
> Both policies ask receivers to reject a domain identifier in some cases.
> RFC
> 7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC
> provides
> for overrides but is less clear about how to handle exceptions.  After SPF
> broke forwarding, the reaction was split between some changing identifier
> and
> turning to ~all; after DMARC broke mailing lists, between changing
> identifier
> and not altering messages.  In my limited experience, the ratio seems to
> be
> higher for DMARC than SPF, but I may be wrong.
>
> In theory, domains that currently have a strict DMARC policy and spf-all,
> 6 of
> the above, should have their messages blocked when either method fails, up
> to
> changing identifiers.  Why would it be so bad for deliverability to
> additionally require DMARC alignment, which is the difference between that
> and
> the "and"?
>
> And, it seems to me that an ESP not having a bloated SPF record could stop
> a
> good deal of DKIM replay by resorting to auth=dkim+spf.  Besides
> 

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

[Alessandro Vesely]

On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:

I'm saying I don't want "and" to be an option, because I think it's
damaging to DMARC.  There is no reason anyone should ever want to say
that, and providing the option asks for misconfigurations because
people think it's somehow "more secure".  It's not more secure.  It
would be very bad for deliverability of legitimate mail and would
provide no additional security.  It would be a terrible mistake.



I've been sporting spf-all for years, and seldom experienced bounces, mostly 
due to misconfigured secondary MXes.  Out of 39 domains whose posts to this 
list in the past year are still in my inbox, 14 have spf-all.  So, while I'm 
not the only one, not many published -all even though it may seem to be somehow 
more secure.


I think it can be worth to compare SPF and DMARC.  Another sender policy a 
decade and an authentication method after.  What adoption, what hype.


Both policies ask receivers to reject a domain identifier in some cases.  RFC 
7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC provides 
for overrides but is less clear about how to handle exceptions.  After SPF 
broke forwarding, the reaction was split between some changing identifier and 
turning to ~all; after DMARC broke mailing lists, between changing identifier 
and not altering messages.  In my limited experience, the ratio seems to be 
higher for DMARC than SPF, but I may be wrong.


In theory, domains that currently have a strict DMARC policy and spf-all, 6 of 
the above, should have their messages blocked when either method fails, up to 
changing identifiers.  Why would it be so bad for deliverability to 
additionally require DMARC alignment, which is the difference between that and 
the "and"?


And, it seems to me that an ESP not having a bloated SPF record could stop a 
good deal of DKIM replay by resorting to auth=dkim+spf.  Besides collateral 
deliverability problems, why wouldn't that work?


Wht would "and" damage DMARC more than -all damaged SPF?

I hope we can discuss detailed criticism rather than vague ostracism.


Best
Ale
--





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

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

[Alessandro Vesely]

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)



ESPs can provide include files for those who wish otherwise.


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 Levine]

It appears that Barry Leiba   said:
>I'm saying I don't want "and" to be an option, because I think it's
>damaging to DMARC.  There is no reason anyone should ever want to say
>that, and providing the option asks for misconfigurations because
>people think it's somehow "more secure".  It's not more secure.  It
>would be very bad for deliverability of legitimate mail and would
>provide no additional security.  It would be a terrible mistake.

What he said.  The group that invented DMARC thought about using
both and specifically rejected it.  I see no reason to believe
they were wrong.  (If someone's going to say that using both fixes
DKIM replay, it really doesn't and it still has all the other problems.)

It's still not clear how we would know whether anyone was paying
attention to the "SPF only" flag, but since I don't think it's useful,
I'm not worrying about it.

R's,
John

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

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

[Barry Leiba]

I'm saying I don't want "and" to be an option, because I think it's
damaging to DMARC.  There is no reason anyone should ever want to say
that, and providing the option asks for misconfigurations because
people think it's somehow "more secure".  It's not more secure.  It
would be very bad for deliverability of legitimate mail and would
provide no additional security.  It would be a terrible mistake.

Barry

On Mon, Jun 26, 2023 at 11:55 AM Murray S. Kucherawy
 wrote:
>
> Just to clarify something:
>
> On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba  wrote:
>>
>> I can accept some mechanism for the sender to say "SPF only", "DKIM
>> only", or "either SPF or DKIM".  I cannot except a version of DMARC
>> where *both* must pass.
>
>
> I think the proposal before us is to allow the domain owner to indicate it 
> wants specific combination(s) of SPF and DKIM to pass in order for DMARC to 
> pass.  I imagine the default would be "or" which is backward compatible with 
> what we have today, as the charter demands.
>
> Are you saying you don't even want "and" to be an option if it is made 
> configurable?  Or do you just not want the "or" to change to "and" without 
> the proposed new tag?
>
> -MSK, participating

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

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

[Douglas Foster]

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)

This seems unlikely to be a reliable assertion, so the effect on
disposition is likely to be strongly negative, even without the effect on
forwarders.  I oppose.

Similarly, SPF only seems unlikely to provide improved dispositions.
Evaluators are unlikely to find it worth honoring.

All I think we need is a tag that says,nl "ignore SPF if you understand
DMARC" .   Since only DMARC-aware evaluators will be looking for the policy
which contains the tag, I see no obstacles.



On Mon, Jun 26, 2023, 12:14 PM Alessandro Vesely  wrote:

> On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote:
> > If we consider this sort of thing, I want to push to keep one thing
> > off the table:
> >
> > Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
> > Let's please just remove that from consideration.  It has not been in
> > DMARC up to this point, and it would be really bad to add it.
> > Deliverability would be worse than ever because we would get the worst
> > of both: fragility of SPF when messages are relayed/forwarded, *and*
> > problems caused by misconfigurations in *either* SPF *or* DKIM.
>
>
> I agree it'd be an extreme setting.  It could only make sense in very
> extreme
> cases.  However, in those cases it might make sense.
>
> In addition, if ARC-driven forwarding setups will gain the ability to
> override
> DMARC, at least for established forwarding paths, the forwarding
> prohibition
> would then be softened.  After all, spf-all requires a comparable behavior
> (except that SPF allows intermediate results) and many domains use it
> satisfactorily.
>
> The conundrum is protecting users from self-injury versus unleashing the
> full
> power of the combined mechanisms.
>
>
> > I can accept some mechanism for the sender to say "SPF only", "DKIM
> > only", or "either SPF or DKIM".  I cannot except a version of DMARC
> > where *both* must pass.
>
>
> Frankly, I cannot imagine the usefulness of auth=spf only.  People who
> don't
> implement DKIM or don't like it don't bother publishing a policy to
> explicitly
> excluding it.  It's enough not to sign.  Excluding DKIM would be useful if
> keys
> have been compromised, an they have a long lifetime while, by chance,
> DMARC
> policy is given with TTL 3600.  It doesn't seem to be realistic.
>
> Still, I'd allow that possibility for symmetry reasons.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
> ___
> 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

[Alessandro Vesely]

On Mon 26/Jun/2023 14:51:34 +0200 Barry Leiba wrote:

If we consider this sort of thing, I want to push to keep one thing
off the table:

Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
Let's please just remove that from consideration.  It has not been in
DMARC up to this point, and it would be really bad to add it.
Deliverability would be worse than ever because we would get the worst
of both: fragility of SPF when messages are relayed/forwarded, *and*
problems caused by misconfigurations in *either* SPF *or* DKIM.



I agree it'd be an extreme setting.  It could only make sense in very extreme 
cases.  However, in those cases it might make sense.


In addition, if ARC-driven forwarding setups will gain the ability to override 
DMARC, at least for established forwarding paths, the forwarding prohibition 
would then be softened.  After all, spf-all requires a comparable behavior 
(except that SPF allows intermediate results) and many domains use it 
satisfactorily.


The conundrum is protecting users from self-injury versus unleashing the full 
power of the combined mechanisms.




I can accept some mechanism for the sender to say "SPF only", "DKIM
only", or "either SPF or DKIM".  I cannot except a version of DMARC
where *both* must pass.



Frankly, I cannot imagine the usefulness of auth=spf only.  People who don't 
implement DKIM or don't like it don't bother publishing a policy to explicitly 
excluding it.  It's enough not to sign.  Excluding DKIM would be useful if keys 
have been compromised, an they have a long lifetime while, by chance, DMARC 
policy is given with TTL 3600.  It doesn't seem to be realistic.


Still, I'd allow that possibility for symmetry reasons.


Best
Ale
--







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

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

[Murray S. Kucherawy]

Just to clarify something:

On Mon, Jun 26, 2023 at 5:52 AM Barry Leiba  wrote:

> I can accept some mechanism for the sender to say "SPF only", "DKIM
> only", or "either SPF or DKIM".  I cannot except a version of DMARC
> where *both* must pass.
>

I think the proposal before us is to allow the domain owner to indicate it
wants specific combination(s) of SPF and DKIM to pass in order for DMARC to
pass.  I imagine the default would be "or" which is backward compatible
with what we have today, as the charter demands.

Are you saying you don't even want "and" to be an option if it is made
configurable?  Or do you just not want the "or" to change to "and" without
the proposed new tag?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jan Dušátko]

Barry,
I understand your concerns. Use SPF *and* DKIM could cause issues for 
any kind of mail conferencing and forwarding. Situation are quite 
complicated right now. Use of these method, as well as combination of 
these methods, could lower deliverability due protection mechanism 
contrary of forwarding/conferencing principle. But the goal of 
protection methods is to ensure the authenticity of the e-mail source. 
This means that the sender is responsible for protecting the 
domain/brand. And this ultimately requires that the owner has methods 
that are able to provide enough data to ensure its full verifiability. 
Whether these methods are properly implemented is the responsibility of 
the sender's system administrator, whether they are checked upon receipt 
is the responsibility of the recipient's system administrator. Some of 
organization checks SPF only, some DKIM only, some SFP then DKIM, some 
SPF and DKIM (but logic of that use OR), in few tenth of precents also 
followed by DMARC. And some of organizations still does not check anything.
Please, can you consider the possibility that the owner of several 
hundred or even several thousand domains is trying to protect his 
business and does not have the possibility to provide verifiable 
authenticity? If he understands the situation with their impacts, the 
possibility of using SPF and DKIM is a method to ensure adequate 
protection. By this I mean protection from where the mail can be sent 
and at the same time whether it will be signed. Despite the problems 
with mail conferences and forwarding, this may be an acceptable way to 
solve specific problems. In other cases, how we can mitigate as much of 
situation mentioned above?
If the possibility of using only DKIM, I see the risk of how the DMARC 
policy will be evaluated. If the error state of the policy is ensured 
for specific cases (non-existent public key, non-existent subdomain, 
non-existing signature), I have no problem with the approach. All that 
is needed to ensure is a precise procedure, what conditions the 
implementation must meet. And we need method, how we can enforce use of 
DKIM, else we will be in situation without any protection. This is a 
reason, why I concern about protection.


Regards

Jan

Dne 26. 6. 2023 v 14:51 Barry Leiba napsal(a):

If we consider this sort of thing, I want to push to keep one thing
off the table:

Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
Let's please just remove that from consideration.  It has not been in
DMARC up to this point, and it would be really bad to add it.
Deliverability would be worse than ever because we would get the worst
of both: fragility of SPF when messages are relayed/forwarded, *and*
problems caused by misconfigurations in *either* SPF *or* DKIM.

I can accept some mechanism for the sender to say "SPF only", "DKIM
only", or "either SPF or DKIM".  I cannot except a version of DMARC
where *both* must pass.

Barry, as participant

On Sat, Jun 24, 2023 at 3:01 PM Jan Dušátko
 wrote:

Hector,
I think Levin's original suggestion to use the setting option like SPF
AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve
a lot of problems. System administrators know best how to set up their
system and for what purposes they need that setting. I can imagine a
great many reasons for and against those combinations. What seems to me
to be important here is that DMARC is able to use policies to solve not
only common but also error states. In that case, it is able to
successfully solve the problems caused by the attackers.

Jan

Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a):

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.

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

[Scott Kitterman]

On June 26, 2023 12:51:06 PM UTC, florian.kun...@telekom.de wrote:
>
>> In theory, DKIM is enough for DMARC (this was always true), but in practice 
>> it
>> is not.
>
>May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job,
>but people here expect to apply it to solve real problems with real email in 
>real life.
>*SCNR* ... do not take that personally.
>
>
>> I don't think there's evidence of a systemic weakness in the protocol.  We've
>> seen evidence of poor deployment of the protocol for SPF, but I think the
>> solution is to fix that (see the separate thread on data hygiene).
>
>
>The problem with DMARC is, there's no easy way to decide you can rely on SPF 
>as long as it references shared IP infrastructure (because you can't decide 
>whether an IP is shared or dedicated).
>In my view this is a tremendous weakness of the SPF protocol.
>(maybe only 'cause I do not trust shared infrastructure providers to get their 
>customers right all the time, 'cause I know how hard that is from being an ISP 
>mailer)
>
>So to remove or at least ignore SPF from DMARC is minimal requirement for 
>DMARC being worth mentioning supportive of sender authentication at all.
>Meanwhile it's a pretty viable attack vector against DMARC, foiling the idea 
>of sender authentication.

That's true if you change the semantics of what a DMARC pass means.  It means 
it came via an authorized source.  It does not mean anything about if the 
message is "good" or "bad".  It doesn't and can't solve the problem of 
inappropriately injected mail in the authorized stream.

When a domain publishes a public key in its DNS that's been given to it by a 
third party provider, DKIM is also exposed to third party provider data hygiene 
risks.

Even if DKIM were perfect and we ditch SPF, users get compromised and bad stuff 
still gets into the authenticated stream.

I think people are attributing a lot of badness to SPF when it's a more general 
problem.  It's just easier to identify with SPF.  Currently, bad ingress 
controls for third party providers mostly imposes external costs (from their 
point of view).  Until that changes, it will be a mess no matter what the 
underlying authentication technology is.

Scott K

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

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

[Florian.Kunkel]

> In theory, DKIM is enough for DMARC (this was always true), but in practice it
> is not.

May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job,
but people here expect to apply it to solve real problems with real email in 
real life.
*SCNR* ... do not take that personally.


> I don't think there's evidence of a systemic weakness in the protocol.  We've
> seen evidence of poor deployment of the protocol for SPF, but I think the
> solution is to fix that (see the separate thread on data hygiene).


The problem with DMARC is, there's no easy way to decide you can rely on SPF as 
long as it references shared IP infrastructure (because you can't decide 
whether an IP is shared or dedicated).
In my view this is a tremendous weakness of the SPF protocol.
(maybe only 'cause I do not trust shared infrastructure providers to get their 
customers right all the time, 'cause I know how hard that is from being an ISP 
mailer)

So to remove or at least ignore SPF from DMARC is minimal requirement for DMARC 
being worth mentioning supportive of sender authentication at all.
Meanwhile it's a pretty viable attack vector against DMARC, foiling the idea of 
sender authentication.


Florian

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

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

[Barry Leiba]

If we consider this sort of thing, I want to push to keep one thing
off the table:

Saying that SPF *and* DKIM *both* have to pass is a VERY BAD approach.
Let's please just remove that from consideration.  It has not been in
DMARC up to this point, and it would be really bad to add it.
Deliverability would be worse than ever because we would get the worst
of both: fragility of SPF when messages are relayed/forwarded, *and*
problems caused by misconfigurations in *either* SPF *or* DKIM.

I can accept some mechanism for the sender to say "SPF only", "DKIM
only", or "either SPF or DKIM".  I cannot except a version of DMARC
where *both* must pass.

Barry, as participant

On Sat, Jun 24, 2023 at 3:01 PM Jan Dušátko
 wrote:
>
> Hector,
> I think Levin's original suggestion to use the setting option like SPF
> AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve
> a lot of problems. System administrators know best how to set up their
> system and for what purposes they need that setting. I can imagine a
> great many reasons for and against those combinations. What seems to me
> to be important here is that DMARC is able to use policies to solve not
> only common but also error states. In that case, it is able to
> successfully solve the problems caused by the attackers.
>
> Jan
>
> Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a):
> > 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
> >>
> >>
> >
> >
>
> ___
> 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

[Jan Dušátko]

Hector,
I think Levin's original suggestion to use the setting option like SPF 
AND DKIM, SPF OR DKIM, SPF only, DKIM only is excellent. It could solve 
a lot of problems. System administrators know best how to set up their 
system and for what purposes they need that setting. I can imagine a 
great many reasons for and against those combinations. What seems to me 
to be important here is that DMARC is able to use policies to solve not 
only common but also error states. In that case, it is able to 
successfully solve the problems caused by the attackers.


Jan

Dne 23. 6. 2023 v 19:23 Hector Santos napsal(a):

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







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

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

[Hector Santos]

> 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.

When said that way, I believe that requires a version bump v2 which would 
inherently means “use DKIM only,"

So supporters all do a version check:


   bUseDKIMOnly =  (DMARC[“v=“] == “DMARC2”)?1:0


And the new supporter will use the flag bUseDKIMOnly throughout its current 
DMARC1 evaluation accordingly.  

Or via “Add-on” tag extension:

   bUseDKIMOnly =  (DMARC[“auth="] == “dkim”)?1:0

Six in one, Half Dozen of the other?

The problem is that there are implementations that do check for v=DMARC1 and 
will not required DMARC2 as a valid record when in fact a DMARC2 record exist 
whose only purpose in life was to signify a relaxed DMARC1 evaluation regarding 
SPF.

I like the tag extension instead.  Make coding life easier, I think.   But if  
v=DMARC2 is the way Levine wishes to go, I’m ok.  I see issues with just 
changing the inherent behavior without any protocol negotiating signals.

—
HLS


 



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

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

[Hector Santos]

Alessandro,  I believe we are on the same wave.  I support the DMARC1 tag 
extension `auth=‘ idea.   Do you have any suggestions for the text?  

Technically we don’t need DMARC1-Bis.   That document can move forward as is 
and a new draft proposal I-D called “DMARC1-EXTENSION-AUTH” can be written for 
relaxing the original DMARC1 (RFC 7489) and also the current DMARC1-bis.

—
HLS

> On Jun 24, 2023, at 12:17 PM, Alessandro Vesely  wrote:
> 
> On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote:
>>> 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:
>> 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.
> 
> 
> Eh?  Dkim+spf wouldn't be a new mechanism, as the domain identifier would 
> have to be the same.  I'd have cited 6.3:
> 
> 6.3.  General Record Format
> https://datatracker.ietf.org/doc/html/rfc7489#section-6.3
> 
>   Section 11 creates a registry for known DMARC tags and registers the
>   initial set defined in this document.  Only tags defined in this
>   document or in later extensions, and thus added to that registry, are
>   to be processed; unknown tags MUST be ignored.
> 
> Of course, there will be lots of verifiers who ignore auth=, t=, and ed25519. 
> Unfortunately, while we have so many blog posts, we're still missing DMARC 
> verifier checks.
> 
> 
>>> 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.
> 
> 
> SPF hard fail is acceptable even with the default auth=.  (SPF hard fail is a 
> problem for those who reject before DATA.  Receiving MXes have no DKIM clue 
> at that stage.  The only way forwarding might work without replacing the 
> bounce address is if either the receiver or the SPF record provide for 
> whitelisting. As a side note, let me add that I'm rejecting way more spam 
> thanks to spf-all than DMARC and DNSBL together.)
> 
> The auth=dkim (excluding SPF) setting is needed by domains who /have/ to 
> include a bloated SPF record in order to deliver at sites which only verify 
> that.  However, since the bloated record allows impersonation, they don't 
> want that DMARC verifiers consider it.  They probably wish that everybody 
> used DMARC so that they could avoid publishing an SPF record, but there's not 
> much they can do about it.
> 
> 
> Best
> Ale
> -- 


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

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

[Alessandro Vesely]

On Fri 23/Jun/2023 20:13:27 +0200 Hector Santos wrote:

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:

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.



Eh?  Dkim+spf wouldn't be a new mechanism, as the domain identifier would have 
to be the same.  I'd have cited 6.3:


6.3.  General Record Format
https://datatracker.ietf.org/doc/html/rfc7489#section-6.3

   Section 11 creates a registry for known DMARC tags and registers the
   initial set defined in this document.  Only tags defined in this
   document or in later extensions, and thus added to that registry, are
   to be processed; unknown tags MUST be ignored.

Of course, there will be lots of verifiers who ignore auth=, t=, and ed25519. 
Unfortunately, while we have so many blog posts, we're still missing DMARC 
verifier checks.




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.



SPF hard fail is acceptable even with the default auth=.  (SPF hard fail is a 
problem for those who reject before DATA.  Receiving MXes have no DKIM clue at 
that stage.  The only way forwarding might work without replacing the bounce 
address is if either the receiver or the SPF record provide for whitelisting. 
As a side note, let me add that I'm rejecting way more spam thanks to spf-all 
than DMARC and DNSBL together.)


The auth=dkim (excluding SPF) setting is needed by domains who /have/ to 
include a bloated SPF record in order to deliver at sites which only verify 
that.  However, since the bloated record allows impersonation, they don't want 
that DMARC verifiers consider it.  They probably wish that everybody used DMARC 
so that they could avoid publishing an SPF record, but there's not much they 
can do about it.



Best
Ale
--




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

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

[Alessandro Vesely]

On Fri 23/Jun/2023 22:56:59 +0200 Barry Leiba wrote:

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.



As old as DKIM is, it's still too young to be provided for in MTA design.  The 
software I use, for example, allows filters on incoming mail.  Messages are 
signed before going in the queue.  That means that signatures are broken in the 
(rare) event of 7-bit conversion, and DSNs generated on the fly are not signed 
at all.


If we want DMARC to brand authentication, we'd better add than remove 
mechanisms.


Best
Ale
--





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

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] 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

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

[Emanuel Schorsch]

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

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

[John Levine]

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

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

[Emil Gustafsson]

The #2 option (backward compatible with new auth tag) is a good
clarification what we were thinking and that Wei mentioned here:
https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/

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).

/E

On Thu, Jun 22, 2023 at 3:38 PM Ken Simpson 
wrote:

>
>> Barry, this is obviously a new relaxation option.  From a mail system
>> integration standpoint, the options are:
>>
>> 1) A version bump to DMARC2 with new semantics with backward DMARC1
>> compatibility, or
>>
>> 2) Use a DMARC1 Extended tag option allowed by DMARC1.   Alessandro cited
>> an excellent backward compatible extended tag option:
>>
>> auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf
>>
>>
>>
>
> FWIW, I support the concept above, which would be compatible with DMARC
> today. Would anyone from a large receiver like to comment?
>
> Regards,
> Ken
> ___
> 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

[Ken Simpson]

>
>
> Barry, this is obviously a new relaxation option.  From a mail system
> integration standpoint, the options are:
>
> 1) A version bump to DMARC2 with new semantics with backward DMARC1
> compatibility, or
>
> 2) Use a DMARC1 Extended tag option allowed by DMARC1.   Alessandro cited
> an excellent backward compatible extended tag option:
>
> auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf
>
>
>

FWIW, I support the concept above, which would be compatible with DMARC
today. Would anyone from a large receiver like to comment?

Regards,
Ken
___
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 22, 2023, at 9:54 AM, Scott Kitterman  wrote:
> 
> My conclusion (it won't surprise you to learn) from this thread is precisely 
> the opposite.  
> 
> In theory, DKIM is enough for DMARC (this was always true), but in practice 
> it 
> is not.
> 
> I don't think there's evidence of a systemic weakness in the protocol.  We've 
> seen evidence of poor deployment of the protocol for SPF, but I think the 
> solution is to fix that (see the separate thread on data hygiene).
> 
> Scott K
> 

Scott, this all started as a way to add weight to a SPF=SOFTFAIL using ADSP.  
Microsoft started it and DMARC came out with a surprising even tighter rule for 
DKIM+SPF alignment.

SPF rejects immediately issued an 55z the transaction, confused DMARCers.  
Let’s keep in mind SPF pre-dated DMARC.

SPF softfail results were interesting to see how a DKIM signature may help.  
Microsoft’s idea before DMARC.

Overall, DMARC created a Link with SPF that wasn’t thoroughly reviewed with the 
IETF.  It skipped the process as an Informational proposal.  Now as a standard 
track DMARCbis, we see all the problems. 

How is this problem fixed with client/server protocol negotiating software?

—
HLS___
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 22, 2023, at 1:08 PM, Barry Leiba  wrote:
> 
>> I concur that this isn't really a problem for either working group to solve 
>> as part of a standard,
> 
> Well, the part that the working group needs to solve is whether the
> challenges of getting DKIM right are such that we need to retain SPF
> to fill that gap, or whether the issues with relying on SPF are more
> significant.  I think that's an important part of the decision we're
> discussing, and will be a significant part of judging consensus on
> that discussion.
> 
> Barry, as chair
> 

Barry, this is obviously a new relaxation option.  From a mail system 
integration standpoint, the options are:

1) A version bump to DMARC2 with new semantics with backward DMARC1 
compatibility, or

2) Use a DMARC1 Extended tag option allowed by DMARC1.   Alessandro cited an 
excellent backward compatible extended tag option:

auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf

Of course, this would need to be discussed and I know Levine see this is too 
late for DMARCbis, but in my opinion,  Why the rush?  IETF San Fran next month?

DMARCBis is highly contentious and remains problematic. You know whats 
happening. I put my IETF faith in you.

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

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

[Dotzero]

On Thu, Jun 22, 2023 at 8:59 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Right, but the messages often get sent anyway.   So the evaluator who
> blocks the message as malicious impersonation is blocking incorrectly
> because the fail result is unreliable.   If it only affects nuisance
> advertising, the error may not matter to the evaluator.  But I think the
> problem affects some messages that matter to the recipient.
>
> Doug
>

Blocking a message that fails authentication does not mean that the
evaluator assumes "malicious impersonation". It simply means the sending
domain in the From address has published a p=reject policy and has
requested that messages which fail to authenticate aren't authorized by the
domain, nothing more and nothing less.

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

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

[Barry Leiba]

> I concur that this isn't really a problem for either working group to solve 
> as part of a standard,

Well, the part that the working group needs to solve is whether the
challenges of getting DKIM right are such that we need to retain SPF
to fill that gap, or whether the issues with relying on SPF are more
significant.  I think that's an important part of the decision we're
discussing, and will be a significant part of judging consensus on
that discussion.

Barry, as chair

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

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

[Murray S. Kucherawy]

On Thu, Jun 22, 2023 at 6:32 AM Todd Herr  wrote:

> Marty also has the right to engage a third party to send the mail (again,
> as conveyed by their employer), mail that Marty and others at Marty's
> company will create. The third party here is most commonly referred to, in
> my experience, as an Email Service Provider (ESP), but this is just one use
> case. The ESP knows how to DKIM sign messages, and can even do so using the
> domain of Marty's employer, so long as Marty is able to get the public key
> published in DNS.
>

We thought about this during the early DKIM days.  It was called out more
than once that at sufficiently large organizations, the email people and
the DNS people are not certain to be part of the same organization.  That's
certainly true where I work.  And at a subset of the largest of those
organizations, the email people and the DNS people don't trust each other
either, so they sometimes make it harder for one to tamper in the space of
the other.  We tried to keep this in mind while designing how DKIM could
function.

I concur that this isn't really a problem for either working group to solve
as part of a standard, but there might be room for some suggestions if
either one ends up producing a best practices document.

The open source DKIM package I developed included a simple tool that would
generate a properly formed TXT record and associated comments suitable for
inclusion into a zone file, but there was feedback that it was still error
prone.  It also included a script that, once you had published a DKIM
record, would confirm that your signing key and the public key now in the
DNS matched, so signatures should work.

I had two thoughts over the years about other things to try:

(1) Instead of generating a DNS TXT record for someone to cut and paste,
output a complete "_domainkey" zone file to simply move into position,
i.e., by copying files rather than strings.  This is less prone to
corruption because copy-paste isn't part of the process.

(2) Make use of protocols like DNS UPDATE (RFC2136) that could allow DKIM
key generation tools to insert new records directly into the primary
authoritative server.  This is even less prone to error or corruption
because the human is almost totally removed from the process.

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

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

[Douglas Foster]

How about this!

p=none or quarantine trusts SPF and DKIM, but p=reject trusts DKIM only.

This option addresses Google's desire for a strict rule to protect the most
aggressively attacked domains, while leaving flexibility for those who want
it.

DF

On Thu, Jun 22, 2023, 9:55 AM Scott Kitterman  wrote:

> My conclusion (it won't surprise you to learn) from this thread is
> precisely
> the opposite.
>
> In theory, DKIM is enough for DMARC (this was always true), but in
> practice it
> is not.
>
> I don't think there's evidence of a systemic weakness in the protocol.
> We've
> seen evidence of poor deployment of the protocol for SPF, but I think the
> solution is to fix that (see the separate thread on data hygiene).
>
> Scott K
>
> On Thursday, June 22, 2023 9:46:07 AM EDT Sebastiaan de Vos wrote:
> > It's not easy to set a DKIM key, I can agree with that. I do think,
> > Marty should have tested before sending, though.
> >
> > None of this, however, solves the issue of SPF weakening the DMARC
> > standard. The weakness in SPF is not incidental, but systematic. That is
> > - independent of the numbers - the reason why I vote to have SPF removed
> > from the DMARC standard.
> >
> > On 22.06.23 15:31, Todd Herr wrote:
> > > When we look at the numbers others have posted on the topic, and we
> > > see a perhaps higher than expected percentage of DMARC passes that
> > > relied on SPF only (or at least a higher than expected rate of DKIM
> > > failures) I'd posit that many of those DKIM failures are due to the
> > > challenges that Marty and people like them face with getting the key
> > > published.
>
>
>
>
> ___
> 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

[Scott Kitterman]

My conclusion (it won't surprise you to learn) from this thread is precisely 
the opposite.  

In theory, DKIM is enough for DMARC (this was always true), but in practice it 
is not.

I don't think there's evidence of a systemic weakness in the protocol.  We've 
seen evidence of poor deployment of the protocol for SPF, but I think the 
solution is to fix that (see the separate thread on data hygiene).

Scott K

On Thursday, June 22, 2023 9:46:07 AM EDT Sebastiaan de Vos wrote:
> It's not easy to set a DKIM key, I can agree with that. I do think,
> Marty should have tested before sending, though.
> 
> None of this, however, solves the issue of SPF weakening the DMARC
> standard. The weakness in SPF is not incidental, but systematic. That is
> - independent of the numbers - the reason why I vote to have SPF removed
> from the DMARC standard.
> 
> On 22.06.23 15:31, Todd Herr wrote:
> > When we look at the numbers others have posted on the topic, and we
> > see a perhaps higher than expected percentage of DMARC passes that
> > relied on SPF only (or at least a higher than expected rate of DKIM
> > failures) I'd posit that many of those DKIM failures are due to the
> > challenges that Marty and people like them face with getting the key
> > published.




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

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

[Sebastiaan de Vos]

It's not easy to set a DKIM key, I can agree with that. I do think, 
Marty should have tested before sending, though.


None of this, however, solves the issue of SPF weakening the DMARC 
standard. The weakness in SPF is not incidental, but systematic. That is 
- independent of the numbers - the reason why I vote to have SPF removed 
from the DMARC standard.


On 22.06.23 15:31, Todd Herr wrote:
When we look at the numbers others have posted on the topic, and we 
see a perhaps higher than expected percentage of DMARC passes that 
relied on SPF only (or at least a higher than expected rate of DKIM 
failures) I'd posit that many of those DKIM failures are due to the 
challenges that Marty and people like them face with getting the key 
published.

--

Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

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

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

[Todd Herr]

On Thu, Jun 22, 2023 at 9:18 AM Sebastiaan de Vos  wrote:

> In that case, if I understand correctly, Marty is sending his E-mail
> untested and unmonitored. Is that not Marty's problem, really? Where are we
> heading if we try to fix that problem?
>

You seem to be ascribing malice to Marty here where I intended no such
thing.

Marty has the right (as conveyed by their employer) to send mail using his
employer's domain, and Marty wants to do the right thing and have that
email sent with DKIM signatures that use the domain in the d= tag, thereby
allowing the domain to claim responsibility for the message.

Marty also has the right to engage a third party to send the mail (again,
as conveyed by their employer), mail that Marty and others at Marty's
company will create. The third party here is most commonly referred to, in
my experience, as an Email Service Provider (ESP), but this is just one use
case. The ESP knows how to DKIM sign messages, and can even do so using the
domain of Marty's employer, so long as Marty is able to get the public key
published in DNS.

It has been my experience that as the size of an organization grows, the
ability of Marty to get DNS records published and published correctly
becomes more challenging.

This is not a problem for the DMARC Working Group to solve, of course; I do
think it's a problem for the larger community to solve, and as I posted
up-thread, Domain Connect is one attempt to do just that. However, I do
think it's a problem that we must be aware of as we consider whether or not
to make a DKIM-aligned pass a requirement for a DMARC pass, as opposed to
its current state of optional, where it's needed only when an SPF-aligned
pass is not present.

When we look at the numbers others have posted on the topic, and we see a
perhaps higher than expected percentage of DMARC passes that relied on SPF
only (or at least a higher than expected rate of DKIM failures) I'd posit
that many of those DKIM failures are due to the challenges that Marty and
people like them face with getting the key published.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Sebastiaan de Vos]

In that case, if I understand correctly, Marty is sending his E-mail 
untested and unmonitored. Is that not Marty's problem, really? Where are 
we heading if we try to fix that problem?


On 22.06.23 14:59, Douglas Foster wrote:
Right, but the messages often get sent anyway.  So the evaluator who 
blocks the message as malicious impersonation is blocking incorrectly 
because the fail result is unreliable.   If it only affects nuisance 
advertising, the error may not matter to the evaluator.  But I think 
the problem affects some messages that matter to the recipient.


Doug



On Thu, Jun 22, 2023, 7:46 AM Sebastiaan de Vos 
 wrote:


If I don't know how to control the zone for the domain I want to
send from, I can't authenticate my mail from that domain. Isn't
that part of the purpose of DKIM in the first place?

On 21.06.23 15:36, Todd Herr wrote:

Maybe Marty knows who does control DNS, and Marty is good at
cutting and pasting, and Marty can successfully communicate the
request to the DNS people for wesellstuff.com

-- 


Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

InboxSys Brochure


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


--

Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

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

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

[Douglas Foster]

Right, but the messages often get sent anyway.   So the evaluator who
blocks the message as malicious impersonation is blocking incorrectly
because the fail result is unreliable.   If it only affects nuisance
advertising, the error may not matter to the evaluator.  But I think the
problem affects some messages that matter to the recipient.

Doug



On Thu, Jun 22, 2023, 7:46 AM Sebastiaan de Vos  wrote:

> If I don't know how to control the zone for the domain I want to send
> from, I can't authenticate my mail from that domain. Isn't that part of the
> purpose of DKIM in the first place?
> On 21.06.23 15:36, Todd Herr wrote:
>
> Maybe Marty knows who does control DNS, and Marty is good at cutting and
> pasting, and Marty can successfully communicate the request to the DNS
> people for wesellstuff.com
>
> --
>
> Sebastiaan de Vos
> Founder
>
> Tel: +43 680 200 22 95
> E-Mail: sebasti...@inboxsys.com
> Website: http://inboxsys.com
>
> InboxSys Brochure 
> ___
> 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

[Sebastiaan de Vos]

If I don't know how to control the zone for the domain I want to send 
from, I can't authenticate my mail from that domain. Isn't that part of 
the purpose of DKIM in the first place?


On 21.06.23 15:36, Todd Herr wrote:
Maybe Marty knows who does control DNS, and Marty is good at cutting 
and pasting, and Marty can successfully communicate the request to the 
DNS people for wesellstuff.com 

--

Sebastiaan de Vos
Founder

Tel: +43 680 200 22 95
E-Mail: sebasti...@inboxsys.com
Website: http://inboxsys.com

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

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

[Alessandro Vesely]

On Wed 21/Jun/2023 15:36:44 +0200 Todd Herr wrote:

On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely  wrote:

On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:


I can't speak for Patrick, but I don't think he's necessarily thinking of 
different encryption algorithms here.


Not all who wish to have their email DKIM signed have the luxury that you 
have John of full control of the DKIM signing process. I'm specifically 
thinking of the entity (call them Marty Marketer) who has the authority to 
employ a third party to send authenticated mail on behalf of a domain, mail 
that the third party can and will DKIM sign using the entity's domain. 
Sadly, Marty does not have the authority to update DNS for that domain in 
order to publish a DKIM public key. This leads to challenges as the third 
party presents to Marty a public key to publish, and Marty tries to figure 
out to whom to pass along this information and in what format. This leads 
to screen caps, or cutting and pasting errors, misdirected mail chains, 
etc., etc.


Is this the way it should be? Probably not, but it's a reality for many, 
and it's a problem we don't as an industry have an answer for yet. If we 
did, there wouldn't be people in the other thread reporting such a high 
percentage of DKIM failures due to malformed/missing keys.


Now, of course we could argue that Marty shouldn't be left to their own 
devices to engage third party senders, and that should solely be the 
province of the IT staff that manages DNS, but I fear that the energy 
required to type and distribute such words would be wasted.


Creating more and more publishing mechanisms could reproduce the situation of 
SPF, whereby customers of the same third party can easily impersonate one 
another.


DKIM signatures have to be created by MSAs upon user authentication.  MSAs 
which use smarthosts, IMHO, had better sign just the header fields they 
control rather than delegate signing.  Doesn't Marty have any option on that?


I'm afraid I've done a poor job of making my point, as it seems that you 
haven't understood what I was trying to say. Let me try again.


The scenario I'm describing here isn't referring to the actual DKIM signing 
of any given message. Rather, I'm talking about the publication of the DKIM 
public key in DNS to support the validation of signed mail.


In this scenario, Marty has hired a third party email service provider 
(e.g., WeSendMail) to handle a class of bulk sending on behalf of Marty's 
organization (e.g., WeSellStuff.com).


Marty wants WeSendMail to DKIM sign that mail using d=wesellstuff.com, and 
WeSendMail can do that, so Marty clicks a button or whatever in the 
WeSendMail UI to make that happen.


The UI pops up a screen that says "Please publish this TXT record in your 
DNS", where the name is WSMWSSSelector._domainkey.wesellstuff.com and the 
value is the DKIM public key. Marty doesn't control DNS for wesellstuff.com.


Maybe Marty knows who does control DNS, and Marty is good at cutting and 
pasting, and Marty can successfully communicate the request to the DNS 
people for wesellstuff.com.


Maybe Marty has no clue who to engage, or maybe Marty misses a character in 
the cutting and pasting, or maybe Marty just does a screen capture and the 
DNS folks mess up something when transcribing the contents of the picture, 
or...


Might something like Domain Connect (https://www.domainconnect.org/) solve 
this? Sure, it could, and its website even describes a scenario identical 
to what I'm trying to describe here. However, Domain Connect seems to be a 
bit hand-wavy on the concept of authorization when it comes to making 
changes to DNS zones, and in this scenario, Marty doesn't have those 
credentials.



Ah, yeah.  I had thought that the message content was written by people at 
wesellstuff.com and sent on their behalf.  If it's people at WeSendMail who 
actually creates the messages, then it is correct that they sign what they 
write.  I understand the key publishing problem, although in the realities I 
have experience of, that kind of agreement is handled at a high enough level 
that Marty wouldn't have problems to ask it to the it head directly.


From a recipient POV, I'd prefer From: to refer to the creatives and the 
subject to the advertised product...



Best
Ale
--













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

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

[Todd Herr]

On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely  wrote:

> On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:
> >
> > I can't speak for Patrick, but I don't think he's necessarily thinking
> of
> > different encryption algorithms here.
> >
> > Not all who wish to have their email DKIM signed have the luxury that
> you
> > have John of full control of the DKIM signing process. I'm specifically
> > thinking of the entity (call them Marty Marketer) who has the authority
> to
> > employ a third party to send authenticated mail on behalf of a domain,
> mail
> > that the third party can and will DKIM sign using the entity's domain.
> > Sadly, Marty does not have the authority to update DNS for that domain
> in
> > order to publish a DKIM public key. This leads to challenges as the
> third
> > party presents to Marty a public key to publish, and Marty tries to
> figure
> > out to whom to pass along this information and in what format. This
> leads
> > to screen caps, or cutting and pasting errors, misdirected mail chains,
> > etc., etc.
> >
> > Is this the way it should be? Probably not, but it's a reality for many,
> > and it's a problem we don't as an industry have an answer for yet. If we
> > did, there wouldn't be people in the other thread reporting such a high
> > percentage of DKIM failures due to malformed/missing keys.
> >
> > Now, of course we could argue that Marty shouldn't be left to their own
> > devices to engage third party senders, and that should solely be the
> > province of the IT staff that manages DNS, but I fear that the energy
> > required to type and distribute such words would be wasted.
>
>
> Creating more and more publishing mechanisms could reproduce the situation
> of
> SPF, whereby customers of the same third party can easily impersonate one
> another.
>
> DKIM signatures have to be created by MSAs upon user authentication.  MSAs
> which use smarthosts, IMHO, had better sign just the header fields they
> control
> rather than delegate signing.  Doesn't Marty have any option on that?
>
>
>
I'm afraid I've done a poor job of making my point, as it seems that you
haven't understood what I was trying to say. Let me try again.

The scenario I'm describing here isn't referring to the actual DKIM signing
of any given message. Rather, I'm talking about the publication of the DKIM
public key in DNS to support the validation of signed mail.

In this scenario, Marty has hired a third party email service provider
(e.g., WeSendMail) to handle a class of bulk sending on behalf of Marty's
organization (e.g., WeSellStuff.com).

Marty wants WeSendMail to DKIM sign that mail using d=wesellstuff.com, and
WeSendMail can do that, so Marty clicks a button or whatever in the
WeSendMail UI to make that happen.

The UI pops up a screen that says "Please publish this TXT record in your
DNS", where the name is WSMWSSSelector._domainkey.wesellstuff.com and the
value is the DKIM public key. Marty doesn't control DNS for wesellstuff.com
.

Maybe Marty knows who does control DNS, and Marty is good at cutting and
pasting, and Marty can successfully communicate the request to the DNS
people for wesellstuff.com.

Maybe Marty has no clue who to engage, or maybe Marty misses a character in
the cutting and pasting, or maybe Marty just does a screen capture and the
DNS folks mess up something when transcribing the contents of the picture,
or...

Might something like Domain Connect (https://www.domainconnect.org/) solve
this? Sure, it could, and its website even describes a scenario identical
to what I'm trying to describe here. However, Domain Connect seems to be a
bit hand-wavy on the concept of authorization when it comes to making
changes to DNS zones, and in this scenario, Marty doesn't have those
credentials.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:

On Mon, Jun 19, 2023 at 8:25 PM John R Levine  wrote:

On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
I suggest that we do not only drop SPF, but also come up with better ways 
(simplification, tools, exchange formats) to implement DKIM in order to allow 
for a smooth transition.


I'm scratching my head here.  On my system I publish and rotate DKIM keys 
completely automatically.  The only manual config is to edit the list of 
domains when I add or remove one from my mail server.  It's not totally 
trivial but it's not that hard.


I suppose we could encourage people to implement ed25519 signatures since 
the keys are small and more likely to fit in a single TXT record string 
for provisioning crudware that doesn't handle multiple strings, but beyond 
that, what do you have in mind?


I can't speak for Patrick, but I don't think he's necessarily thinking of 
different encryption algorithms here.


Not all who wish to have their email DKIM signed have the luxury that you 
have John of full control of the DKIM signing process. I'm specifically 
thinking of the entity (call them Marty Marketer) who has the authority to 
employ a third party to send authenticated mail on behalf of a domain, mail 
that the third party can and will DKIM sign using the entity's domain. 
Sadly, Marty does not have the authority to update DNS for that domain in 
order to publish a DKIM public key. This leads to challenges as the third 
party presents to Marty a public key to publish, and Marty tries to figure 
out to whom to pass along this information and in what format. This leads 
to screen caps, or cutting and pasting errors, misdirected mail chains, 
etc., etc.


Is this the way it should be? Probably not, but it's a reality for many, 
and it's a problem we don't as an industry have an answer for yet. If we 
did, there wouldn't be people in the other thread reporting such a high 
percentage of DKIM failures due to malformed/missing keys.


Now, of course we could argue that Marty shouldn't be left to their own 
devices to engage third party senders, and that should solely be the 
province of the IT staff that manages DNS, but I fear that the energy 
required to type and distribute such words would be wasted.



Creating more and more publishing mechanisms could reproduce the situation of 
SPF, whereby customers of the same third party can easily impersonate one another.


DKIM signatures have to be created by MSAs upon user authentication.  MSAs 
which use smarthosts, IMHO, had better sign just the header fields they control 
rather than delegate signing.  Doesn't Marty have any option on that?



Best
Ale
--





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

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

[Todd Herr]

On Mon, Jun 19, 2023 at 8:25 PM John R Levine  wrote:

> On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
> > I suggest that we do not only drop SPF, but also come up with better ways
> > (simplification, tools, exchange formats) to implement DKIM in order to
> allow
> > for a smooth transition.
>
> I'm scratching my head here.  On my system I publish and rotate DKIM keys
> completely automatically.  The only manual config is to edit the list of
> domains when I add or remove one from my mail server.  It's not totally
> trivial but it's not that hard.
>
> I suppose we could encourage people to implement ed25519 signatures since
> the keys are small and more likely to fit in a single TXT record string
> for provisioning crudware that doesn't handle multiple strings, but beyond
> that, what do you have in mind?
>
>
I can't speak for Patrick, but I don't think he's necessarily thinking of
different encryption algorithms here.

Not all who wish to have their email DKIM signed have the luxury that you
have John of full control of the DKIM signing process. I'm specifically
thinking of the entity (call them Marty Marketer) who has the authority to
employ a third party to send authenticated mail on behalf of a domain, mail
that the third party can and will DKIM sign using the entity's domain.
Sadly, Marty does not have the authority to update DNS for that domain in
order to publish a DKIM public key. This leads to challenges as the third
party presents to Marty a public key to publish, and Marty tries to figure
out to whom to pass along this information and in what format. This leads
to screen caps, or cutting and pasting errors, misdirected mail chains,
etc., etc.

Is this the way it should be? Probably not, but it's a reality for many,
and it's a problem we don't as an industry have an answer for yet. If we
did, there wouldn't be people in the other thread reporting such a high
percentage of DKIM failures due to malformed/missing keys.

Now, of course we could argue that Marty shouldn't be left to their own
devices to engage third party senders, and that should solely be the
province of the IT staff that manages DNS, but I fear that the energy
required to type and distribute such words would be wasted.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Benny Pedersen]

John R Levine skrev den 2023-06-20 02:25:

On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
I suggest that we do not only drop SPF, but also come up with better 
ways
(simplification, tools, exchange formats) to implement DKIM in order 
to allow

for a smooth transition.


I'm scratching my head here.  On my system I publish and rotate DKIM
keys completely automatically.  The only manual config is to edit the
list of domains when I add or remove one from my mail server.  It's
not totally trivial but it's not that hard.

I suppose we could encourage people to implement ed25519 signatures
since the keys are small and more likely to fit in a single TXT record
string for provisioning crudware that doesn't handle multiple strings,
but beyond that, what do you have in mind?


i see it as a problem, not as a solution, would we want all to be forced 
to accept new algo ?, will old be depricated ?, yes retorisk question i 
know, but be carefull, metacpan Mail::DKIM does not yet have it, but 
there is patches waiting so maybe it comes ?


imho there would be more forward to see amavisd-new do ARC-Seal/ARC-Sign 
then to see it support one more algo in dkim, i know this is maybe just 
me ?


___
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 Mon, 19 Jun 2023, Patrick Ben Koetter wrote:

I suggest that we do not only drop SPF, but also come up with better ways
(simplification, tools, exchange formats) to implement DKIM in order to allow
for a smooth transition.


I'm scratching my head here.  On my system I publish and rotate DKIM keys 
completely automatically.  The only manual config is to edit the list of 
domains when I add or remove one from my mail server.  It's not totally 
trivial but it's not that hard.


I suppose we could encourage people to implement ed25519 signatures since 
the keys are small and more likely to fit in a single TXT record string 
for provisioning crudware that doesn't handle multiple strings, but beyond 
that, what do you have in mind?


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