ignore_hops cannot be set to a constant, when emails sometimes first run over a local mailing list manager

[dilyanpalauzov]

I have on the same system RoundCube and Mailing list manager. When an email for me enters the system, the top-second Received: header contains information about how the email entered the system. When the email is first sent from outside to the mailing list manager and then to me, the top-second Received: header contains information about how the mailing list manager transmitted the email to the LDA. Example:

Received: from mail.aegee.org ([unix socket])
         by mail.aegee.org (Cyrus 3.4.4) with LMTPA;
         Mon, 19 Dec 2022 08:44:21 +0000
Received: from mail (localhost [127.0.0.1])
        by mail.aegee.org (8.17.1/8.17.1) with ESMTP id 2BJ8iFIV2112641;
        Mon, 19 Dec 2022 08:44:19 GMT
Received: by LISTS.AEGEE.ORG (LISTSERV-TCP/IP release 17.0) with spool id
          16690518 for ZZZ@LISTS.AEGEE.ORG; Mon, 19 Dec 2022 08:44:15
          +0000
Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com
          [209.85.214.170]) by mail.aegee.org (8.17.1/8.17.1) with ESMTPS id
          2BEIoBw93590222 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384
          bits=256 verify=OK) for <ZZZ@lists.aegee.org>; Wed, 14 Dec
          2022 18:50:12 GMT
Received: by mail-pl1-f170.google.com with SMTP id x2so2978273plb.13 for
 <ZZZ@lists.aegee.org>; Wed, 14 Dec 2022 10:50:12 -0800 (PST)

Relevant in this case is the fourth header from top, since it contains information whether the email entered the system in a secure manner (TLS).

Provided that Received headers have tho form from X (Y [1.2.3.4]) by Z, where X and Y are likely the EHLO-greeting / invers PTR IP-lookup, tls_icon shall detect the header that was first inserted, when the email entered the system and look in it for STARTTLS-signs.

Instead of the property $config['tls_icon_ignore_hops'] = …; there shall be another property with known hosts as strings for the system and the first header (the one closest to the end of the email), which is to the current system, but not from the current system, shall be checked for STARTTLS-information.

[GermanCoding]

This was one of the suggested options in #3, but due to the added complexity we only added a simple skip option. Requoting my original comment from that issue:

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.

Scanning for a given host in Received headers requires some care to do it right and adds a bunch of new moving parts. We probably want do this someday anyhow, as I imagine this setup isn't that atypical, but its not on my priority list for now.

[Jordo-o]

I have written a fix to review all Received headers (all hops) via the raw_headers data.
If you are interested, I can share it with you.

[williamdes]

I have written a fix to review all Received headers (all hops) via the raw_headers data. If you are interested, I can share it with you.

Sure, please share it or open a pull-request with it