#sendmail — Public Fediverse posts

How to regenerate sendmail certifcates #certificates #sendmail #tls

https://askubuntu.com/q/1565815/612

How to regenerate sendmail certifcates #configuration #lamp #certificates #sendmail #tls

https://askubuntu.com/q/1565815/612

How to regenerate sendmail certifcates #configuration #lamp #certificates #sendmail #tls

https://askubuntu.com/q/1565815/612

How to regenerate sendmail certifcates #configuration #lamp #certificates #sendmail #tls

https://askubuntu.com/q/1565815/612

smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/sender_access

smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/sender_access

smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/sender_access

I am tidying up and found my copy of the Bat Book.
I'm feeling nostalgic.
Should I install a new mail server using sendmail?
#email #sendmail #postfix #proton #proton_mail #MS365 #Google #Microsoft #GoogleWorkspace

I never ceases to amaze me that mail systems do this shit. I know it was a thing with Sendmail but most of us have moved on or at least fixed the stupid mailer flags.

#Sysadminnery #Email #Sendmail

I wondered why my local mail wasn't dragged into my mailbox.
Turns out I'd forgotten to configure sendmail to allow mail traffic from localhost/127.0.0.1.

Duh.

#linux #mail #sendmail

@ben

What if you invent a file format that has comments but isn't human readable?

Like the old sendmail.cf files.

The evidence suggests that the reverse happens and everyone else spends well over a decade in the penalty box. (-:

The fun ones are where the comments are mere side effects of throwing away all lines that don't parse properly.

Like how invalid : labels became a way to do comments in scripts for Microsoft's COMMAND/CMD.

#Sendmail #COMMAND #CMD

Wie ich bei der ersten Veröffentlichung vom Serienhelper angekündigt habe, kommt hier die HTML Ausgabe ich werde auch Zeigen wie ihr euren Linux Server dazu bringt euch regelmäßig E-Mails mit den Ergebnissen schicken zu lassen

#Cronjob #HTML #Linux #msmtp, #Sendmail #Serien #SerienHelper

https://blog.es-development.de/?p=214

@nuintari

Seeing that we've been collectively pretending that #MMDF never happened since the 1990s; where *that* had flat tables that compiled into DBM files; I suspect that it will be eventually possible to do the same for #Sendmail.

R$*<$*.>$* $1<$2>$3

You know that you have been traumatized by Sendmail if you just winced.

Or wondered how that damn modem line noise got into a FediVerse post. (-:

And when they're not in rc.conf format, they're either cap files that compile to Berkeley DB databases, or tab-separated flat tables.

We're collectively pretending that #Sendmail never happened, ne? (-:

#FreeBSD

Lol I think I managed to make it work o_O The URL I passed to the config (PDS_EMAIL_SMTP_URL) is: "smtp:///?sendmail=true" Leaving a trail for the next person: #pds #smtp #sendmail

Eric Allman: A Comprehensive Biography

Eric Paul Allman was born on September 2, 1955, in El Cerrito, California, USA. From an early age, he exhibited a keen interest in technology and engineering. This fascination eventually led him to the University of California, Berkeley, where he pursued a degree in computer science.

Read More: https://machaddr.substack.com/p/eric-allman-a-comprehensive-biography

#UNIX #OpenSource #Computer #Science #Mail #Sendmail #BSD #Berkeley

#FreeBSD 14 replaces #Sendmail with #DMA
https://klarasystems.com/articles/freebsd14-replaces-sendmail-with-dma/

Yet another night debugging email delivery problems

I’ve run my own mail server for 30+ years. It’s a pain sometimes, but I’m a stubborn old cuss and I think it’s worth it both because I value my privacy and don’t want my emails being stored on somebody else’s servers, and because I’m a sysadmin at heart and I love a good sysadmin challenge, which running a mail server definitely is.

Every once in a while the corporate email service providers come up with a new way to screw things up for small mail server operators like me. Most recently, both Proofpoint and Cisco IronPort SMTP servers started having trouble delivering emails to my server. Maybe you’ll find the explanation of why amusing, or at least maybe you’ll find the bits below about how to get sendmail to accept more TLS ciphers useful.

The behavior I was seeing was that whenever someone using Proofpoint or IronPort for their outbound email delivery attempted to send me email, it would be delayed for many hours before finally being delivered. I started digging into my sendmail logs and saw messages like this every hour:

Nov 17 00:33:33 jik4 sendmail[372431]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=esa12.hc6077-55.iphmx.com [139.138.46.199]
Nov 17 00:33:33 jik4 sendmail[372431]: 4AH5XXPf372431: esa12.hc6077-55.iphmx.com [139.138.46.199] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

My mail server runs on CentOS Stream 9, which is pretty strict about which TLS ciphers its servers accept by default. Therefore, my first theory about what was causing the delivery issues was that Proofpoint’s and IronPort’s servers are running old SSL libraries that don’t support modern, secure ciphers.

However, this raises an obvious question: if that’s true, then why were these messages eventually being delivered at all. Shouldn’t the servers just keep trying and failing to connect with their old TLS ciphers and then eventually give up? I.e., shouldn’t delivery just fail completely, rather than being delayed?

I hand-waved away this question by observing that either of the following might be true:

• Some of their servers run more modern code, so eventually one of those servers attempts to deliver the message and it works.
• They have a fallback built into their delivery pipeline, such that if a certain number of delivery attempts with TLS fail, they fall back on delivering without TLS.

Neither of these is true, and I shouldn’t have hand-waved away this question, but I’ll get to that later since I’m telling the debugging story in chronological order.

Since at this point my theory was that the problem was that Proofpoint and IronPort servers didn’t support modern SSL ciphers, I decided to try figuring out how to get my sendmail to accept a larger list of SSL ciphers. I have attempted to do this in the past and failed, but this time I decided to be more persistent.

The first problem I had to solve was how to identify which TLS ciphers were supported by the running sendmail process, so I could easily test whether my attempts to make it accept more were working. I dig around a bit online and found the tool “sslscan” which works great for this purpose: “sslscan –starttls-smtp hostname:25″. Sslscan is conveniently available for installation from Debian’s repositories.

First attempt at expanding the list of accepted ciphers: I captured the list of supported ciphers with sslscan, ran “update-crypto-policies --set LEGACY“, restarted sendmail, and tested again with sslscan. No change, unfortunately.

Next, I said to myself, “Hmm, is there some way to explicitly tell sendmail in its configuration file to accept more ciphers.” After consulting /usr/share/sendmail-cf/README and the openssl-ciphers man page, I concluded that adding “define(`confCIPHER_LIST', `ALL')dnl” to the M4 source file for my sendmail.cf, then rebuilding and reinstalling it and restarting sendmail, might yield a bigger list of supported ciphers. And indeed, sslscan confirmed that this added 5 additional supported ciphers to the original list of 12.

However, those ciphers looked mostly like the old ones, so I was pretty sure I had to go further. Next I tried using “@SECLIST=1:ALL” as the cipher list instead of just “ALL“. I suspected that this might make a difference because /etc/crypto-policies/back-ends/openssl.config starts with “@SECLIST=2:“. Alas, it didn’t help.

I tried again with “@SECLIST=0” instead of “@SECLIST=1“, and the added an additional 14 ciphers. Some of these looked quite different, so maybe this would be enough to get Proofpoint and/or IronPort to be able to deliver email? I went back to one of the websites where I knew how to trigger an email message sent to me through Proofpoint, and tried it out. No luck, still “no shared cipher” in the log.

At this point I needed another solution, so I asked myself whether I might have been wrong to hand-wave away the question of why the email messages were eventually being delivered successfully. Just allowing my brain that small amount of space to question my priors caused me to have a revelation. It suddenly occurred to me that there were other log messages related to Proofpoint and IronPort delivery fails that I had been dismissing as irrelevant which in fact where not irrelevant at all. They looked like this:

Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: timeout waiting for input from esa12.hc6077-55.iphmx.com during server cmd read
Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: lost input channel from esa12.hc6077-55.iphmx.com [139.138.46.199] to MTA after rcpt
Nov 17 14:33:44 jik4 sendmail[614551]: 4AHJH3eD614551: collect: premature EOM: Connection timed out with mx0a-001e6701.pphosted.com
Nov 17 19:15:28 jik4 sendmail[701129]: 4AI0ESSZ701129: timeout waiting for input from mx0a-001e6701.pphosted.com during server cmd read
Nov 18 06:58:18 jik4 sendmail[908302]: 4AIBvHH3908302: lost input channel from mx0a-001e6701.pphosted.com [148.163.149.215] to MTA after mail

When I first saw these messages, I just assumed they indicated that Proofpoint’s and IronPort’s servers were being stupid about something. That was a mistake. In fact, it was my server that was being stupid.

I use fail2ban configured on my server, and I have it configured to aggressively block suspicious SMTP connections. It blocks a server for an hour after a single suspicious log message from that server, and the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages shown above, that are generated after Proofpoint or IronPort attempts and fails to initiate TLS and then disconnects, count as suspicious.

So while the fact that Proofpoint and IronPort don’t support modern TLS ciphers was the root cause of the issue, my server was exacerbating the problem by banning their IP address immediately after they tried to do TLS, so that they were then unable to reconnect and deliver the message without TLS.

The reason why the messages from these servers were eventually being delivered is that there’s sometimes a 1–2 second delay between when a suspicious log message appears and when fail2ban bans the associated server IP, and after trying over and over eventually the Proofpoint or IronPort managed to sneak in a successful message delivery during that short delay.

The solution, therefore, is to make fail2ban less aggressive about banning suspicious SMTP servers. However, if I do that, then my server is much more vulnerable to brute-force SMTP authentication attacks? What to do, what to do?

Maybe there’s another suspicious log message I can match against in the logs instead of the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages which are caused innocuously when a TLS connection fails? With just a little bit of digging I found these:

Nov 21 23:07:50 jik4 sendmail[58510]: 4AM47hXh058510: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=postmaster, relay=[109.172.142.229]

Wait a minute, why the heck isn’t fail2ban banning based on this message which is obviously, unambiguously a brute-force login attempt?

Well, you see, it turns out that I originally configured fail2ban to ban based on the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages way back in 2007 (like I said, I’ve been running my own mail server for a long time), and back in 2007, the “AUTH failure” log messages did note have the “relay=” at the end of them. That wasn’t added until release sendmail 8.14.4, which was released in December 2009 (I figured out which release this was added in by doing a binary search through all of the old sendmail source archives on ftp.sendmail.org).

Putting this all together:

• One root cause of the incoming email delivery issues is Proofpoint and IronPort being stupid about which TLS ciphers they support.
• A second root cause is my fail2ban configuration being too aggressive about banning suspicious SMTP servers, resulting in servers being banned for engaging in innocuous activities.
• Configuring sendmail to accept more TLS ciphers is the wrong solution.
• The right solution, which I’ve implemented, is to make fail2ban more selective about which log messages it considers suspicious, so it won’t ban the Proofpoint and IronPort servers for failing to initiate a TLS connection.

See, now, this is actually one of the reasons I love running my own mail server: there is immense satisfaction in getting to the bottom of one of these problems and successfully solving it.

#fail2ban #IronPort #OpenSSL #Proofpoint #sendmail #SMTP #sslscan #TLS

Yet another night debugging email delivery problems

I’ve run my own mail server for 30+ years. It’s a pain sometimes, but I’m a stubborn old cuss and I think it’s worth it both because I value my privacy and don’t want my emails being stored on somebody else’s servers, and because I’m a sysadmin at heart and I love a good sysadmin challenge, which running a mail server definitely is.

Every once in a while the corporate email service providers come up with a new way to screw things up for small mail server operators like me. Most recently, both Proofpoint and Cisco IronPort SMTP servers started having trouble delivering emails to my server. Maybe you’ll find the explanation of why amusing, or at least maybe you’ll find the bits below about how to get sendmail to accept more TLS ciphers useful.

The behavior I was seeing was that whenever someone using Proofpoint or IronPort for their outbound email delivery attempted to send me email, it would be delayed for many hours before finally being delivered. I started digging into my sendmail logs and saw messages like this every hour:

Nov 17 00:33:33 jik4 sendmail[372431]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=esa12.hc6077-55.iphmx.com [139.138.46.199]
Nov 17 00:33:33 jik4 sendmail[372431]: 4AH5XXPf372431: esa12.hc6077-55.iphmx.com [139.138.46.199] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

My mail server runs on CentOS Stream 9, which is pretty strict about which TLS ciphers its servers accept by default. Therefore, my first theory about what was causing the delivery issues was that Proofpoint’s and IronPort’s servers are running old SSL libraries that don’t support modern, secure ciphers.

However, this raises an obvious question: if that’s true, then why were these messages eventually being delivered at all. Shouldn’t the servers just keep trying and failing to connect with their old TLS ciphers and then eventually give up? I.e., shouldn’t delivery just fail completely, rather than being delayed?

I hand-waved away this question by observing that either of the following might be true:

• Some of their servers run more modern code, so eventually one of those servers attempts to deliver the message and it works.
• They have a fallback built into their delivery pipeline, such that if a certain number of delivery attempts with TLS fail, they fall back on delivering without TLS.

Neither of these is true, and I shouldn’t have hand-waved away this question, but I’ll get to that later since I’m telling the debugging story in chronological order.

Since at this point my theory was that the problem was that Proofpoint and IronPort servers didn’t support modern SSL ciphers, I decided to try figuring out how to get my sendmail to accept a larger list of SSL ciphers. I have attempted to do this in the past and failed, but this time I decided to be more persistent.

The first problem I had to solve was how to identify which TLS ciphers were supported by the running sendmail process, so I could easily test whether my attempts to make it accept more were working. I dig around a bit online and found the tool “sslscan” which works great for this purpose: “sslscan –starttls-smtp hostname:25″. Sslscan is conveniently available for installation from Debian’s repositories.

First attempt at expanding the list of accepted ciphers: I captured the list of supported ciphers with sslscan, ran “update-crypto-policies --set LEGACY“, restarted sendmail, and tested again with sslscan. No change, unfortunately.

Next, I said to myself, “Hmm, is there some way to explicitly tell sendmail in its configuration file to accept more ciphers.” After consulting /usr/share/sendmail-cf/README and the openssl-ciphers man page, I concluded that adding “define(`confCIPHER_LIST', `ALL')dnl” to the M4 source file for my sendmail.cf, then rebuilding and reinstalling it and restarting sendmail, might yield a bigger list of supported ciphers. And indeed, sslscan confirmed that this added 5 additional supported ciphers to the original list of 12.

However, those ciphers looked mostly like the old ones, so I was pretty sure I had to go further. Next I tried using “@SECLIST=1:ALL” as the cipher list instead of just “ALL“. I suspected that this might make a difference because /etc/crypto-policies/back-ends/openssl.config starts with “@SECLIST=2:“. Alas, it didn’t help.

I tried again with “@SECLIST=0” instead of “@SECLIST=1“, and the added an additional 14 ciphers. Some of these looked quite different, so maybe this would be enough to get Proofpoint and/or IronPort to be able to deliver email? I went back to one of the websites where I knew how to trigger an email message sent to me through Proofpoint, and tried it out. No luck, still “no shared cipher” in the log.

At this point I needed another solution, so I asked myself whether I might have been wrong to hand-wave away the question of why the email messages were eventually being delivered successfully. Just allowing my brain that small amount of space to question my priors caused me to have a revelation. It suddenly occurred to me that there were other log messages related to Proofpoint and IronPort delivery fails that I had been dismissing as irrelevant which in fact where not irrelevant at all. They looked like this:

Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: timeout waiting for input from esa12.hc6077-55.iphmx.com during server cmd read
Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: lost input channel from esa12.hc6077-55.iphmx.com [139.138.46.199] to MTA after rcpt
Nov 17 14:33:44 jik4 sendmail[614551]: 4AHJH3eD614551: collect: premature EOM: Connection timed out with mx0a-001e6701.pphosted.com
Nov 17 19:15:28 jik4 sendmail[701129]: 4AI0ESSZ701129: timeout waiting for input from mx0a-001e6701.pphosted.com during server cmd read
Nov 18 06:58:18 jik4 sendmail[908302]: 4AIBvHH3908302: lost input channel from mx0a-001e6701.pphosted.com [148.163.149.215] to MTA after mail

When I first saw these messages, I just assumed they indicated that Proofpoint’s and IronPort’s servers were being stupid about something. That was a mistake. In fact, it was my server that was being stupid.

I use fail2ban configured on my server, and I have it configured to aggressively block suspicious SMTP connections. It blocks a server for an hour after a single suspicious log message from that server, and the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages shown above, that are generated after Proofpoint or IronPort attempts and fails to initiate TLS and then disconnects, count as suspicious.

So while the fact that Proofpoint and IronPort don’t support modern TLS ciphers was the root cause of the issue, my server was exacerbating the problem by banning their IP address immediately after they tried to do TLS, so that they were then unable to reconnect and deliver the message without TLS.

The reason why the messages from these servers were eventually being delivered is that there’s sometimes a 1–2 second delay between when a suspicious log message appears and when fail2ban bans the associated server IP, and after trying over and over eventually the Proofpoint or IronPort managed to sneak in a successful message delivery during that short delay.

The solution, therefore, is to make fail2ban less aggressive about banning suspicious SMTP servers. However, if I do that, then my server is much more vulnerable to brute-force SMTP authentication attacks? What to do, what to do?

Maybe there’s another suspicious log message I can match against in the logs instead of the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages which are caused innocuously when a TLS connection fails? With just a little bit of digging I found these:

Nov 21 23:07:50 jik4 sendmail[58510]: 4AM47hXh058510: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=postmaster, relay=[109.172.142.229]

Wait a minute, why the heck isn’t fail2ban banning based on this message which is obviously, unambiguously a brute-force login attempt?

Well, you see, it turns out that I originally configured fail2ban to ban based on the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages way back in 2007 (like I said, I’ve been running my own mail server for a long time), and back in 2007, the “AUTH failure” log messages did note have the “relay=” at the end of them. That wasn’t added until release sendmail 8.14.4, which was released in December 2009 (I figured out which release this was added in by doing a binary search through all of the old sendmail source archives on ftp.sendmail.org).

Putting this all together:

• One root cause of the incoming email delivery issues is Proofpoint and IronPort being stupid about which TLS ciphers they support.
• A second root cause is my fail2ban configuration being too aggressive about banning suspicious SMTP servers, resulting in servers being banned for engaging in innocuous activities.
• Configuring sendmail to accept more TLS ciphers is the wrong solution.
• The right solution, which I’ve implemented, is to make fail2ban more selective about which log messages it considers suspicious, so it won’t ban the Proofpoint and IronPort servers for failing to initiate a TLS connection.

See, now, this is actually one of the reasons I love running my own mail server: there is immense satisfaction in getting to the bottom of one of these problems and successfully solving it.

#fail2ban #IronPort #OpenSSL #Proofpoint #sendmail #SMTP #sslscan #TLS

Yet another night debugging email delivery problems

I’ve run my own mail server for 30+ years. It’s a pain sometimes, but I’m a stubborn old cuss and I think it’s worth it both because I value my privacy and don’t want my emails being stored on somebody else’s servers, and because I’m a sysadmin at heart and I love a good sysadmin challenge, which running a mail server definitely is.

Every once in a while the corporate email service providers come up with a new way to screw things up for small mail server operators like me. Most recently, both Proofpoint and Cisco IronPort SMTP servers started having trouble delivering emails to my server. Maybe you’ll find the explanation of why amusing, or at least maybe you’ll find the bits below about how to get sendmail to accept more TLS ciphers useful.

The behavior I was seeing was that whenever someone using Proofpoint or IronPort for their outbound email delivery attempted to send me email, it would be delayed for many hours before finally being delivered. I started digging into my sendmail logs and saw messages like this every hour:

Nov 17 00:33:33 jik4 sendmail[372431]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=esa12.hc6077-55.iphmx.com [139.138.46.199]
Nov 17 00:33:33 jik4 sendmail[372431]: 4AH5XXPf372431: esa12.hc6077-55.iphmx.com [139.138.46.199] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

My mail server runs on CentOS Stream 9, which is pretty strict about which TLS ciphers its servers accept by default. Therefore, my first theory about what was causing the delivery issues was that Proofpoint’s and IronPort’s servers are running old SSL libraries that don’t support modern, secure ciphers.

However, this raises an obvious question: if that’s true, then why were these messages eventually being delivered at all. Shouldn’t the servers just keep trying and failing to connect with their old TLS ciphers and then eventually give up? I.e., shouldn’t delivery just fail completely, rather than being delayed?

I hand-waved away this question by observing that either of the following might be true:

• Some of their servers run more modern code, so eventually one of those servers attempts to deliver the message and it works.
• They have a fallback built into their delivery pipeline, such that if a certain number of delivery attempts with TLS fail, they fall back on delivering without TLS.

Neither of these is true, and I shouldn’t have hand-waved away this question, but I’ll get to that later since I’m telling the debugging story in chronological order.

Since at this point my theory was that the problem was that Proofpoint and IronPort servers didn’t support modern SSL ciphers, I decided to try figuring out how to get my sendmail to accept a larger list of SSL ciphers. I have attempted to do this in the past and failed, but this time I decided to be more persistent.

The first problem I had to solve was how to identify which TLS ciphers were supported by the running sendmail process, so I could easily test whether my attempts to make it accept more were working. I dig around a bit online and found the tool “sslscan” which works great for this purpose: “sslscan –starttls-smtp hostname:25″. Sslscan is conveniently available for installation from Debian’s repositories.

First attempt at expanding the list of accepted ciphers: I captured the list of supported ciphers with sslscan, ran “update-crypto-policies --set LEGACY“, restarted sendmail, and tested again with sslscan. No change, unfortunately.

Next, I said to myself, “Hmm, is there some way to explicitly tell sendmail in its configuration file to accept more ciphers.” After consulting /usr/share/sendmail-cf/README and the openssl-ciphers man page, I concluded that adding “define(`confCIPHER_LIST', `ALL')dnl” to the M4 source file for my sendmail.cf, then rebuilding and reinstalling it and restarting sendmail, might yield a bigger list of supported ciphers. And indeed, sslscan confirmed that this added 5 additional supported ciphers to the original list of 12.

However, those ciphers looked mostly like the old ones, so I was pretty sure I had to go further. Next I tried using “@SECLIST=1:ALL” as the cipher list instead of just “ALL“. I suspected that this might make a difference because /etc/crypto-policies/back-ends/openssl.config starts with “@SECLIST=2:“. Alas, it didn’t help.

I tried again with “@SECLIST=0” instead of “@SECLIST=1“, and the added an additional 14 ciphers. Some of these looked quite different, so maybe this would be enough to get Proofpoint and/or IronPort to be able to deliver email? I went back to one of the websites where I knew how to trigger an email message sent to me through Proofpoint, and tried it out. No luck, still “no shared cipher” in the log.

At this point I needed another solution, so I asked myself whether I might have been wrong to hand-wave away the question of why the email messages were eventually being delivered successfully. Just allowing my brain that small amount of space to question my priors caused me to have a revelation. It suddenly occurred to me that there were other log messages related to Proofpoint and IronPort delivery fails that I had been dismissing as irrelevant which in fact where not irrelevant at all. They looked like this:

Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: timeout waiting for input from esa12.hc6077-55.iphmx.com during server cmd read
Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: lost input channel from esa12.hc6077-55.iphmx.com [139.138.46.199] to MTA after rcpt
Nov 17 14:33:44 jik4 sendmail[614551]: 4AHJH3eD614551: collect: premature EOM: Connection timed out with mx0a-001e6701.pphosted.com
Nov 17 19:15:28 jik4 sendmail[701129]: 4AI0ESSZ701129: timeout waiting for input from mx0a-001e6701.pphosted.com during server cmd read
Nov 18 06:58:18 jik4 sendmail[908302]: 4AIBvHH3908302: lost input channel from mx0a-001e6701.pphosted.com [148.163.149.215] to MTA after mail

When I first saw these messages, I just assumed they indicated that Proofpoint’s and IronPort’s servers were being stupid about something. That was a mistake. In fact, it was my server that was being stupid.

I use fail2ban configured on my server, and I have it configured to aggressively block suspicious SMTP connections. It blocks a server for an hour after a single suspicious log message from that server, and the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages shown above, that are generated after Proofpoint or IronPort attempts and fails to initiate TLS and then disconnects, count as suspicious.

So while the fact that Proofpoint and IronPort don’t support modern TLS ciphers was the root cause of the issue, my server was exacerbating the problem by banning their IP address immediately after they tried to do TLS, so that they were then unable to reconnect and deliver the message without TLS.

The reason why the messages from these servers were eventually being delivered is that there’s sometimes a 1–2 second delay between when a suspicious log message appears and when fail2ban bans the associated server IP, and after trying over and over eventually the Proofpoint or IronPort managed to sneak in a successful message delivery during that short delay.

The solution, therefore, is to make fail2ban less aggressive about banning suspicious SMTP servers. However, if I do that, then my server is much more vulnerable to brute-force SMTP authentication attacks? What to do, what to do?

Maybe there’s another suspicious log message I can match against in the logs instead of the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages which are caused innocuously when a TLS connection fails? With just a little bit of digging I found these:

Nov 21 23:07:50 jik4 sendmail[58510]: 4AM47hXh058510: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=postmaster, relay=[109.172.142.229]

Wait a minute, why the heck isn’t fail2ban banning based on this message which is obviously, unambiguously a brute-force login attempt?

Well, you see, it turns out that I originally configured fail2ban to ban based on the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages way back in 2007 (like I said, I’ve been running my own mail server for a long time), and back in 2007, the “AUTH failure” log messages did note have the “relay=” at the end of them. That wasn’t added until release sendmail 8.14.4, which was released in December 2009 (I figured out which release this was added in by doing a binary search through all of the old sendmail source archives on ftp.sendmail.org).

Putting this all together:

• One root cause of the incoming email delivery issues is Proofpoint and IronPort being stupid about which TLS ciphers they support.
• A second root cause is my fail2ban configuration being too aggressive about banning suspicious SMTP servers, resulting in servers being banned for engaging in innocuous activities.
• Configuring sendmail to accept more TLS ciphers is the wrong solution.
• The right solution, which I’ve implemented, is to make fail2ban more selective about which log messages it considers suspicious, so it won’t ban the Proofpoint and IronPort servers for failing to initiate a TLS connection.

See, now, this is actually one of the reasons I love running my own mail server: there is immense satisfaction in getting to the bottom of one of these problems and successfully solving it.

#fail2ban #IronPort #OpenSSL #Proofpoint #sendmail #SMTP #sslscan #TLS

Yet another night debugging email delivery problems

I’ve run my own mail server for 30+ years. It’s a pain sometimes, but I’m a stubborn old cuss and I think it’s worth it both because I value my privacy and don’t want my emails being stored on somebody else’s servers, and because I’m a sysadmin at heart and I love a good sysadmin challenge, which running a mail server definitely is.

Every once in a while the corporate email service providers come up with a new way to screw things up for small mail server operators like me. Most recently, both Proofpoint and Cisco IronPort SMTP servers started having trouble delivering emails to my server. Maybe you’ll find the explanation of why amusing, or at least maybe you’ll find the bits below about how to get sendmail to accept more TLS ciphers useful.

The behavior I was seeing was that whenever someone using Proofpoint or IronPort for their outbound email delivery attempted to send me email, it would be delayed for many hours before finally being delivered. I started digging into my sendmail logs and saw messages like this every hour:

Nov 17 00:33:33 jik4 sendmail[372431]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=esa12.hc6077-55.iphmx.com [139.138.46.199]
Nov 17 00:33:33 jik4 sendmail[372431]: 4AH5XXPf372431: esa12.hc6077-55.iphmx.com [139.138.46.199] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

My mail server runs on CentOS Stream 9, which is pretty strict about which TLS ciphers its servers accept by default. Therefore, my first theory about what was causing the delivery issues was that Proofpoint’s and IronPort’s servers are running old SSL libraries that don’t support modern, secure ciphers.

However, this raises an obvious question: if that’s true, then why were these messages eventually being delivered at all. Shouldn’t the servers just keep trying and failing to connect with their old TLS ciphers and then eventually give up? I.e., shouldn’t delivery just fail completely, rather than being delayed?

I hand-waved away this question by observing that either of the following might be true:

• Some of their servers run more modern code, so eventually one of those servers attempts to deliver the message and it works.
• They have a fallback built into their delivery pipeline, such that if a certain number of delivery attempts with TLS fail, they fall back on delivering without TLS.

Neither of these is true, and I shouldn’t have hand-waved away this question, but I’ll get to that later since I’m telling the debugging story in chronological order.

Since at this point my theory was that the problem was that Proofpoint and IronPort servers didn’t support modern SSL ciphers, I decided to try figuring out how to get my sendmail to accept a larger list of SSL ciphers. I have attempted to do this in the past and failed, but this time I decided to be more persistent.

The first problem I had to solve was how to identify which TLS ciphers were supported by the running sendmail process, so I could easily test whether my attempts to make it accept more were working. I dig around a bit online and found the tool “sslscan” which works great for this purpose: “sslscan –starttls-smtp hostname:25″. Sslscan is conveniently available for installation from Debian’s repositories.

First attempt at expanding the list of accepted ciphers: I captured the list of supported ciphers with sslscan, ran “update-crypto-policies --set LEGACY“, restarted sendmail, and tested again with sslscan. No change, unfortunately.

Next, I said to myself, “Hmm, is there some way to explicitly tell sendmail in its configuration file to accept more ciphers.” After consulting /usr/share/sendmail-cf/README and the openssl-ciphers man page, I concluded that adding “define(`confCIPHER_LIST', `ALL')dnl” to the M4 source file for my sendmail.cf, then rebuilding and reinstalling it and restarting sendmail, might yield a bigger list of supported ciphers. And indeed, sslscan confirmed that this added 5 additional supported ciphers to the original list of 12.

However, those ciphers looked mostly like the old ones, so I was pretty sure I had to go further. Next I tried using “@SECLIST=1:ALL” as the cipher list instead of just “ALL“. I suspected that this might make a difference because /etc/crypto-policies/back-ends/openssl.config starts with “@SECLIST=2:“. Alas, it didn’t help.

I tried again with “@SECLIST=0” instead of “@SECLIST=1“, and the added an additional 14 ciphers. Some of these looked quite different, so maybe this would be enough to get Proofpoint and/or IronPort to be able to deliver email? I went back to one of the websites where I knew how to trigger an email message sent to me through Proofpoint, and tried it out. No luck, still “no shared cipher” in the log.

At this point I needed another solution, so I asked myself whether I might have been wrong to hand-wave away the question of why the email messages were eventually being delivered successfully. Just allowing my brain that small amount of space to question my priors caused me to have a revelation. It suddenly occurred to me that there were other log messages related to Proofpoint and IronPort delivery fails that I had been dismissing as irrelevant which in fact where not irrelevant at all. They looked like this:

Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: timeout waiting for input from esa12.hc6077-55.iphmx.com during server cmd read
Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: lost input channel from esa12.hc6077-55.iphmx.com [139.138.46.199] to MTA after rcpt
Nov 17 14:33:44 jik4 sendmail[614551]: 4AHJH3eD614551: collect: premature EOM: Connection timed out with mx0a-001e6701.pphosted.com
Nov 17 19:15:28 jik4 sendmail[701129]: 4AI0ESSZ701129: timeout waiting for input from mx0a-001e6701.pphosted.com during server cmd read
Nov 18 06:58:18 jik4 sendmail[908302]: 4AIBvHH3908302: lost input channel from mx0a-001e6701.pphosted.com [148.163.149.215] to MTA after mail

When I first saw these messages, I just assumed they indicated that Proofpoint’s and IronPort’s servers were being stupid about something. That was a mistake. In fact, it was my server that was being stupid.

I use fail2ban configured on my server, and I have it configured to aggressively block suspicious SMTP connections. It blocks a server for an hour after a single suspicious log message from that server, and the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages shown above, that are generated after Proofpoint or IronPort attempts and fails to initiate TLS and then disconnects, count as suspicious.

So while the fact that Proofpoint and IronPort don’t support modern TLS ciphers was the root cause of the issue, my server was exacerbating the problem by banning their IP address immediately after they tried to do TLS, so that they were then unable to reconnect and deliver the message without TLS.

The reason why the messages from these servers were eventually being delivered is that there’s sometimes a 1–2 second delay between when a suspicious log message appears and when fail2ban bans the associated server IP, and after trying over and over eventually the Proofpoint or IronPort managed to sneak in a successful message delivery during that short delay.

The solution, therefore, is to make fail2ban less aggressive about banning suspicious SMTP servers. However, if I do that, then my server is much more vulnerable to brute-force SMTP authentication attacks? What to do, what to do?

Maybe there’s another suspicious log message I can match against in the logs instead of the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages which are caused innocuously when a TLS connection fails? With just a little bit of digging I found these:

Nov 21 23:07:50 jik4 sendmail[58510]: 4AM47hXh058510: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=postmaster, relay=[109.172.142.229]

Wait a minute, why the heck isn’t fail2ban banning based on this message which is obviously, unambiguously a brute-force login attempt?

Well, you see, it turns out that I originally configured fail2ban to ban based on the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages way back in 2007 (like I said, I’ve been running my own mail server for a long time), and back in 2007, the “AUTH failure” log messages did note have the “relay=” at the end of them. That wasn’t added until release sendmail 8.14.4, which was released in December 2009 (I figured out which release this was added in by doing a binary search through all of the old sendmail source archives on ftp.sendmail.org).

Putting this all together:

• One root cause of the incoming email delivery issues is Proofpoint and IronPort being stupid about which TLS ciphers they support.
• A second root cause is my fail2ban configuration being too aggressive about banning suspicious SMTP servers, resulting in servers being banned for engaging in innocuous activities.
• Configuring sendmail to accept more TLS ciphers is the wrong solution.
• The right solution, which I’ve implemented, is to make fail2ban more selective about which log messages it considers suspicious, so it won’t ban the Proofpoint and IronPort servers for failing to initiate a TLS connection.

See, now, this is actually one of the reasons I love running my own mail server: there is immense satisfaction in getting to the bottom of one of these problems and successfully solving it.

#fail2ban #IronPort #OpenSSL #Proofpoint #sendmail #SMTP #sslscan #TLS

Yet another night debugging email delivery problems

I’ve run my own mail server for 30+ years. It’s a pain sometimes, but I’m a stubborn old cuss and I think it’s worth it both because I value my privacy and don’t want my emails being stored on somebody else’s servers, and because I’m a sysadmin at heart and I love a good sysadmin challenge, which running a mail server definitely is.

Every once in a while the corporate email service providers come up with a new way to screw things up for small mail server operators like me. Most recently, both Proofpoint and Cisco IronPort SMTP servers started having trouble delivering emails to my server. Maybe you’ll find the explanation of why amusing, or at least maybe you’ll find the bits below about how to get sendmail to accept more TLS ciphers useful.

The behavior I was seeing was that whenever someone using Proofpoint or IronPort for their outbound email delivery attempted to send me email, it would be delayed for many hours before finally being delivered. I started digging into my sendmail logs and saw messages like this every hour:

Nov 17 00:33:33 jik4 sendmail[372431]: STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1, errno=0, retry=-1, relay=esa12.hc6077-55.iphmx.com [139.138.46.199]
Nov 17 00:33:33 jik4 sendmail[372431]: 4AH5XXPf372431: esa12.hc6077-55.iphmx.com [139.138.46.199] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

My mail server runs on CentOS Stream 9, which is pretty strict about which TLS ciphers its servers accept by default. Therefore, my first theory about what was causing the delivery issues was that Proofpoint’s and IronPort’s servers are running old SSL libraries that don’t support modern, secure ciphers.

However, this raises an obvious question: if that’s true, then why were these messages eventually being delivered at all. Shouldn’t the servers just keep trying and failing to connect with their old TLS ciphers and then eventually give up? I.e., shouldn’t delivery just fail completely, rather than being delayed?

I hand-waved away this question by observing that either of the following might be true:

• Some of their servers run more modern code, so eventually one of those servers attempts to deliver the message and it works.
• They have a fallback built into their delivery pipeline, such that if a certain number of delivery attempts with TLS fail, they fall back on delivering without TLS.

Neither of these is true, and I shouldn’t have hand-waved away this question, but I’ll get to that later since I’m telling the debugging story in chronological order.

Since at this point my theory was that the problem was that Proofpoint and IronPort servers didn’t support modern SSL ciphers, I decided to try figuring out how to get my sendmail to accept a larger list of SSL ciphers. I have attempted to do this in the past and failed, but this time I decided to be more persistent.

The first problem I had to solve was how to identify which TLS ciphers were supported by the running sendmail process, so I could easily test whether my attempts to make it accept more were working. I dig around a bit online and found the tool “sslscan” which works great for this purpose: “sslscan –starttls-smtp hostname:25″. Sslscan is conveniently available for installation from Debian’s repositories.

First attempt at expanding the list of accepted ciphers: I captured the list of supported ciphers with sslscan, ran “update-crypto-policies --set LEGACY“, restarted sendmail, and tested again with sslscan. No change, unfortunately.

Next, I said to myself, “Hmm, is there some way to explicitly tell sendmail in its configuration file to accept more ciphers.” After consulting /usr/share/sendmail-cf/README and the openssl-ciphers man page, I concluded that adding “define(`confCIPHER_LIST', `ALL')dnl” to the M4 source file for my sendmail.cf, then rebuilding and reinstalling it and restarting sendmail, might yield a bigger list of supported ciphers. And indeed, sslscan confirmed that this added 5 additional supported ciphers to the original list of 12.

However, those ciphers looked mostly like the old ones, so I was pretty sure I had to go further. Next I tried using “@SECLIST=1:ALL” as the cipher list instead of just “ALL“. I suspected that this might make a difference because /etc/crypto-policies/back-ends/openssl.config starts with “@SECLIST=2:“. Alas, it didn’t help.

I tried again with “@SECLIST=0” instead of “@SECLIST=1“, and the added an additional 14 ciphers. Some of these looked quite different, so maybe this would be enough to get Proofpoint and/or IronPort to be able to deliver email? I went back to one of the websites where I knew how to trigger an email message sent to me through Proofpoint, and tried it out. No luck, still “no shared cipher” in the log.

At this point I needed another solution, so I asked myself whether I might have been wrong to hand-wave away the question of why the email messages were eventually being delivered successfully. Just allowing my brain that small amount of space to question my priors caused me to have a revelation. It suddenly occurred to me that there were other log messages related to Proofpoint and IronPort delivery fails that I had been dismissing as irrelevant which in fact where not irrelevant at all. They looked like this:

Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: timeout waiting for input from esa12.hc6077-55.iphmx.com during server cmd read
Nov 17 00:34:34 jik4 sendmail[372437]: 4AH5XXIZ372437: lost input channel from esa12.hc6077-55.iphmx.com [139.138.46.199] to MTA after rcpt
Nov 17 14:33:44 jik4 sendmail[614551]: 4AHJH3eD614551: collect: premature EOM: Connection timed out with mx0a-001e6701.pphosted.com
Nov 17 19:15:28 jik4 sendmail[701129]: 4AI0ESSZ701129: timeout waiting for input from mx0a-001e6701.pphosted.com during server cmd read
Nov 18 06:58:18 jik4 sendmail[908302]: 4AIBvHH3908302: lost input channel from mx0a-001e6701.pphosted.com [148.163.149.215] to MTA after mail

When I first saw these messages, I just assumed they indicated that Proofpoint’s and IronPort’s servers were being stupid about something. That was a mistake. In fact, it was my server that was being stupid.

I use fail2ban configured on my server, and I have it configured to aggressively block suspicious SMTP connections. It blocks a server for an hour after a single suspicious log message from that server, and the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages shown above, that are generated after Proofpoint or IronPort attempts and fails to initiate TLS and then disconnects, count as suspicious.

So while the fact that Proofpoint and IronPort don’t support modern TLS ciphers was the root cause of the issue, my server was exacerbating the problem by banning their IP address immediately after they tried to do TLS, so that they were then unable to reconnect and deliver the message without TLS.

The reason why the messages from these servers were eventually being delivered is that there’s sometimes a 1–2 second delay between when a suspicious log message appears and when fail2ban bans the associated server IP, and after trying over and over eventually the Proofpoint or IronPort managed to sneak in a successful message delivery during that short delay.

The solution, therefore, is to make fail2ban less aggressive about banning suspicious SMTP servers. However, if I do that, then my server is much more vulnerable to brute-force SMTP authentication attacks? What to do, what to do?

Maybe there’s another suspicious log message I can match against in the logs instead of the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages which are caused innocuously when a TLS connection fails? With just a little bit of digging I found these:

Nov 21 23:07:50 jik4 sendmail[58510]: 4AM47hXh058510: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=postmaster, relay=[109.172.142.229]

Wait a minute, why the heck isn’t fail2ban banning based on this message which is obviously, unambiguously a brute-force login attempt?

Well, you see, it turns out that I originally configured fail2ban to ban based on the “did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA” messages way back in 2007 (like I said, I’ve been running my own mail server for a long time), and back in 2007, the “AUTH failure” log messages did note have the “relay=” at the end of them. That wasn’t added until release sendmail 8.14.4, which was released in December 2009 (I figured out which release this was added in by doing a binary search through all of the old sendmail source archives on ftp.sendmail.org).

Putting this all together:

• One root cause of the incoming email delivery issues is Proofpoint and IronPort being stupid about which TLS ciphers they support.
• A second root cause is my fail2ban configuration being too aggressive about banning suspicious SMTP servers, resulting in servers being banned for engaging in innocuous activities.
• Configuring sendmail to accept more TLS ciphers is the wrong solution.
• The right solution, which I’ve implemented, is to make fail2ban more selective about which log messages it considers suspicious, so it won’t ban the Proofpoint and IronPort servers for failing to initiate a TLS connection.

See, now, this is actually one of the reasons I love running my own mail server: there is immense satisfaction in getting to the bottom of one of these problems and successfully solving it.

#fail2ban #IronPort #OpenSSL #Proofpoint #sendmail #SMTP #sslscan #TLS

@jwz

This joke's Venn diagram has a vanishingly-thin intersection.

#venn #VennDiagram #sendmail #ffmpeg

It's weird that you have to employ dirty stunts to make #Postfix log a message's subject...

To do it, you need to enable "header_checks" with an INFO action for the "Subject:" header.

Why, oh why, can it *not* be as simple as with #Exim, where you can enable dozens of additional fields to be logged?!

It feels like Postfix is a tool from the past... Not as old as #Sendmail maybe, which I also had the "pleasure" to work with many, many years ago, but still...

#SMTP #MTA #email

Default MTA: The default Mail Transport Agent (MTA) is now the Dragonfly Mail Agent (dma(8)), replacing sendmail(8). This change simplifies mail configuration and management. Configuration is handled through mailer.conf(5), and sendmail(8) is still available for those who need it. Additionally, the mta_start_script configuration variable has been retired from rc.conf(5) along with the othermta startup script​​.
Good bye #Sendmail I miss you my old friend.

#FreeBSD FreeBSD 14.1-RELEASE

@kjhealy me today with #sendmail and directory permissions.

Regarding the #xz backdoor Jonathan Corbet from https://lwn.net/ thinks that #autoconf is part of the problem: "Why are we still using ancient build systems that almost nobody understands?"
So do I. I have not been using #sendmail for decades which used to have the same #m4 bullshit.

Who's making a LLM-based spam filter plugin for #Spamassassin or #Rspamd?

Gmail has advanced AI-based filtering. Now that LLMs are becoming democratized, I'm ready for a self-hosted AI spam filter.

It seems much more popular to publish research papers on the viability of LLM-based spam filtering than it is to build LLM-based spam filtering software. Here are dozens of papers: https://www.arxiv-sanity-lite.com/?rank=pid&pid=2206.02443 Nothing on GitHub, yet.

#llm #ai #spam #phishing #SelfHosting #postfix #exim #sendmail #qmail

Who's making a LLM-based spam filter plugin for #Spamassassin or #Rspamd?

Gmail has advanced AI-based filtering. Now that LLMs are becoming democratized, I'm ready for a self-hosted AI spam filter.

It seems much more popular to publish research papers on the viability of LLM-based spam filtering than it is to build LLM-based spam filtering software. Here are dozens of papers: https://www.arxiv-sanity-lite.com/?rank=pid&pid=2206.02443 Nothing on GitHub, yet.

#llm #ai #spam #phishing #SelfHosting #postfix #exim #sendmail #qmail

Who's making a LLM-based spam filter plugin for #Spamassassin or #Rspamd?

Gmail has advanced AI-based filtering. Now that LLMs are becoming democratized, I'm ready for a self-hosted AI spam filter.

It seems much more popular to publish research papers on the viability of LLM-based spam filtering than it is to build LLM-based spam filtering software. Here are dozens of papers: https://www.arxiv-sanity-lite.com/?rank=pid&pid=2206.02443 Nothing on GitHub, yet.

#llm #ai #spam #phishing #SelfHosting #postfix #exim #sendmail #qmail

Who's making a LLM-based spam filter plugin for #Spamassassin or #Rspamd?

Gmail has advanced AI-based filtering. Now that LLMs are becoming democratized, I'm ready for a self-hosted AI spam filter.

It seems much more popular to publish research papers on the viability of LLM-based spam filtering than it is to build LLM-based spam filtering software. Here are dozens of papers: https://www.arxiv-sanity-lite.com/?rank=pid&pid=2206.02443 Nothing on GitHub, yet.

#llm #ai #spam #phishing #SelfHosting #postfix #exim #sendmail #qmail

Who's making a LLM-based spam filter plugin for #Spamassassin or #Rspamd?

Gmail has advanced AI-based filtering. Now that LLMs are becoming democratized, I'm ready for a self-hosted AI spam filter.

It seems much more popular to publish research papers on the viability of LLM-based spam filtering than it is to build LLM-based spam filtering software. Here are dozens of papers: https://www.arxiv-sanity-lite.com/?rank=pid&pid=2206.02443 Nothing on GitHub, yet.

#llm #ai #spam #phishing #SelfHosting #postfix #exim #sendmail #qmail

@cstross @marjolica

Since you mention Xenix, here's a couple of interesting historical tidbits:

One of the ironies of history is that #MMDF, which SCO Xenix had instead of #Sendmail, would have been far more popular had it been around just a decade later.

It's also interesting that if one is writing stuff for a virtual terminal on FreeBSD, one still has traces of Xenix around. The keymap(5) file format is much the same as the #Xenix one.

@Kensan I use #sendmail with #SASL and for stronger auth I use my own #Kerberos

One of my #GitLab instances was no longer able to send e-mails. (It tried to send almost empty e-mails, but its smarthost discarded those.)

It was the one that used #nullmailer as its #MTA. GitLab recommends either #Sendmail or #Postfix as an MTA. Switching to Postfix solved this issue for me.

Making sure that Postfix uses the #StartTLS capability of its smarthost took longer than expected.

It's also rather annoying that on Debian systems, postfix by default accepts connections from anywhere on the Internet even though I asked debconf to set up a “satellite system”.

When using Nullmailer, I just had to put the line “smtp.domain.tld smtp --port=25 --starttls” in /etc/nullmailer/remotes.

For Postfix, I need this:
inet_interfaces = loopback-only
smtp_tls_security_level = encrypt

Your mileage may vary.

@Anarcat: When I read https://packages.debian.org/sid/rsendmail I expected it to be a replacement for my local #MTA which instead does ssh into another box with a fullblown MTA and calls #sendmail there. But https://gitlab.com/anarcat/rsendmail/-/blob/main/README.md makes it sound much more complex and way less obvious.

Why do I need #rsendmail on the remote host? Why doesn't it conflict with my local MTA? What's the real benefit over `nullmailer`? You write "#nullmailer is almost what we need, but still talks #SMTP" — but what's bad about that?

@Anarcat: When I read https://packages.debian.org/sid/rsendmail I expected it to be a replacement for my local #MTA which instead does ssh into another box with a fullblown MTA and calls #sendmail there. But https://gitlab.com/anarcat/rsendmail/-/blob/main/README.md makes it sound much more complex and way less obvious.

Why do I need #rsendmail on the remote host? Why doesn't it conflict with my local MTA? What's the real benefit over `nullmailer`? You write "#nullmailer is almost what we need, but still talks #SMTP" — but what's bad about that?

@Anarcat: When I read https://packages.debian.org/sid/rsendmail I expected it to be a replacement for my local #MTA which instead does ssh into another box with a fullblown MTA and calls #sendmail there. But https://gitlab.com/anarcat/rsendmail/-/blob/main/README.md makes it sound much more complex and way less obvious.

Why do I need #rsendmail on the remote host? Why doesn't it conflict with my local MTA? What's the real benefit over `nullmailer`? You write "#nullmailer is almost what we need, but still talks #SMTP" — but what's bad about that?

@Anarcat: When I read https://packages.debian.org/sid/rsendmail I expected it to be a replacement for my local #MTA which instead does ssh into another box with a fullblown MTA and calls #sendmail there. But https://gitlab.com/anarcat/rsendmail/-/blob/main/README.md makes it sound much more complex and way less obvious.

Why do I need #rsendmail on the remote host? Why doesn't it conflict with my local MTA? What's the real benefit over `nullmailer`? You write "#nullmailer is almost what we need, but still talks #SMTP" — but what's bad about that?

@Anarcat: When I read https://packages.debian.org/sid/rsendmail I expected it to be a replacement for my local #MTA which instead does ssh into another box with a fullblown MTA and calls #sendmail there. But https://gitlab.com/anarcat/rsendmail/-/blob/main/README.md makes it sound much more complex and way less obvious.

Why do I need #rsendmail on the remote host? Why doesn't it conflict with my local MTA? What's the real benefit over `nullmailer`? You write "#nullmailer is almost what we need, but still talks #SMTP" — but what's bad about that?

One of my #GitLab instances was no longer able to send e-mails. (It tried to send almost empty e-mails, but its smarthost discarded those.)

It was the one that used #nullmailer as its #MTA. GitLab recommends either #Sendmail or #Postfix as an MTA. Switching to Postfix solved this issue for me.

Making sure that Postfix uses the #StartTLS capability of its smarthost took longer than expected.

It's also rather annoying that on Debian systems, postfix by default accepts connections from anywhere on the Internet even though I asked debconf to set up a “satellite system”.

When using Nullmailer, I just had to put the line “smtp.domain.tld smtp --port=25 --starttls” in /etc/nullmailer/remotes.

For Postfix, I need this:
inet_interfaces = loopback-only
smtp_tls_security_level = encrypt

Your mileage may vary.

One of my #GitLab instances was no longer able to send e-mails. (It tried to send almost empty e-mails, but its smarthost discarded those.)

It was the one that used #nullmailer as its #MTA. GitLab recommends either #Sendmail or #Postfix as an MTA. Switching to Postfix solved this issue for me.

Making sure that Postfix uses the #StartTLS capability of its smarthost took longer than expected.

It's also rather annoying that on Debian systems, postfix by default accepts connections from anywhere on the Internet even though I asked debconf to set up a “satellite system”.

When using Nullmailer, I just had to put the line “smtp.domain.tld smtp --port=25 --starttls” in /etc/nullmailer/remotes.

For Postfix, I need this:
inet_interfaces = loopback-only
smtp_tls_security_level = encrypt

Your mileage may vary.