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] The auth= tag, was DMARC2 & SPF Dependency Removal

[Jan Dušátko]

Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a):

On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF 
and DKIM support, and to support senders that want to drop SPF as one 
of their DMARC authentication methods to avoid the SPF upgrade 
vulnerability. We could have a DMARC policy tag for authentication 
e.g. "auth=" that describes the permitted authentication methods the 
sender supports and receiver MUST use for validation.   DKIM or SPF 
are represented as tags "dkim" and "spf", and if multiple tags are 
present then they are comma separated and any one passing is 
considered passing authentication.  Also at least one authentication 
method MUST be present.  Other authentication methods could be added 
in the future as it is our hope that there will be some other 
authentication method to improve upon and someday replace SPF.  
overall.  If "auth=" is missing, then DMARC falls back to supporting 
SPF and DKIM.


+1, clarifying underlying mechanisms improves DMARC usability.

Version bump only forces domains that wish to use the new tag to 
create a new v=DMARC2 record.  Old evaluators will read the v=DMARC1 
record, whereas they can just ignore the new tag if we stick to the 
same version.


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



Best
Ale


Ale,
If I understand DMARC well, right now works in mentioned way. The fo= 
are for reporting only and I have seen many implementation, which simply 
ignore it, they used the same condition as DMARC have. To be honest, I 
does not sure if my understanding are correct, please do not hesitate 
and correct me if I'm wrong.


if ((SPF=pass) and (SPF aligned with "From" domain)) or ((DKIM=pass) and 
(DKIM aligned with "From" domain)) then DMARC=pass


+---++---+-+--+
| Alignment | Result | Alignment | Result  |  Result  |
|   of SPF  | of SPF |  of DKIM  | of DKIM | of DMARC |
+---++---+-+--+
|   Failed  | Failed |  Failed   | Failed  | Failed   |
|   Failed  | Failed |  Failed   |  Pass   | Failed   |
|   Failed  | Failed |   Pass    | Failed  | Failed   |
|   Failed  | Failed |   Pass    |  Pass   |  Pass    |
|   Failed  |  Pass  |  Failed   | Failed  | Failed   |
|   Failed  |  Pass  |  Failed   |  Pass   | Failed   |
|   Failed  |  Pass  |   Pass    | Failed  | Failed   |
|   Failed  |  Pass  |   Pass    |  Pass   |  Pass    |
|   Pass    | Failed |  Failed   | Failed  | Failed   |
|   Pass    | Failed |  Failed   |  Pass   | Failed   |
|   Pass    | Failed |   Pass    | Failed  | Failed   |
|   Pass    | Failed |   Pass    |  Pass   |  Pass    |
|   Pass    |  Pass  |  Failed   | Failed  |  Pass    |
|   Pass    |  Pass  |  Failed   |  Pass   |  Pass    |
|   Pass    |  Pass  |   Pass    | Failed  |  Pass    |
|   Pass    |  Pass  |   Pass    |  Pass   |  Pass    |
+---++---+-+--+

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


if ((SPF=pass) and (SPF aligned with "From" domain)) and ((DKIM=pass) 
and (DKIM aligned with "From" domain)) then DMARC=pass


+---++---+-+--+
| Alignment | Result | Alignment | Result  |  Result  |
|   of SPF  | of SPF |  of DKIM  | of DKIM | of DMARC |
+---++---+-+--+
|   Failed  | Failed |  Failed   | Failed  | Failed   |
|   Failed  | Failed |  Failed   |  Pass   | Failed   |
|   Failed  | Failed |   Pass    | Failed  | Failed   |
|   Failed  | Failed |   Pass    |  Pass   | Failed   |
|   Failed  |  Pass  |  Failed   | Failed  | Failed   |
|   Failed  |  Pass  |  Failed   |  Pass   | Failed   |
|   Failed  |  Pass  |   Pass    | Failed  | Failed   |
|   Failed  |  Pass  |   Pass    |  Pass   | Failed   |
|   Pass    | Failed |  Failed   | Failed  | Failed   |
|   Pass    | Failed |  Failed   |  Pass   | Failed   |
|   Pass    | Failed |   Pass    | Failed  | Failed   |
|   Pass    | Failed |   Pass    |  Pass   | Failed   |
|   Pass    |  Pass  |  Failed   | Failed  | Failed   |
|   Pass    |  Pass  |  Failed   |  Pass   | Failed   |
|   Pass    |  Pass  |   Pass    | Failed  | Failed   |
|   Pass    |  Pass  |   Pass    |  Pass   |  Pass    |
+---++---+-+--+

Regards

Jan

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

[dmarc-ietf] SPF/DKIM/DMARC statistics from Valimail

[Todd Herr]

Colleagues,

We looked at data covering a time period of several months and more than a
quarter of a trillion DMARC pass results to get a sense for the impact of
what a change to DKIM-only might mean for DMARC. Here's what we found.

   - 3.65% of all DMARC passes recorded had only an aligned SPF pass
   - 1.35% of all DMARC passes recorded had only an aligned SPF pass and no
   DKIM signature
   - 2.28% of all DMARC passes recorded with p=quarantine or p=reject had
   only an aligned SPF pass
   - 0.89% of all DMARC passes recorded with p=quarantine or p=reject had
   only an aligned SPF pass and no DKIM signature

Relatively small percentages, I'll grant you, but rather a large sample
size.

As for domains, looking across many tens of thousands of domains...

   - For 60% of all domains with DMARC pass verdicts, at least some of
   those passes had only an aligned SPF pass
   - For 32.7% of all domains with DMARC pass verdicts, at least some of
   those passes had only an aligned SPF pass and the prevailing DMARC policy
   was either quarantine or reject

We also found that of the mailing services used by our customers that we
refer to as "configurable" (meaning that they support one or both of an
aligned SPF and aligned DKIM configuration), 44.2% of those configurable
services currently only support aligned SPF.

We also found that among our customers who use these services that only
support aligned SPF, the average number of such services used is three.

When I look at these numbers (and others that have been presented on this
list) I see more evidence of what Mr. Kitterman termed "poor deployments of
the protocol(s)", and I believe those problems should be fixed. I just
don't think that changing the DMARC protocol to force the fix is the right
way to go here.

-- 

*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

[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] DMARC and Data Hygiene

[Douglas Foster]

In a perfect world, we would have a two-tailed test, where PASS really
means "no malicious impersonation" and "FAIL" really means "malicious
impersonation".   Absent that ideal, we can try for a one-tailed test,
either
"FAIL" means "malicious interpretation" but "PASS" only means "uncertain",
or
"PASS" means "no malicious interpretation" and "FAIL" means "uncertain"

The discussion has convinced me that neither is entirely reliable, so we
have a zero-tail test.   But as a practical matter, I trust PASS more than
FAIL so I only act on FAIL after all other possibilities are ruled out.

In the typical environment, messages which are not blocked by sender
authentication will still need to pass content filtering, unless the sender
is whitelisted.  Whitelisting needs to be based on evidence to avoid
whitelisting an impersonator.   So if an evaluator does any whitelisting,
he needs a PASS rule to make whitelisting safe.   That makes PASS critical,
at least for that subset of messages (and those messages may not be from
DMARC-enforcing senders.)

I don't have the luxury of blocking messages that are legitimate and needed
for business purposes, so I have to quarantine and inspect for messages
that are uncertain.   Sender authentication FAIL is prioritized for that
quarantine and review process.Messages which pass sender authentication
can still get blocked during content filtering.  Content filtering failures
often indicate malicious senders, so those results are reviewed and often
become sender authentication blocks.

Doug






On Wed, Jun 21, 2023 at 11:46 PM Scott Kitterman 
wrote:

> I think that's exactly backwards.  The most DMARC pass can mean is from
> who it
> says it's from.  It says nothing about if the message should be accepted.
> Even in the case of email directly from the infrastructure of a high
> reputation domain, there's no guarantee it didn't get there because one of
> the
> employees got phished and their credentials or client are compromised.
>
> Scott K
>
> On Wednesday, June 21, 2023 9:26:28 AM EDT Douglas Foster wrote:
> > Every allowed message is presumed to be free of malicious impersonation.
> > That presumption is either based on evidence (some mixture of DKIM, SPF,
> > and fcDNS) or blind faith. "Positive assertions" are intrinsic to
> what
> > we are doing.  Without them, we have only blind faith.
> >
> > Doug Foster.
> >
> > On Tue, Jun 20, 2023, 1:29 PM Dotzero  wrote:
> > > On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman  >
> > >
> > > wrote:
> > >> I am starting a separate thread, because this isn't just about SPF.
> > >>
> > >> I think the criticism of the reliability of SPF data is valid, but I
> > >> think
> > >> DKIM is similarly problematic.  Once you get rid of SPF, you'll find
> you
> > >> haven't really solved much.  The next logical step will be to get rid
> of
> > >> DKIM.
> > >>
> > >> DKIM has man wonderful features, but the bottom line for DMARC is a
> valid
> > >> DKIM
> > >> signature indicates that the mail was sent (at some point) from an MTA
> > >> that
> > >> was authorized by the signing domain.  This is what a SPF pass result
> > >> means
> > >> too.  DKIM has broader utility in DMARC because it can persist through
> > >> some
> > >> indirect mail flows, but either way, an SPF pass and a valid DKIM
> > >> signature
> > >> both mean the message was authorized by the domain in the relevant
> > >> identity.
> > >>
> > >>
> > >> The particular SPF problem that's being the focus of some much
> attention
> > >> is
> > >> addressed in the RFC 7208 security considerations (See section 11.4).
> > >>
> > >> DKIM has a similar, but different problem.  The DKIM replay problem is
> > >> bad
> > >> enough that the IETF has chartered a working group to try to address
> it:
> > >>
> > >> https://datatracker.ietf.org/doc/charter-ietf-dkim/
> > >>
> > >> I'll lay out examples to demonstrate:
> > >>
> > >> Case 1 - First Party Only
> > >>
> > >> An organization only authorizes email to be sent from MTAs it directly
> > >> controls (I know this mostly doesn't exist, but it's useful to show
> where
> > >> the
> > >> problems are).  The organization does not send email for any third
> > >> parties.
> > >>
> > >> In this case, as long as the organization can limit sending to
> authorized
> > >> users, the quality of both SPF and DKIM pass results should be well
> > >> aligned
> > >> with the nature of the mail the organization sends.
> > >>
> > >> Case 2 - Sender For Others, Own Domain
> > >>
> > >> An domain uses it's own domain to send mail for others (like all
> webmail
> > >> providers).  The domain's email is sent using it's own
> infrastructure, so
> > >> it
> > >> doesn't need to worry directly about third parties.
> > >>
> > >> In this case, there's still no real risk of external forgery, so an
> SPF
> > >> or
> > >> DKIM pass means it was sent by the domain.  The risk is to the
> domain's
> > >> reputation if users sign up and use the service to send "bad" mail.
>

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

[Alessandro Vesely]

On Wed 21/Jun/2023 23:24:57 +0200 John Levine wrote:

It appears that Alessandro Vesely   said:
After sleeping on it, I think the new tag could also specify DKIM /and/ SPF, 
besides or and one only, ...


I am reasonably sure that when DMARC was designed they considered that and
rejected it.



Perhaps the landscape slightly changed since?


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