multiple Received headers handling

[maniac0r]

In setup with amavisd-new the first Received header does not contain information about TLS , just information about local amavis-postfix connection, for example, here is chronological extract of Received headers from one email:

Received: from localhost (unknown [127.0.0.1]) by localhost.sk (Postfix) with ESMTP id 120FE21170 for x@y.z; Sat, 27 Feb 2021 22:57:57 +0000 (UTC) Received: from localhost.sk ([127.0.0.1]) by localhost (localhost.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPlRL9aYu1cL for x@y.z; Sat, 27 Feb 2021 23:57:55 +0100 (CET) Received: from mx1.slc.paypal.com (mx2.slc.paypal.com [173.0.84.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by localhost.sk (Postfix) with ESMTPS id 9EF9B20AA9 for x@y.z; Sat, 27 Feb 2021 23:57:54 +0100 (CET)

Please would it be possible to iterate over the Received headers and pick only the last one (which is actually describing real incoming connection, including relevant TLS info)?

Thanks!

[GermanCoding]

The plugin currently deliberately checks only the last hop of the email.

The reasoning behind this was that previous hops may not actually belong to us, but may belong to other organizations we don't know. For example, orgs such as GitHub and Google generate local Received headers in their outbound infrastructure. Also, even if a previous hop does belong to us, we have no idea if the hops that come after it are secured in the same way.

Hence I took the decision to solely base the plugin statement on the last hop and put a warning in the readme stating that previous hops may be insecure. There really is no way to know.

However, I understand that some setups generate multiple local Received headers as part of their forwarding/distribution/filtering process, which can be annoying because if these are local systems, you obviously aren't going to use TLS on them.

Possible options I can think of:

• If you have no use for the local Received headers of your filter, you could try turning them off. This is what I do for my final delivery - I've configured my storage server to not add a Received header, as it serves no real purpose (some RFC standard states you should always add them to allow tracing, but sometimes they're nothing but useless clutter).
• I might consider adding a feature that allows ignoring of the last n hops. For example, if you know that your setup always generates n internal hops, the plugin could check the l - n Received header. This would mean adding new configuration option that allows configuring what n should be. If you have interest in this, PR's are always welcome.

[maniac0r]

Thanks for reply. The configurable number of last N hops to skip would work for me (and I guess for most people with additional "local" mail processing. Maybe there could be even regex configuration to specify which entries should be skipped - for e.g. skipping my own server(s) entries like: by localhost (localhost.sk [127.0.0.1]) would be regex like '^\s+by localhost (\S+ [127.0.0.1])'

I would yet need to have a look if i could remove internal hops headers somehow that would be quick solution too.