Support Sendmail

[GermanCoding]

See issue #11. This is blocked on:

• More tests/confirmation this is working (Appears to be confirmed by @dilyanpalauzov)
• Does Sendmail also log local users in a similar way to Postfix? If so, we need to add a regex for that too. (Not entirely clear; If this is required it can be added later)
• Documentation: Is this default Sendmail behaviour, or are there switches for TLS logging, like in Postfix? (No, defaults)

[dilyanpalauzov]

This does work, when I set $config['tls_icon_ignore_hops'] = 1;.

Isn’t it sufficient to check for ESMTPS or ESMTPSA in Received: per RFC 3848, avoiding the distinction between postfix, sendmail, exim?

The headers I cited are generated by default, without extra configuration, apart from enabling STARTTLS.

You could also check just the verify= parameter, it can have these values:

TRUSTED     verification via DANE succeeded.   
OK          verification succeeded. 
NO          no cert presented. 
NOT         no cert requested. 
FAIL        cert presented but could not be verified, e.g., the signing CA is missing.  
NONE        STARTTLS has not been performed. 
CLEAR       STARTTLS has been disabled internally for a clear text delivery attempt.
TEMP        temporary error occurred.
PROTOCOL    some protocol error occurred at the ESMTP level (not TLS). 
SOFTWARE    STARTTLS handshake failed, which is a fatal error for this session, the e-mail will be queued.

[dilyanpalauzov]

for is part of Received:, only when there is only one recipient. This works with many recipients: const SENDMAIL_TLS_REGEX = "/\(version=(TLS.*)\)/im";.

[GermanCoding]

Isn’t it sufficient to check for ESMTPS or ESMTPSA in Received: per RFC 3848, avoiding the distinction between postfix, sendmail, exim?

One of the plugin's ideas was to have a small tooltip with extra "expert" information, i.e. cipher used or whatever else the MTA displays. We don't get that information just from looking at the S in the protocol. Also, at least for Postfix, other delivery protocols such as LMTP would have to be considered.

for is part of Received:, only when there is only one recipient. This works with many recipients: const SENDMAIL_TLS_REGEX = "/\(version=(TLS.*)\)/im";.

Do you have a test vector for this, so that we can add tests for this?

[dilyanpalauzov]

Also, at least for Postfix, other delivery protocols such as LMTP would have to be considered.

You can consider LMTPS and LMTPSA, but I do not think they are practical here. That LMTP-delivery headers do not say anything about whether the email was transmitted securely from the outside world to your system, the are about transmissions within your system.

One of the plugin's ideas was to have a small tooltip with extra "expert" information, i.e. cipher used or whatever else the MTA displays.

This is a nice idea. What are the chances to get it implemented in reasonable time?

Do you have a test vector for this, so that we can add tests for this?

Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134])    by mail.aegee.org (8.17.1/8.17.1) with ESMTPS id 2BLGrgYw3602565    (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 21 Dec 2022 16:53:42 GMT

[GermanCoding]

This is a nice idea. What are the chances to get it implemented in reasonable time?

This already exists. This is what the regex is used for.

You can consider LMTPS and LMTPSA, but I do not think they are practical here. That LMTP-delivery headers do not say anything about whether the email was transmitted securely from the outside world to your system, the are about transmissions within your system.

We can only ever make a safe statement about the last hop: Every previous hop may be untrusted and may have rewritten or modified headers and content. I also tried to make this clear in the README: The assurance given by the lock icon can only ever apply to the final hop(s), not to any previous communication. The ignore_n_hops option is already a workaround, which requires the admin to explicitly trust these final hops. We can't infer how the mail setup may look like and it is theoretically possible that an external mailserver receives mail and forwards it to us via LMTP(S) (i.e. if this third party is contracted to do this for us). If we don't control or trust that external mailserver, we can only make a (true) statement ("TLS vs no TLS") about the communication between them and us - we have absolutely no idea what else is going on. It is true that this data may be less interesting than what happened externally, but we shouldn't make assumptions unless the mail admin allows us to.

[dilyanpalauzov]

Does Sendmail also log local users in a similar way to Postfix? If so, we need to add a regex for that too.

I do not think so. Even if sendmail could insert in some header the username, who called the sendmail command, I do not use it. sendmail can insert a warning, if the user, who invoked sendmail is not in the list of “trusted uaers”, but this is a warning. Email submitted over SUBMISSION (port 465 or 587) cannot have that marks. That said I do not think it is relevant, whether sendmail does insert this information.