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

Paul Smith <> Tue, 21 July 2020 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9C613A0AC5 for <>; Tue, 21 Jul 2020 14:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I9jVwqs7jYbe for <>; Tue, 21 Jul 2020 14:47:30 -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 3CB0D3A0AC3 for <>; Tue, 21 Jul 2020 14:47:28 -0700 (PDT)
Authentication-Results:; spf=none; auth=pass (cram-md5) smtp.auth=pscs
Received: from ([]) by ([] running VPOP3) with ESMTPSA (TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384) for <>; Tue, 21 Jul 2020 22:47:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; q=dns/txt; s=lmail; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To :Content-Type:Content-Transfer-Encoding:Cc:Reply-to:Sender; t=1595367704; x=1595972504; bh=ysz07MFn0rXhDw3TrDNHnh+fa7hlUNl6Pfo1XgG8hD0=; b=OvSC8+5zd5UPaNWL5/EEbY6KoIu3kvoLGAvy82hxcS8G+Xdbdn3Nexlq7r2GQcKQQfFx6Cbx mH2GvpHMcEFygIVNN+RoFhrOeZwbOMCDbYN7w91u4GXStgy/sxPKUXPt/1ZhAaYEN7dhkDkXhy YfOP01//X9v80lM7Om9+ySVoc=
Authentication-Results:; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from [] ([] ( by ([] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384) for <>; Tue, 21 Jul 2020 22:41:42 +0100
References: <20200721201938.D4F7D1D5CAD3@ary.qy> <>
From: Paul Smith <>
Message-ID: <>
Date: Tue, 21 Jul 2020 22:41:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V7.10 - Registered
X-Organisation: Paul Smith Computer Services
X-VPOP3Tester: 12 345
X-Authenticated-Sender: pscs
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: Tue, 21 Jul 2020 21:47:33 -0000

On 21/07/2020 21:45, Hector Santos wrote:
>> 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.
> I heard this stated by you a few times. I never brought into it. It 
> wasn't a problem to be concern about a few decades ago.  Now it is. 
> It's junk and its growing.  The more it grows the more overhead we 
> have. It makes systems who are suppose to be ignorant about the junk, 
> work harder.  It makes your "View Source" more cryptic. 

Hmm, my view is that the headers should be at least vaguely useful at 
the recipient end. That means that OK examples could be:

- an old (non validating) DKIM record
- X-Virus-Scanned: amavisd-new at
- X-BeenThere:
- X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
   tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
   SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no

But useless ones could be:
- X-Data: E5-cx76azc4-nr189/4/434-00019lcm
- X-MA-Instance: 
- X-PP-Email-transmission-Id: 407b928e-cb6d-11ea-a29f-b875c0aa69dc

(The above are real examples from some recent legitimate messages I've 

The former ones tell me something. It may or may not be that useful. It 
may nor may not be true, but it tells me something. The latter ones tell 
me (the recipient) nothing at all. I'm honestly not sure why the latter 
data is in the headers at all.

It *may* be that if I ask for support from Paypal about an email, 
they'll ask me 'What was the "X-PP-Email-Transmission-Id'' header in 
that message? But I seriously doubt that would happen. If it did, then 
adding that header is OK, otherwise, no. In any case, the Message-ID 
should be sufficient for them to trace it if that's what they need to do.

The former set may be more useful if it was tagged with WHICH server 
added those headers, but that's it.



Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at