Sendmail no longer works after upgrade to f37

Ask Fedora Ask in English
1

I have been using my sendmail.mc file for the past several years. After upgrading to Fedora 37, I get the following error message Relaying denied. Proper authentication required.

The strange thing is that my mail client does not even get the request for an authentication. I found this out by removing the user/password from my mail client, so it was supposed to prompt for a password, but it didn’t.

Here is my sendmail.mc 
divert(-1)dnl
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for Linux')dnl
OSTYPE(`linux')dnl
define(`confDEF_USER_ID',``8:12'')dnl
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A p y')dnl
define(`CERT_DIR', `/etc/letsencrypt/live/example')
define(`confCACERT_PATH', `CERT_DIR')
define(`confCACERT', `CERT_DIR/fullchain.pem')
define(`confSERVER_CERT', `CERT_DIR/cert.pem')
define(`confSERVER_KEY', `CERT_DIR/privkey.pem')
define(`confCLIENT_CERT', `CERT_DIR/cert.pem')
define(`confCLIENT_KEY', `CERT_DIR/privkey.pem')
define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confTO_IDENT', `0')dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(`masquerade_entire_domain')
FEATURE(`masquerade_envelope')
FEATURE(`allmasquerade')
MASQUERADE_DOMAIN(`example.com.')
FEATURE(local_procmail,`/usr/libexec/dovecot/deliver',`deliver -d $u' )dnl
MODIFY_MAILER_FLAGS(`LOCAL', `-f')
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
EXPOSED_USER(`root')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org')dnl
FEATURE(`dnsbl',`b.barracudacentral.org')dnl
FEATURE(`delay_checks',`friend')dnl
MAILER(`smtp')dnl
INPUT_MAIL_FILTER(`spamassassin', `S=unix:/var/run/spamass-milter/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl
INPUT_MAIL_FILTER(`opendkim', `S=inet:8891@127.0.0.1')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl
define(`confMILTER_MACROS_HELO',`s, {tls_version}, {cipher}, {cipher_bits}, {cert_subject}, {cert_issuer}')dnl
define(`confMILTER_MACROS_ENVRCPT',`r, v, Z, {rcpt_mailer}, {rcpt_host}, {rcpt_addr}')dnl
define(`confMILTER_MACROS_ENVFROM',`i, {auth_type}, {auth_authen}, {auth_ssf}, {auth_author}, {mail_mailer}, {mail_host}, {mail_addr}, {rcpt_addr}')dnl

I have run testsaslauthd and authentication works. I am kind of puzzled by all this, because I don’t see any issues with my sendmail.mc and it worked before the upgrade.

Has anyone seen a similar issue before and/or know what could be the problem?

1 Like
2

That error seems to indicate that outgoing mail is being denied as it originates from your pc and not from the domain of your connecting mail server.

Almost all mail servers block relaying to prevent spam email. You will need to work out with your ISP why the service is now blocked and was not previously. The detailed content of the bounced outgoing mail should give you some pointers as to what caused the bounce. The ISP should also be able to assist with their detailed logs.

The issue may be nothing more than an upgraded security profile on your end that is not compatible with the ISP so proper handshaking does not occur.

3

Yes, but when I authenticate against the server the mail server should see the client as local. At least when it comes to relaying. (That’s what my mail server did before the upgrade with the same config.)

It’s my mail server (in a DC, not at home) and I allow relaying mails when a user is authenticated. The problem is that the mail server no longer asks for an authentication when a user connects to 465 (implicit TLS).

After several hours I found out that the sendmail version that comes with f37 has a problem with the following setup:

define(`confAUTH_OPTIONS', `A p y')`

It seems that A is no longer supported and/or disables authentication against the mail server.

The solution is to remove A from the options:

define(`confAUTH_OPTIONS', `p y')`

This is certainly a weird one, since I had been using this setup for the last 10 years. I can only say that the sendmail version in f37 broke this setup.

1 Like
4

It seems I was right. The mail server update broke the previously used authentication. (though I thought it was your PC that was upgraded).

Upgrades to software for security reasons or otherwise can break long term configs, and this is just one example.
:man_shrugging:

5

I rather think that this is a bug. At least I couldn’t find anything that says that A will destroy your setup in sendmail 8.17.1. On the contrary, this option is still in the default config when you install 8.17.1 from scratch.

1 Like
6

At the risk of seeming rude; I have to ask if you think the documents are always 100% up to date with software changes? If so then you are out of sync with reality.

Sometimes the developers make changes and documentation may at times never be updated, or at best the doc updates lag software updates by some time.

It is obvious that some software change now caused that option to not function and the change needs to be addressed to the developers since we, as users, do not dictate those changes.

If you feel it is a bug then please report it as such. Discussion here does not encourage progress nor address the change in any way but to tell users of the change. Reporting a bug may allow a return to the original config file options (or may not) if the developers are aware of the change that affected you.

7

Thank you for pointing this out KC. I added it to my notes for when I upgrade my server next month. Please file a bug if you have time.

On a more general level, there’s growing awareness in open source communities of the need to treat documentation more seriously: that it needs to be integrated into the engineering workflow and be reviewed and tested. Recent article on the topic of Documenation as Code.

1 Like
8

I agree 100%

9

You are not rude at all and in general I agree with you. As a developer myself I can understand that writing documentation is the least favorite part of the coding process, but this is a bit different, don’t you think?

This change (if it really was intentional) breaks a running server, which has been running for years. It’s a breaking change that will render the sending functionality of a mailserver useless.

I use my mail server just for myself and a handful users, but what about ISPs?

It’s the same as you get a new car, but can’t get in. You can start the car remotely, but you can’t drive it, because the doors won’t open and you can’t pry them open either. You have to remove fuse number 13A so that the doors open. But neither the manufacturer nor the dealership ever told you that.

10

Done.

https://bugzilla.redhat.com/show_bug.cgi?id=2144614

1 Like
11

Yes, I have the same problem, my sendmail does not working after update to fedora 37, and the outgoing address will change back to 127.0.0.1, I need to check the “A” later.