Hello OpenSuSE Lister's - I think I have encountered a change on BSD Sendmail's behavior (version 8.15.2-150000.8.9.1) that coincides with upgrading OpenSuSE 15.4. I want to run sendmail on some systems that are running another MTA also (such as Apache James, Axigen) For many many moons of OpenSuSE releases, I accomplish this feat by turning off the running of sendmail in daemon mode. That is accomplished by NOT including the -bd parameter for sendmail when starting the systemd sendmail service. This effectively turns off the ability for sendmail to listen for incoming connection request on port 25. But this configuration did not stop sendmail from sending emails for clients such as clamd, cron, etc., which use sendmail internally to send emails as needed. And it did not cause a conflict of the usage of port 25 between sendmail and another MTA. As of OpenSuSE15.4 the ability of sendmail to send emails, and not receive them is broken. Trying to send an email (via localhost) - such as the following test - echo "Subject: sendmail test from Quasar" | sendmail -v marc@marcchamberlin.com results in the following useless and misleading error message - marc@marcchamberlin.com... Connecting to [127.0.0.1] port 25 via relay... marc@marcchamberlin.com... Deferred: Connection refused by [127.0.0.1] I tried exploring firewalld, routes, dhcpd and other network tools all to no joy. The one thing I have found, that will work and get sendmail to send email messages, is to restore the -bd parameter, which up to 15.4 has never affected sendmail's ability to send emails. But as I already said, I cannot use -bd for systems on which I am running another smtp mail server also. If others are willing to concur that this is a new bug, I will happily submit a bug report. I also need to know where to submit it, I tried using Google and got lots of hits on places where sendmail bug reports had been made. Should I submit a bug report on OpenSuSE's bugzilla and let the maintainers figure out where to forward the bug report? Alternatively, perhaps some kind guru knows of an alternative way to configure BSD Sendmail to send but not receive emails? As always, thoughts and comments are much appreciated! Marc.... -- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
On 2023-06-20 01:58, Marc Chamberlin via openSUSE Users wrote:
Hello OpenSuSE Lister's - I think I have encountered a change on BSD Sendmail's behavior (version 8.15.2-150000.8.9.1) that coincides with upgrading OpenSuSE 15.4. I want to run sendmail on some systems that are running another MTA also (such as Apache James, Axigen) For many many moons of OpenSuSE releases, I accomplish this feat by turning off the running of sendmail in daemon mode. That is accomplished by NOT including the -bd parameter for sendmail when starting the systemd sendmail service. This effectively turns off the ability for sendmail to listen for incoming connection request on port 25. But this configuration did not stop sendmail from sending emails for clients such as clamd, cron, etc., which use sendmail internally to send emails as needed. And it did not cause a conflict of the usage of port 25 between sendmail and another MTA.
As of OpenSuSE15.4 the ability of sendmail to send emails, and not receive them is broken. Trying to send an email (via localhost) - such as the following test -
echo "Subject: sendmail test from Quasar" | sendmail -v marc@marcchamberlin.com
results in the following useless and misleading error message -
marc@marcchamberlin.com... Connecting to [127.0.0.1] port 25 via relay... marc@marcchamberlin.com... Deferred: Connection refused by [127.0.0.1]
I tried exploring firewalld, routes, dhcpd and other network tools all to no joy. The one thing I have found, that will work and get sendmail to send email messages, is to restore the -bd parameter, which up to 15.4 has never affected sendmail's ability to send emails. But as I already said, I cannot use -bd for systems on which I am running another smtp mail server also.
If others are willing to concur that this is a new bug, I will happily submit a bug report. I also need to know where to submit it, I tried using Google and got lots of hits on places where sendmail bug reports had been made. Should I submit a bug report on OpenSuSE's bugzilla and let the maintainers figure out where to forward the bug report?
Alternatively, perhaps some kind guru knows of an alternative way to configure BSD Sendmail to send but not receive emails?
As always, thoughts and comments are much appreciated! Marc....
I'm confused. I run the default postfix, which listens to port 25, and includes a sendmail binary, which can be called with no tricks to send mail. No tricks at all. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 6/19/23 17:40, Carlos E. R. wrote:
On 2023-06-20 01:58, Marc Chamberlin via openSUSE Users wrote:
Hello OpenSuSE Lister's - I think I have encountered a change on BSD Sendmail's behavior (version 8.15.2-150000.8.9.1) that coincides with upgrading OpenSuSE 15.4. I want to run sendmail on some systems that are running another MTA also (such as Apache James, Axigen) For many many moons of OpenSuSE releases, I accomplish this feat by turning off the running of sendmail in daemon mode. That is accomplished by NOT including the -bd parameter for sendmail when starting the systemd sendmail service. This effectively turns off the ability for sendmail to listen for incoming connection request on port 25. But this configuration did not stop sendmail from sending emails for clients such as clamd, cron, etc., which use sendmail internally to send emails as needed. And it did not cause a conflict of the usage of port 25 between sendmail and another MTA.
As of OpenSuSE15.4 the ability of sendmail to send emails, and not receive them is broken. Trying to send an email (via localhost) - such as the following test -
echo "Subject: sendmail test from Quasar" | sendmail -v marc@marcchamberlin.com
results in the following useless and misleading error message -
marc@marcchamberlin.com... Connecting to [127.0.0.1] port 25 via relay... marc@marcchamberlin.com... Deferred: Connection refused by [127.0.0.1]
I tried exploring firewalld, routes, dhcpd and other network tools all to no joy. The one thing I have found, that will work and get sendmail to send email messages, is to restore the -bd parameter, which up to 15.4 has never affected sendmail's ability to send emails. But as I already said, I cannot use -bd for systems on which I am running another smtp mail server also.
If others are willing to concur that this is a new bug, I will happily submit a bug report. I also need to know where to submit it, I tried using Google and got lots of hits on places where sendmail bug reports had been made. Should I submit a bug report on OpenSuSE's bugzilla and let the maintainers figure out where to forward the bug report?
Alternatively, perhaps some kind guru knows of an alternative way to configure BSD Sendmail to send but not receive emails?
As always, thoughts and comments are much appreciated! Marc....
I'm confused.
I run the default postfix, which listens to port 25, and includes a sendmail binary, which can be called with no tricks to send mail.
No tricks at all.
"which listens to port 25" That's the problem with most MTA's, they listen on port 25 and I can't allow that. I am using customized email servers, in particular Apache James which has internal mailets I wrote for automating an email interface with a telescope. Apache James and Postfix cannot coexist on
Hi Carlos the same system. BSD sendmail could be configured so as to send ONLY and NOT listen on port 25 for incoming emails. That keeps port 25 free to be used by my Apache James MTA with a regular SMTP server capable of both sending and receiving emails on port 25. HTH's Marc -- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
On 2023-06-20 03:08, Marc Chamberlin via openSUSE Users wrote:
On 6/19/23 17:40, Carlos E. R. wrote:
On 2023-06-20 01:58, Marc Chamberlin via openSUSE Users wrote:
As always, thoughts and comments are much appreciated! Marc....
I'm confused.
I run the default postfix, which listens to port 25, and includes a sendmail binary, which can be called with no tricks to send mail.
No tricks at all.
Hi Carlos
"which listens to port 25" That's the problem with most MTA's, they listen on port 25 and I can't allow that.
Block it in the firewall. And probably listening on 25 can be disabled in postfix, but not something I have investigated. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023/06/20 10:00:52 +0200, Carlos E. R. wrote:
On 2023-06-20 03:08, Marc Chamberlin via openSUSE Users wrote:
On 6/19/23 17:40, Carlos E. R. wrote:
On 2023-06-20 01:58, Marc Chamberlin via openSUSE Users wrote:
As always, thoughts and comments are much appreciated! Marc....
I'm confused.
I run the default postfix, which listens to port 25, and includes a sendmail binary, which can be called with no tricks to send mail.
No tricks at all.
Hi Carlos
"which listens to port 25" That's the problem with most MTA's, they listen on port 25 and I can't allow that.
Block it in the firewall.
And probably listening on 25 can be disabled in postfix, but not something I have investigated.
If no sendmail daemon is running (aka stopped and disabled via systemctl) or if running but configured not to listen on port 25 aka smtp on 127.0.0.1 as well as on ::1 (change /etc/mail/linux.mc based on the README below /usr/share/sendmail/ and use the m4 command below /etc/mail/ to generate the /etc/sendmail.cf ) ... but be aware that if no other daemon is listen on 127.0.0.1 as well as on ::1 at port 25 you'll get a connection refused. Check this with sudo ss -lntp | grep :25 to see if port 25 is provided by a daemon Btw: this is not a bug ;) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 20 Jun 2023 10:00:52 +0200 On 2023-06-20 03:08, Marc Chamberlin via openSUSE Users wrote:
On 6/19/23 17:40, Carlos E. R. wrote:
On 2023-06-20 01:58, Marc Chamberlin via openSUSE Users wrote:
As always, thoughts and comments are much appreciated! Marc....
I'm confused.
I run the default postfix, which listens to port 25, and includes a sendmail binary, which can be called with no tricks to send mail.
No tricks at all.
Hi Carlos
"which listens to port 25" That's the problem with most MTA's, they listen on port 25 and I can't allow that.
Block it in the firewall. That won't help; he wants another app to be able to listen on the port. And probably listening on 25 can be disabled in postfix, but not something I have investigated. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar) Yes; FTR, Postfix has a line in /etc/postfix/master.cf that looks like this: smtp inet n - n - - smtpd Comment that out, restart the postfix daemon, and Postfix will no longer monopolize port 25 (signified here by "smtp"). Alternatively, replacing "smtp" by "localhost:10025" moves it out of the way by using a different port on localhost. ================ From: "Dr. Werner Fink" <werner@suse.de> Date: Tue, 20 Jun 2023 10:55:27 +0200 On 2023/06/20 10:00:52 +0200, Carlos E. R. wrote:
Block it in the firewall.
And probably listening on 25 can be disabled in postfix, but not something I have investigated.
If no sendmail daemon is running (aka stopped and disabled via systemctl) or if running but configured not to listen on port 25 aka smtp on 127.0.0.1 as well as on ::1 (change /etc/mail/linux.mc based on the README below /usr/share/sendmail/ and use the m4 command below /etc/mail/ to generate the /etc/sendmail.cf ) ... So far so good . . . but be aware that if no other daemon is listen on 127.0.0.1 as well as on ::1 at port 25 you'll get a connection refused . . . Werner In more detail, if sendmail is told to bind port 25 on localhost, Apache James will have to be told to bind port 25 on all interfaces *other than* localhost. Otherwise, it will try binding port 25 on 0.0.0.0, and this will fail, usually resulting in a complete failure of the MTA to start up. The error messages I've seen for this (and I've shot myself in this particular foot multiple times, not just with MTAs) are usually confusing, which I why I think this deserves special mention. -- Bob Rogers http://www.rgrjr.com/
Hi Bob, Carlos, and all you other kind responders to my query. I guess I was not clear enough in my original post, so I have change the subject of this thread slightly in order to be a bit clearer. For many years I have been using the BSD version of sendmail because it was the recommend way (from the folks at Apache James) and I suspect it had an easy to understand way to stop it from listening on port 25. This was done by not using the -bd parameter, that I mentioned earlier, which forks a separate process/daemon that listens on port 25 for incoming connections. I only want the BSD version of it's sendmail binary to send internally generated emails from other services such as cron, fail2ban, clamd etc., that rely on a sendmail process to send their messages. I much appreciate your taking the time to describe how to change the Postfix version of sendmail so that it too will not listen for incoming connections on port 25. I will keep that as a reserve option to try if I cannot get to the bottom of the problem I am now experiencing, as of OpenSuSE 15.4. The current version of the BSD version of its sendmail binary/command now seems to want to make a connection on port 25, expecting a listening daemon is running and listening for connections. I don't think the previous versions of BSD sendmail wanted to make a connection on port 25, but rather when the BSD sendmail binary was called to compose and send an email, it in turn called directly the internal routines of BSD sendmail that are responsible for actually sending or relaying a message to another MTA. This is my only hypothesis on why the -bd parameter's behavior has changed and is now required by the sendmail binary. Also, as I have discovered, if the current version of BSD sendmail command is called directly, to compose and send an email, and the -bd parameter is not specified when the BSD sendmail service is started, I get a connection refused on port 25. This is true across all of my firewalld zones. If I am correct, this is a MAJOR change to BSD sendmail and NOT at all backwards compatible with the previous versions of the BSD sendmail binary. My inquiring mind wants to know why this change in the BSD version of sendmail was made, is there a workaround, and/or is this a bug. Google is not helping me find an answer, probably because this appears to be a recent change in behavior. I have another issue that appears to be a show stopper regarding port forwarding on localhost which doesn't appear to be working either. I will start another thread tomorrow, it is too late and I am too tired to continue, but I will say these two issues are connected in terms of what I am trying to accomplish with these MTAs.... Thanks again everyone for your help and ideas and please keep em coming! Marc On 6/20/23 11:29, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 20 Jun 2023 10:00:52 +0200
On 2023-06-20 03:08, Marc Chamberlin via openSUSE Users wrote: > On 6/19/23 17:40, Carlos E. R. wrote: >> On 2023-06-20 01:58, Marc Chamberlin via openSUSE Users wrote:
>>> As always, thoughts and comments are much appreciated! Marc.... >> >> >> I'm confused. >> >> I run the default postfix, which listens to port 25, and includes a >> sendmail binary, which can be called with no tricks to send mail. >> >> No tricks at all. >> > Hi Carlos > >> "which listens to port 25" > That's the problem with most MTA's, they listen on port 25 and I can't > allow that.
Block it in the firewall.
That won't help; he wants another app to be able to listen on the port.
And probably listening on 25 can be disabled in postfix, but not something I have investigated.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
Yes; FTR, Postfix has a line in /etc/postfix/master.cf that looks like this:
smtp inet n - n - - smtpd
Comment that out, restart the postfix daemon, and Postfix will no longer monopolize port 25 (signified here by "smtp"). Alternatively, replacing "smtp" by "localhost:10025" moves it out of the way by using a different port on localhost.
================ From: "Dr. Werner Fink" <werner@suse.de> Date: Tue, 20 Jun 2023 10:55:27 +0200
On 2023/06/20 10:00:52 +0200, Carlos E. R. wrote: > > Block it in the firewall. > > And probably listening on 25 can be disabled in postfix, but not something I > have investigated.
If no sendmail daemon is running (aka stopped and disabled via systemctl) or if running but configured not to listen on port 25 aka smtp on 127.0.0.1 as well as on ::1 (change /etc/mail/linux.mc based on the README below /usr/share/sendmail/ and use the m4 command below /etc/mail/ to generate the /etc/sendmail.cf ) ...
So far so good . . .
but be aware that if no other daemon is listen on 127.0.0.1 as well as on ::1 at port 25 you'll get a connection refused . . .
Werner
In more detail, if sendmail is told to bind port 25 on localhost, Apache James will have to be told to bind port 25 on all interfaces *other than* localhost. Otherwise, it will try binding port 25 on 0.0.0.0, and this will fail, usually resulting in a complete failure of the MTA to start up. The error messages I've seen for this (and I've shot myself in this particular foot multiple times, not just with MTAs) are usually confusing, which I why I think this deserves special mention.
-- Bob Rogers http://www.rgrjr.com/
-- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
From: Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> Date: Tue, 20 Jun 2023 22:55:54 -0700 Hi Bob, Carlos, and all you other kind responders to my query. I guess I was not clear enough in my original post, so I have change the subject of this thread slightly in order to be a bit clearer. For many years I have been using the BSD version of sendmail because it was the recommend way (from the folks at Apache James) and I suspect it had an easy to understand way to stop it from listening on port 25. This was done by not using the -bd parameter, that I mentioned earlier, which forks a separate process/daemon that listens on port 25 for incoming connections. I only want the BSD version of it's sendmail binary to send internally generated emails from other services such as cron, fail2ban, clamd etc., that rely on a sendmail process to send their messages. OK, I think that's clear. You need Apache James for incoming emails on port 25, and are using sendmail only for outgoing email originated on that system. I much appreciate your taking the time to describe how to change the Postfix version of sendmail so that it too will not listen for incoming connections on port 25. I will keep that as a reserve option to try if I cannot get to the bottom of the problem I am now experiencing, as of OpenSuSE 15.4. Understood; I certainly don't expect you to switch MTAs mid-project. I've had to do that several times now, and the learning curve can be steep. On the other hand, I've never tried running two MTAs on the same system before, which sounds like it could get sticky. But I guess you've been doing that successfully until this upgrade, so maybe it's not so bad. The current version of the BSD version of its sendmail binary/command now seems to want to make a connection on port 25, expecting a listening daemon is running and listening for connections. I don't think the previous versions of BSD sendmail wanted to make a connection on port 25, but rather when the BSD sendmail binary was called to compose and send an email, it in turn called directly the internal routines of BSD sendmail that are responsible for actually sending or relaying a message to another MTA. This is my only hypothesis on why the -bd parameter's behavior has changed and is now required by the sendmail binary. According to [1], "-bd" causes sendmail to run as a daemon and listen on port 25 (as you say); without it, it tries to deliver a message from stdin. I am pretty sure this is long-standing behavior for the sendmail binary. Also, as I have discovered, if the current version of BSD sendmail command is called directly, to compose and send an email, and the -bd parameter is not specified when the BSD sendmail service is started, I get a connection refused on port 25. This is true across all of my firewalld zones. So the sendmail "server" is trying to *connect to* something on port 25, presumably to attempt a delivery. My reading of the aforementioned page is that without "-bd", sendmail (still running in the systemd process and not as a daemon) should see no addresses on the command line and an EOF on stdin, and exit with an error. (This may have happened before your upgrade, but somebody fixed a bug (in sendmail or its systemd interface) that hid the error. Or not; see below. If you still have the older installation around, it might be instructive to see what "systemctl status sendmail" says after startup.) But now, obscurely, it seems to be trying to deliver something, to somewhere . . . If I am correct, this is a MAJOR change to BSD sendmail and NOT at all backwards compatible with the previous versions of the BSD sendmail binary. My inquiring mind wants to know why this change in the BSD version of sendmail was made, is there a workaround, and/or is this a bug. Google is not helping me find an answer, probably because this appears to be a recent change in behavior. This is quite odd, but it amounts to a different error behavior; by not requesting a sendmail daemon in the systemd startup script, you went off into uncharted territory. That alone should explain why you haven't found any fellow sufferers. Now that I'm finally reading your emails in detail (and I confess that I only skimmed them before because I'm not a sendmail guru), I believe that what you need to do is: (a) figure out how to tweak the /etc/mail/sendmail.cf configuration file to tell sendmail not to start an SMTP server on port 25 (or, failing that, to start it on some other obscure port on the loopback interface) so it doesn't clobber Apache James; and (b) reinstate that "-bd" option in the systemd startup file so that you get the sendmail daemon back, because you need it it to manage the outgoing queue. All of which should be taken with a grain of salt because, again, I'm not a sendmail guru. Also, I can't entirely explain the symptoms you're currently seeing, nor can I explain how you were able to send mail before without a running daemon. Perhaps the default used to be to start a daemon if there was no message, and that's what they changed in this release? In any case, the solution outlined above is what I would try next. And I'm also going to bet that setting this up would be easier with either of the other two MTAs I've dealt with (Qmail and Postfix) than it is with sendmail. Again, not that I'm advocating switching ATM, but you might want to look into it longer term. I preferred Qmail when sendmail was the widespread default (it's wicked fast and rock solid) but Postfix has the advantage of being the openSUSE default. Thanks again everyone for your help and ideas and please keep em coming! Marc No problem. -- Bob [1] https://man.freebsd.org/cgi/man.cgi?sendmail (note that this is current, but dated 2013)
On 2023-06-21 22:41, Bob Rogers wrote:
From: Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> Date: Tue, 20 Jun 2023 22:55:54 -0700
Hi Bob, Carlos, and all you other kind responders to my query. I guess I was not clear enough in my original post, so I have change the subject of this thread slightly in order to be a bit clearer. For many years I have been using the BSD version of sendmail because it was the recommend way (from the folks at Apache James) and I suspect it had an easy to understand way to stop it from listening on port 25. This was done by not using the -bd parameter, that I mentioned earlier, which forks a separate process/daemon that listens on port 25 for incoming connections. I only want the BSD version of it's sendmail binary to send internally generated emails from other services such as cron, fail2ban, clamd etc., that rely on a sendmail process to send their messages.
OK, I think that's clear. You need Apache James for incoming emails on port 25, and are using sendmail only for outgoing email originated on that system.
I much appreciate your taking the time to describe how to change the Postfix version of sendmail so that it too will not listen for incoming connections on port 25. I will keep that as a reserve option to try if I cannot get to the bottom of the problem I am now experiencing, as of OpenSuSE 15.4.
Understood; I certainly don't expect you to switch MTAs mid-project. I've had to do that several times now, and the learning curve can be steep. On the other hand, I've never tried running two MTAs on the same system before, which sounds like it could get sticky. But I guess you've been doing that successfully until this upgrade, so maybe it's not so bad.
The current version of the BSD version of its sendmail binary/command now seems to want to make a connection on port 25, expecting a listening daemon is running and listening for connections. I don't think the previous versions of BSD sendmail wanted to make a connection on port 25, but rather when the BSD sendmail binary was called to compose and send an email, it in turn called directly the internal routines of BSD sendmail that are responsible for actually sending or relaying a message to another MTA. This is my only hypothesis on why the -bd parameter's behavior has changed and is now required by the sendmail binary.
According to [1], "-bd" causes sendmail to run as a daemon and listen on port 25 (as you say); without it, it tries to deliver a message from stdin. I am pretty sure this is long-standing behavior for the sendmail binary.
Also, as I have discovered, if the current version of BSD sendmail command is called directly, to compose and send an email, and the -bd parameter is not specified when the BSD sendmail service is started, I get a connection refused on port 25. This is true across all of my firewalld zones.
So the sendmail "server" is trying to *connect to* something on port 25, presumably to attempt a delivery. My reading of the aforementioned page is that without "-bd", sendmail (still running in the systemd process and not as a daemon) should see no addresses on the command line and an EOF on stdin, and exit with an error.
Why is not "Apache James", which you said listens "for incoming emails on port 25", accepting the connection from the sendmail on port 25? Postfix provides a sendmail binary with limited functionality to fool local applications into calling sendmail to send mail, but that binary instead passes it to postfix "somehow". Question: doesn't Apache James provide another sendmail binary for this purpose? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 6/21/23 14:08, Carlos E. R. wrote:
Why is not "Apache James", which you said listens "for incoming emails on port 25", accepting the connection from the sendmail on port 25?
Carlos, you are a great straight man, LOL, asking a question that directly leads to the second issue that I mention and said I would start a new thread about! My Apache James server cannot run under root control for security reasons. Root control gives access to some of the mailet functions that control a telescope and would be very dangerous if someone managed to find a way to access them via Apache James and/or it's mailets. (they could cause expensive damage to a telescope) So as recommend by the Apache James folks I run it under it's own user name that has very limited capabilities. This means Apache James cannot run/attach itself to the low numbered ports and listen for incoming connections there. Only root owned processes are allow to have access to the low numbered ports that most email servers use. (smtp, pop3, imap, etc) So I have configured firewalld to do port forwarding of these low numbered ports to high numbered ports that Apache James is actually listening to. This works fine for the interfaces connected to my external and internal zones/networks, including port 25, but for some reason I don't grok, I cannot get port forwarding to work for the localhost. I have assigned both localhost and the IP address of 127.0.0.1 (I'm not using IPv6 addresses at all) to the trusted zone in firewalld, and like the external and internal interfaces, I set up firewalld to do port forwarding also for the local host/trusted zone email ports. Doesn't work and when sendmail is used to send an email from localhost or a localhost processes (port 25) they get a connection refused error message back. That shows firewalld is failing to follow the port forwarding rules I set up in firewalld for the trusted zone. I cannot even telnet on localhost, to the low numbers ports, such as port 127.0.0.1:25, which is suppose to be forwarding these connections to port 127.0.0.1:10025 where Apache James is listening. Besides using firewalld commands, I have fooled around with some rich rules and direct rules and still no joy (sigh, problems such a this almost makes me want to go back to the old days of using SuSEFirewall) So what gives with firewalld? Why is it refusing to forward localhost ports? Googling also seems to imply that it is not possible but I get mixed answers and no good explanations as to why and/or what is a work around? Can/do I have to use IPTables rules directly instead? If so, can some kind guru tell me how, I am not an IPTables guru yet.
Postfix provides a sendmail binary with limited functionality to fool local applications into calling sendmail to send mail, but that binary instead passes it to postfix "somehow". Question: doesn't Apache James provide another sendmail binary for this purpose?
Yeah, I am planning/scheduling time to take a look at Postfix (groan) but haven't gotten approval yet from my lords on high. And no, Apache James does not provide an equivalent sendmail binary, instead they recommend using the BSD sendmail binary instead. (Would be a good idea for an Apache James mailet to plug in to the server, but I don't have the time or approval to write it myself.) Thanks as always for your thoughts and questions, Marc... -- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
From: Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> Date: Wed, 21 Jun 2023 16:50:25 -0700 . . . My Apache James server cannot run under root control for security reasons . . . So I have configured firewalld to do port forwarding of these low numbered ports to high numbered ports that Apache James is actually listening to . . . So what gives with firewalld? Why is it refusing to forward localhost ports? Googling also seems to imply that it is not possible but I get mixed answers and no good explanations as to why and/or what is a work around? Can/do I have to use IPTables rules directly instead? If so, can some kind guru tell me how, I am not an IPTables guru yet. Sigh. At least now we're getting to someplace I'm more familiar with, as I used to write my own firewalls with ipchains, then iptables. Unfortunately, because of my DIY bent, I have no experience with firewalld, or even SuSEFirewall. Accordingly, I may still only be able to help you halfway. IIUC, you want port 25 on your public IP to be forwarded to 127.0.0.1:10025 on the same machine so that an unprivileged Apache James can listen on that port, correct? Because that certainly seems like it ought to work. (Did it work before, or is that a casualty of upgrading? Just to openSUSE Leap 15.4, or also to firewalld? Just wondering.) If so, you can do iptables -t nat --list and see if firewalld added the appropriate rule in the PREROUTING chain. If not, and it claimed to have done so, you now have material for a bug report. And then you can decide if you want to ditch firewalld, or patch it, or try something else. -- Bob
On 22.06.2023 02:50, Marc Chamberlin via openSUSE Users wrote:
So I have configured firewalld to do port forwarding of these low numbered ports to high numbered ports that Apache James is actually listening to.
Brilliant. So it took just a dozen of emails to finally inform us about your actual configuration and actual problem.
This works fine for the interfaces connected to my external and internal zones/networks, including port 25, but for some reason I don't grok, I cannot get port forwarding to work for the localhost.
Because firewalld rules are for incoming traffic (i.e. INPUT chain) and packets from local processes are not incoming but outgoing packets (i.e. they go via OUTPUT chain). Current firewalld allows adding port redirection in OUTPUT chain using policy with egress zone HOST and ingress zone ANY, but it is not yet supported in the version provided by Leap 15.4. If you absolutely need it, use direct rule to configure redirection. Anyway, instead of jumping through the hoops it is much more easier to configure your relay mailer to connect to the correct port.
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Wed, 21 Jun 2023 23:08:35 +0200 On 2023-06-21 22:41, Bob Rogers wrote:
From: Marc Chamberlin via openSUSE Users <users@lists.opensuse.org> Date: Tue, 20 Jun 2023 22:55:54 -0700
. . .
Also, as I have discovered, if the current version of BSD sendmail command is called directly, to compose and send an email, and the -bd parameter is not specified when the BSD sendmail service is started, I get a connection refused on port 25. This is true across all of my firewalld zones.
So the sendmail "server" is trying to *connect to* something on port 25, presumably to attempt a delivery. My reading of the aforementioned page is that without "-bd", sendmail (still running in the systemd process and not as a daemon) should see no addresses on the command line and an EOF on stdin, and exit with an error.
Why is not "Apache James", which you said listens "for incoming emails on port 25", accepting the connection from the sendmail on port 25? Maybe sendmail is trying port 25 on localhost and Apache James is only binding 25 on some other interface? Maybe sendmail is trying to connect to some other host? In any case, I think this is a side issue; the real problem is to get the sendmail daemon (if a daemon is in fact necessary) configured for outgoing email only. Postfix provides a sendmail binary with limited functionality to fool local applications into calling sendmail to send mail, but that binary instead passes it to postfix "somehow". Question: doesn't Apache James provide another sendmail binary for this purpose? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar) I'm guessing it doesn't, and didn't, or Marc would have been using it before his upgrade. (IIRC he said the Apache James doc said to use sendmail for outgoing mail.) -- Bob
On 20.06.2023 02:58, Marc Chamberlin via openSUSE Users wrote:
echo "Subject: sendmail test from Quasar" | sendmail -v marc@marcchamberlin.com
results in the following useless and misleading error message -
marc@marcchamberlin.com... Connecting to [127.0.0.1] port 25 via relay... marc@marcchamberlin.com... Deferred: Connection refused by [127.0.0.1]
Show output of ss -lntp as root
participants (5)
-
Andrei Borzenkov -
Bob Rogers -
Carlos E. R. -
Dr. Werner Fink -
Marc Chamberlin