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

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 14 June 2023 04:02 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A2AC151700 for <dmarc@ietfa.amsl.com>; Tue, 13 Jun 2023 21:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FwFzmRkwaP0 for <dmarc@ietfa.amsl.com>; Tue, 13 Jun 2023 21:02:10 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8A6C15106E for <dmarc@ietf.org>; Tue, 13 Jun 2023 21:02:10 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-4f619c2ba18so7463793e87.1 for <dmarc@ietf.org>; Tue, 13 Jun 2023 21:02:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686715328; x=1689307328; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=jiY8ihHORbLpSckHEsW47V2CSf3zGhmLZ8xDP10Y77k=; b=NapihHtiRGrGUCG+N+fn4xdIuBfiQqY7QX0huOCZkkmnbGxy7ONqW5RE8cKfCq66v2 wdEJXOvoOsDGOa86cqjZyEeQVRqS0J80v09/WT+6yeafP7t/20kHQ6fAS4ZlSCUk7+as lwILPcql9MNDY8++nv/PXoXEJQFUi7yryztt9tFqgqhPCgEoCTnB7O+prfirCLvINC4R rOO0NgiwPiwA6tTk4dAs1MFPs46w5bxytziG96DoczBmfTnrhsETQZnsDjUX0PbHWMAY xQLzEk8zN7re7n5NEi5s8pBj5AunB1S+WiPh+sMezvg4hq4Q4hDJsSlOkSZKIm+WmE2s zDfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686715328; x=1689307328; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jiY8ihHORbLpSckHEsW47V2CSf3zGhmLZ8xDP10Y77k=; b=dJR44GoU4wbzcko8/6faeiOgGQaAMpriWHqpBn/4ANBqrZaLQAgEYHyPn0cHJcRcdy GDA7aAygHBdLBeqcYNgrYjEhUSpuAjnXGZcV6nlO65MrGZmX2NaEpTePbjN+8YGfa0q/ WcbY70rtKy6qbWKhFLKY7T6GnyLIESjy6GSS3vx19T1/oM5kK9f5rEMQy9wVG5mWhY+U r9Cb4HKmnFG67h8o7twJADpR1uTHCGAPMCkrJwm0K3anAJWNwLSDNiMhXwUp3n46Gdzf QthYT2nobOthIODd5+fyanQFZLQM8fmw+hR+I087CndCGyMk+/bAx4XvBSlTaiByixub IPdg==
X-Gm-Message-State: AC+VfDzLsvXSNkQo/OJOVkaR1sKpjTyiN5TmAT752mOrbyV5posFf74a iywkzYQNn54p6H7XTB0ZY7YBVemwDtu9f4V547yTNg69ggw=
X-Google-Smtp-Source: ACHHUZ6EUCp7S2MT+ngJpGbEn4/bRMnVTWI0OiHGjjXsN9btX2Fwb+dvHLDif6evatDZPIVbMS+lkp/VBW0COF353Nw=
X-Received: by 2002:ac2:5f96:0:b0:4f4:d41b:f416 with SMTP id r22-20020ac25f96000000b004f4d41bf416mr7225813lfe.4.1686715327831; Tue, 13 Jun 2023 21:02:07 -0700 (PDT)
MIME-Version: 1.0
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <25736.57534.195344.782189@fireball.acr.fi>
In-Reply-To: <25736.57534.195344.782189@fireball.acr.fi>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Wed, 14 Jun 2023 00:01:57 -0400
Message-ID: <CAH48ZfyaXG8z155kjj0udTiCn8CtHnikfmL+nTXpeR=ZGpTqWA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f3e98805fe0f03ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/WsOaw0tYlzMFXFqvCgj7OFMaWNk>
Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2023 04:02:13 -0000

This topic raised a question, at least in my mind, whether DKIM signing
algorithms are subject to random failures.   If random failures occur, they
could be blamed on either the sender algorithm or the receiver algorithm.
  The question can be assessed on incoming messages, using authentication
results, or on outgoing messages, using aggregate reports.

My environment has a single MX performing DKIM checking, with essentially
zero mailing list traffic.
I also have a single MTA performing DKIM signing.
The signing server is a different software implementation than the checking
server.

For outgoing messages, I see no evidence of random failures.   All of the
reported DKIM failures appear to have explanations.

For incoming messages, I defined a unique configuration as the tuple of (
Helo Domain, MailFrom domain, and From domain ).  Then I looked at
verification percentages for signed messages from each tuple.    The
results were interesting:

   - 92% of tuples, sending 89% of all signed messages, had 100%
   verification rates
   - 5% of tuples, sending 2% of all signed messages, had 0% verification
   rates
   - 3% of tuples, sending 9% of all signed messages, had a verification
   rate between these limits.
   - Of all messages with DKIM failures, 85% were authenticated using
   aligned SPF PASS.

These statistics are based on 100% of incoming messages, regardless of
subsequent disposition.

My conclusions:

   - SPF is a necessary supplement to DKIM.
   - DKIM can be reliable:   Most senders and receivers have 100% reliable
   DKIM implementations.
   - Senders with 100% failure rates appear to be playing games with DKIM.
    Some of these may already be on my block list.  The rest should  be
   reviewed to see if they should be added to my block list.
   - The 5% with inconsistent results need further investigation.   Perhaps
   a server farm has one server that is generating wrong signatures.

Doug Foster


On Tue, Jun 13, 2023 at 5:34 PM Tero Kivinen <kivinen@iki.fi> wrote:

> Barry Leiba writes:
> > > DKIM only: ~99.5%
> > > DKIM + SPF: ~100%
> > > SPF only: ~100%
> >
> > That's interesting and disturbing if it remains consistent.
>
> The statistics I have are quite different. The failure rate is much
> bigger both in DKIM and SPF.
>
> Following statistics is random subset of emails going through iki.fi
> system, from last 30 days, consisting bit less than 4 million emails.
> Iki.fi is email forwarding service, so about 90% of those emails will
> fail SPF checks after iki.fi sends them forward. DKIM will go through
> unmodified, and we do not modify normal messages (spam messages might
> get tagged as spam depending on the members configuration), so 85.75%
> of emails will still have valid DKIM signature after passing iki.
>
> We do graylisting of blacklisted ip-addresses, thus spammers that do
> not work around graylisting are not part of the statistics.
>
> There is significant amount of mailing lists going through iki, and
> quickly checking that 1.58% of emails going through has spf-errors,
> dkim signers or similar with domain name in form of list.domain or
> lists.domain, so that will cause some of the SPF and DKIM failures.
> Note, that this only counts cases where the domain name was used in
> the verification and printed in the logs i.e., only in error cases.
>
> As we are using ARC, and we add ARC-Authentication-Results header to
> all emails as first step when they come in, and I used those headers
> to generate these statistics.
>
> First some generic statistics:
>
>         Number of ARC-header levels
>         ===========================
>         95.61%  3811208 1
>         3.83%   152487  2
>         0.44%   17711   3
>         0.09%   3586    4
>         0.01%   460     5
>         0.01%   349     6
>         0.01%   207     7
>         0.00%   36      8
>         0.00%   15      9
>         0.00%   1       10
>
>         Mailer
>         ======================
>         91.96%  3665744 MTA-v4
>         8.04%   320315  MTA-v6
>         0.00%   1       MSA
>
> So 3.83% of emails already had one ARC header, and 0.56% had more than
> one arc header, with exactly one email having 10
> ARC-Authentication-Results headers. Most of the emails do not have ARC
> headers.
>
> 92% of traffic came in using IPv4..
>
> Then lets compare DKIM, SPF, DMARC and ARC results
>
>         DKIM summary results
>         =========================
>         85.75%  3417541 pass
>         13.11%  522367  none
>         1.12%   44604   fail
>         0.02%   893     temperror
>
>         SPF results
>         =========================
>         86.50%  3447577 pass
>         8.78%   349947  none
>         1.89%   75137   softfail
>         1.18%   46913   permerror
>         1.12%   44553   fail
>         0.49%   19536   neutral
>         0.05%   2037    temperror
>
>         DMARC results
>         =========================
>         62.82%  1243393 pass
>         30.99%  613478  none
>         6.05%   119800  fail
>         0.08%   1485    temperror
>         0.06%   1244    permerror
>
>         ARC results
>         =========================
>         91.66%  160268  pass
>         8.34%   14584   reject
>
> As you can see 85.75% of incoming email was already signed by DKIM,
> and 86.5% of emails had SPF records that passed. So they both have
> about same amount if usage coming in to our servers.
>
> The difference is that only 1.14% of emails had errors (fail, or
> temperror) in their DKIM signatures (most of those were because the
> email was from the mailing list that modified the body, but did not
> generate new DKIM header), compared to the 4.24% of emails having SPF
> failures (softfail, permerror, fail or temperror). Meaning there were
> much more emails that failed SPF than DKIM. Even if we ignore the
> softfails, we still have about double the emails failing (2.35%).
>
> Note, that the dmarc and arc statistics are not from all of the
> emails, it only includes those which actually had DMARC or ARC
> information. For dmarc this was about 50%, and for ARC it was only
> 4.3% of all emails.
>
> Here are some statistics abut the DKIM processing and the error cases.
> 76.75% had one DKIM signature, and over 20% had more than one
> signature. Here is number of DKIM signatures and their results, i.e.,
> 22.22% of emails had two DKIM signatures both passing, and 0.34% had
> one signature that passed, and another that failed etc:
>
>         DKIM results
>         =======================================
>         62.67%  2497633 pass
>         22.22%  885372  pass,pass
>         13.06%  520332  none
>         1.04%   41477   fail
>         0.34%   13353   pass,fail
>         0.19%   7506    none,pass
>         0.15%   5910    pass,none
>         0.07%   2635    fail,fail
>         0.06%   2235    pass,pass,pass
>         0.05%   2034    none,none
>         0.03%   1296    pass,pass,pass,pass
>         0.03%   1026    pass,pass,fail
>         0.03%   1002    fail,pass
>         0.02%   892     temperror
>         0.02%   631     pass,fail,fail
>         0.01%   583     pass,none,none
>         0.01%   369     fail,fail,fail
>         0.01%   356     fail,fail,pass
>         0.01%   335     pass,pass,none
>         0.00%   86      pass,fail,fail,fail
>         0.00%   69      none,fail
>         0.00%   67      pass,fail,pass
>         0.00%   48      pass,pass,fail,fail
>         0.00%   27      temperror,pass
>         0.00%   26      fail,fail,none
>         0.00%   22      pass,temperror
>         0.00%   15      pass,pass,none,none
>         0.00%   10      none,pass,pass
>         0.00%   9       fail,fail,fail,fail
>         0.00%   7       pass,fail,none
>         0.00%   7       none,fail,fail
>         0.00%   7       fail,fail,fail,fail,none
>         0.00%   4       pass,none,pass
>         0.00%   4       fail,none
>         0.00%   4       pass,fail,fail,fail,fail
>         0.00%   3       fail,pass,pass
>         0.00%   2       pass,pass,pass,pass,pass,pass
>         0.00%   2       pass,none,fail
>         0.00%   2       pass,pass,pass,fail
>         0.00%   2       none,fail,pass
>         0.00%   1       temperror,temperror
>         0.00%   1       pass,pass,pass,pass,fail
>         0.00%   1       fail,fail,temperror
>         0.00%   1       pass,temperror,pass
>         0.00%   1       none,none,none
>
> The none,none,none cases etc are where it had 3 DKIM signatures but it
> could not find any DKIM records from the DNS, and was not able to
> verify the signatures.
>
> And here are reasons why dkim signature checking failed. The Invalid
> DKIM record actually results the dkim result to be none, but other
> errors result to the final result to be fail. As you can see there is
> significant part where the body hash did not verify (most likely
> because this is coming from mailing list). This only includes those
> emails where there was no passing DKIM signature at all.
>
>         DKIM failures
>         ================================================================
>         36.34%  26619   invalid DKIM record
>         36.28%  26577   body hash did not verify
>         20.34%  14900   headers rsa verify failed
>         2.78%   2034    invalid DKIM record,invalid DKIM record
>         1.62%   1186    headers rsa verify failed,headers rsa verify
>                         failed
>         1.62%   1185    body hash did not verify,body hash did not
>                         verify
>         0.49%   360     body hash did not verify,body hash did not
>                         verify,body hash did not verify
>         0.30%   218     headers rsa verify failed,headers eddsa verify
>                         failed
>         0.09%   65      invalid DKIM record,body hash did not verify
>         0.05%   37      headers rsa verify failed,body hash did not
>                         verify
>         0.04%   26      body hash did not verify,body hash did not
>                         verify,invalid DKIM record
>         0.01%   9       headers eddsa verify failed,headers rsa verify
>                         failed
>         0.01%   9       body hash did not verify,body hash did not
>                         verify,body hash did not verify,body hash did
>                         not verify
>         0.01%   7       body hash did not verify,body hash did not
>                         verify,body hash did not verify,body hash did
>                         not verify,invalid DKIM record
>         0.01%   6       invalid DKIM record,body hash did not
>                         verify,body hash did not verify
>         0.01%   4       headers rsa verify failed,headers rsa verify
>                         failed,body hash did not verify
>         0.01%   4       invalid DKIM record,headers rsa verify failed
>         0.00%   3       headers rsa verify failed,headers rsa verify
>                         failed,headers rsa verify failed
>         0.00%   2       headers rsa verify failed,invalid DKIM record
>         0.00%   2       headers rsa verify failed,body hash did not
>                         verify,body hash did not verify
>         0.00%   2       body hash did not verify,invalid DKIM record
>         0.00%   1       invalid DKIM record,invalid DKIM
>                         record,invalid DKIM record
>         0.00%   1       body hash did not verify,headers rsa verify
>                         failed
>         0.00%   1       invalid DKIM record,headers rsa verify
>                         failed,headers rsa verify failed
>
> SPF failures show that it is not that big difference whether you use
> IPv4, or IPv6, as this matches the generic use of IP protocols for
> these incoming emails:
>
>         SPF failures
>         ==============================================================
>         92.71%  41307   MTA-v4: domain of x@y does not designate ipxxx
>                         as permitted sender
>         7.29%   3246    MTA-v6: domain of x@y does not designate ipxxx
>                         as permitted sender
>
> For DMARC failures there is quite a large number of those which do not
> have SPF or DKIM. I do not really known what I should interpret from
> those other errors for DMARC.
>
>         DMARC failures
>         ============================================================
>         52.53%  62925   No valid SPF, No valid DKIM
>         32.97%  39504   SPF not aligned (relaxed), DKIM not aligned
> (relaxed)
>         5.41%   6486    SPF not aligned (relaxed), No valid DKIM
>         3.49%   4186    No valid SPF
>         2.68%   3213    SPF not aligned (relaxed)
>         2.07%   2484    No valid SPF, DKIM not aligned (relaxed)
>         0.25%   297     SPF not aligned (strict), DKIM not aligned (strict)
>         0.21%   256     SPF not aligned (relaxed), DKIM not aligned
> (strict)
>         0.17%   207     SPF not aligned (strict)
>         0.09%   106     SPF not aligned (strict), No valid DKIM
>         0.08%   100     SPF not aligned (strict), DKIM not aligned
> (relaxed)
>         0.03%   36      No valid SPF, DKIM not aligned (strict)
>
> For ARC there is quite big number of signature check failures, I am
> not actually sure whether that is because there is no key to be found
> or what is the issue.
>
>         ARC failures
>         ===========================================================
>         80.36%  11720   "signature check failed: fail, {[1] =
> sig:xxx:reject}"
>         6.37%   929     "cv is fail on i=4"
>         6.31%   920     "cv is fail on i=2"
>         3.73%   544     "seal check failed: fail, {[1] = sig:xxx:reject}"
>         1.89%   275     "cv is none on i=2"
>         0.80%   116     "signature check failed: fail, {[1] =
>                         sig:xxx:dns request to xxx
>         0.52%   76      "cv is fail on i=3"
>         0.02%   3       "seal check failed: fail, {[1] = sig:xxx:dns
>                         request to xxx
>         0.01%   1       unknown
>
>
> Summary: Looking at the data there is much more SPF related failures
> than DKIM related failures, and as I said 90% of these emails WILL
> FAIL SPF checks when iki.fi will forward them to their final
> destination (only those that say +all or do not publish SPF record
> will survive), while the DKIM records still are correct.
>
> We have several cases where final email domain where the user asks us
> to forward his email is only using SPF, thus we simply ask them to
> switch to someone who does email properly and uses DKIM too...
>
> If the DMARCv2 would mandate support of DKIM and would get rid of the
> SPF checks completely then hopefully more people would actually start
> using DKIM also in the verification. It is quite widely already used
> in the generation of the messages.
>
> Of course this is selected data-set as if out user find out he can't
> use his iki.fi address for certain service as it does not do DKIM, and
> his/her final destination checks SPF, he/she will not use his iki.fi
> address in those places or he/she changes his email mailbox provider
> (which is easy to do if all your emails go through iki, you simply
> change the forward to go to your new address, and hour later
> all your emails go there :-)
> --
> kivinen@iki.fi
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>