Re: [ietf-smtp] broken signatures, was Curious

Dilyan Palauzov <> Wed, 22 July 2020 07:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F72C3A0F55 for <>; Wed, 22 Jul 2020 00:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f91ft69wvI4b for <>; Wed, 22 Jul 2020 00:37:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F219B3A0F4B for <>; Wed, 22 Jul 2020 00:37:33 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id 06M7bTRX1133576 for <>; Wed, 22 Jul 2020 07:37:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1595403450;; bh=2x4gwvFFHZ52gZ9oHic+9r+eIUo1sziVuvArvtT8+PI=; h=Date:From:To:Subject:References:In-Reply-To; b=aSI+K1b8nkm/4hfabQ4zU34e10v8NHwI4rdCXL4JUVccp/+N+ofX0toePP0upD86a cgXLgki9ggrb43Qnpg3LShshzz8dB5C7gVPy2mETeig5gvquckdX+twMOMthFE4E88 AOZWuQ9P4mr9wIWgOzsgzV30lDWL/j6S/ja7j0yEexq5+LfF4eYxCnVfmHTX2Qj/mb O0/ObIo2hcr6ae4tOOb8iyhXu/fE/LTvmzpmNZUFg0lKH9EHeIP7gvJwVRgNqBinpn lx2SDz6fT8XDEYZGzIlhBFI3XW1dgz6KvW4mpT7p8OANUDNZKjZYczg3/jBNY/3IX7 2jmrYIco12IyMMvFWtoCNbcQ74BfinOKeiMI2GpMOHab+TzOxDNoGyLSdmaEKiWZLS 47AL/E1OhpaRku4mQc5l+aYImKlRgg836LIu81Z61CAEZRHUqGhxA5Qm7AXUjck+A1 GZwUhsuOM6ufrgT49f9WH0CtakWWax7TZAI84j9I4FLH4PhRbtZj2KjNl1Ha6/IzQq Bz92UMgYcZ0pQ2EbyQzryzDZwKfLL9MiO6lB9iCJt4tJE3fiQOfOVmhvO7GoOa5bAO aqCA58lg3Y8p5I8PgjHFFNfGFZAEc4DZ6osizutD9oTSNiGhckQ7jZLOsjmYc00byP w9mROyO1KoDtX4OumQJCQ1HM=
Authentication-Results:; dkim=none
Received: from ( []) by (Horde Framework) with HTTPS; Wed, 22 Jul 2020 07:37:29 +0000
Date: Wed, 22 Jul 2020 07:37:29 +0000
Message-ID: <>
From: Dilyan Palauzov <>
References: <> <20200721201938.D4F7D1D5CAD3@ary.qy> <>
In-Reply-To: <>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.4 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [ietf-smtp] broken signatures, was Curious
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2020 07:38:02 -0000


> A better (but annoying) reason is there are a smattering of servers which
> reject messages
> based on broken DKIM signatures, against the rfc.

This does not have to be against the RFC.

An open source software for doing DKIM, that was last released  
(tagged/a tarball was created) in May 2015, got a bugfix in October  
2015.   Whoever uses the released version, does for some emails the  
DKIM calculations wrong.  This gets evident, after evaluating a lot of  
aggregate reports on a semi-busy server.  Since the users of the  
software do not understand DKIM/do not evaluate the aggregate reports  
for their own servers, their keep running the unpatched software.  So  
some correct DKIM headers are validated as wrong, and bad DKIM headers  
are inserted.  When DMARC says to reject messages that do not validate  
DKIM, and either the recipient considers valid DKIM as invalid, or the  
sender inserts invalid DKIM, then advancing from DKIM to DMARC/ARC  
does not make sense.

SMTP-rejecting a suspicious message is much better that delivering the  
message to a recipient so, that the recipient is likely to overlook it.

To sum up, if a message is rejected because
- the DKIM was broken, so the rejection is against the RFC (no DMARC  
involved), or
- the DKIM was correct, but the DKIM evaluation software on the  
recipient site has bug in the calculation algorithm and the sender  
published DMARC reject, or
- the DKIM was inserted by software that does the signing wrongly, the  
sender publishes DMARC reject, and the recipient applies the RFCs  

has all the same consequences.

Finding and resolving DKIM bugs, not limited to DNS troubles, is  
essential to bring DKIM/ARC/DMARC forward.  My opinion is that there  
is no willingness in email operators to assist each other on this.   
Cooperation on the matter means, more or less, sending individual  
failure reports (otherwise one is not going to acknowledge, that s/he  
uses DKIM-software with bugs).


----- Message from Brandon Long <> ---------
    Date: Tue, 21 Jul 2020 13:35:29 -0700
    From: Brandon Long <>
Subject: Re: [ietf-smtp] broken signatures, was Curious
      To: John Levine <>
      Cc: ietf-smtp <>

> On Tue, Jul 21, 2020 at 1:19 PM John Levine <> wrote:
>> In article <>
>> you write:
>> >As useless mail headers do make emails heavier, I am in favour of
>> >removing DKIM-Signature headers, that are known to be broken, e.g.
>> >because the current host has modified (and resubmitted) the message.
>> The amount of bandwidth used by e-mail is a rounding error of the
>> Internet's total, which is mostly video these dayts, and the amount
>> used by broken headers is a rounding error on that rounding error.
>> Look at the headers of the mail in your inbox, particularly mail from
>> large providers, and you'll find megabytes of headers that nobody is
>> ever likely to look at or use.  This battle was over decades ago.
> A better (but annoying) reason is there are a smattering of servers which
> reject messages
> based on broken DKIM signatures, against the rfc.
> Brandon

----- End message from Brandon Long <> -----