plugins/postfix - disable GSSAPI authentication

[pmhausen]

Important notices Before you add a new report, we ask you kindly to acknowledge the following:

• [X] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [X] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [X] The title contains the plugin to which this issue belongs

Describe the bug Depending on the features of the relay host outbound authentication for relaying might fail.

To Reproduce

1. Configure the Postfix plugin, General, e.g. Smart Host: mail2.pluspunkthosting.de:587 Enable SMTP Authentication: [X] Authentication Username: [email protected] Authentication Password: *******

2. Relay a mail through the Postfix server

Expected behavior Postfix should authenticate at the relay host and send the mail.

Observed behavior* The server offers in its ESMTP banner these authentication options:

250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5 GSSAPI 
250-AUTH=PLAIN LOGIN CRAM-MD5 DIGEST-MD5 GSSAPI 

Postfix fails and the message stays in the queue forever:

root@opnsense:/var/log/postfix # mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
DC77FF7E4       319 Fri Feb 11 17:52:51  [email protected]
(SASL authentication failed; cannot authenticate to server mail2.pluspunkthosting.de[217.29.33.229]: generic failure)
                                         [email protected]

If one increases the debug level to 10, we get this additional info:

<20>1 2022-02-11T17:53:05+01:00 opnsense.ettlingen.hausen.com postfix/smtp 16930 - [meta sequenceId="14"] warning: SASL authentication failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_125))

I have come to the conclusion that inserting

smtp_sasl_mechanism_filter = !gssapi, !external, static:all

unconditionally is the only sensible way to go for now. OPNsense does not support GSSAPI so outgoing SMTP (client) authentication will always fail if the remote mailserver offers GSSAPI and this line is not present. Similarly all authentication mechanisms that rely on external infrastructure like e.g. Kerberos are currently not supported.

The patch does not change anything else.

PR incoming ...

Originally posted by @pmhausen in https://github.com/opnsense/plugins/issues/2830#issuecomment-1214375251

[OPNsense-bot]

Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

[fichtner]

I wonder why it’s enabled in the first case. Might be configured for base GSSAPI use but that isn’t present for us although krb5 port is there. If it thinks it can do it might be better to either disable in the port or repair there?

[pmhausen]

In the FreeBSD port you might want to use it - needs additional setup, though. But I do not see a need to change the ports default behavior.

The problem is rather that postfix with SASL tries to be clever and always uses the "strongest" mechanism the server offers. That precisely what this filter option is for according to the postfix docs.

This howto has got the best explanation I found so far, so I changed the config to use !external. https://mirror.math.princeton.edu/pub/postfix/SASL_README.html

The full list of SASL supported auth mechanisms can be found here: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Kind regards, Patrick

[pmhausen]

Some more info:

• Postfix is compiled with a dependency on cyrus-sasl2 when SASL is enabled. Which is necessary for authentication when Dovecot is not used. dovecot-sasl is always compiled in but does not make much sense on a firewall acting strictly as a relay.
• If SASL support is compiled in, GSSAPI support is, too, but it relies on the external tools that you get by installing cyrus-sasl2-gssapi. This is a separate module to cyrus-sasl2.
• We might consider including GSSAPI support in the future, but for that I would need to find out, what that actually does ;-) And then we would need UI support etc. etc.