how to stop sendmail 100%

I

ipfreak

hello guys:

i am trying to stop sendmail completely but it doesn't seem to work as intended. here is my rc.conf and hosts:

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"


::1 localhost localhost.domain.dyndns.net
127.0.0.1 localhost server.domain.dyndns.ne

but i still get following messages once a white (not constantly):


Mar 6 03:01:00 <console.info> server kernel: Mar 6 03:01:00 <mail.crit> server sendmail[35319]: My unqualified host name (server) unknown; sleeping for retry
Mar 6 03:02:00 <console.info> server kernel: Mar 6 03:02:00 <mail.alert> server sendmail[35319]: unable to qualify my own domain name (server) -- using short name
Mar 6 03:02:01 <console.info> server kernel: Mar 6 03:02:01 <mail.crit> server sendmail[44481]: My unqualified host name (server) unknown; sleeping for retry

thanks.

_dave
 
ONE way for "100%" is of course the following in /etc/src.conf IF you build yourself:
Code: 
WITHOUT_SENDMAIL=yes
This is one of the things I really wonder why they are still in base by default. I think base should only have a really "dumb" mailer like dma.
 
I really think FreeBSD should remove "cruft" from base. sendmail is a perfect candidate, cause MOST installations nowadays don't need a full-featured MTA (which can always be installed from ports), but only a very basic local MDA which can use (if required) a "smarthost" for sending mail out. Sorry, that's slightly off-topic ;)

On a side note, I also consider tcsh a candidate for dropping. It's a shell, and it isn't POSIX compliant (so, not suitable for portable scripting). If people like to use it as their interactive shell, well, I like zsh for that (which IS POSIX compliant), and you can always install anything you like from ports. Some people prefer fish. Basic /bin/sh (of course POSIX compliant) should always be enough for a base system…
 
ipfreak said:
i had used that before. but per my understanding, <<sendmail_enable="NONE">> has been deprecated:

github.com

sendmail_enable=NONE deprecated · Issue #212 · BastilleBSD/bastille

Bastille sets sendmail_enable=NONE in every jail, butNONE has been deprecated, so that option should be replaced with: sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO"...
github.com github.com
Click to expand...
"NONE" option is deprecated and should not be used. It will be removed in a future release.
Click to expand...

Yeah you are right, but this what gets set by the FreeBSD Installer and this works for me.. BTW according to manpage this hint exists since FreeBSD 5.0 :D
 
Getting back to the OP's problem: They have correctly disabled sendmail starting on boot in rc.conf, yet it is still running.

Option 1: Maybe they have never booted since changing these settings? In that case, the command "service sendmail stop" (or ...onestop) should take care of it.

Option 2: They have rebooted. In that case, it seems that sendmail is starting even though it shouldn't. Here is how I would debug it: Start with "service sendmail status", and "ps auxww | grep sendmail". If this is happening, look at other rc files (or other parts of rc.conf?), maybe the "no" gets overridden to "yes" later?

Independent of why sendmail is running or not, there is likely another problem. The sendmail error messages show that the hostname has not been set correctly. This is normally done with these two lines in /etc/rc.conf:
Code: 
hostname="myserver.example.com"
nisdomainname="example.com"
(obviously use your correct host name). If you do not have DNS for the machine running, I think it is safe to just use "example.com", but another traditional ways is to use the ".local" pseudo-domain, so OP could use "laptop.ipfreak.local" for the host name.
 
ipfreak said:
i am trying to stop sendmail completely but it doesn't seem to work as intended. here is my rc.conf and hosts:
Code: 
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
but i still get following messages once a white (not constantly):
Code: 
Mar  6 03:01:00 <console.info> server kernel: Mar  6 03:01:00 <mail.crit> server sendmail[35319]: My unqualified host name (server) unknown; sleeping for retry
Mar  6 03:02:00 <console.info> server kernel: Mar  6 03:02:00 <mail.alert> server sendmail[35319]: unable to qualify my own domain name (server) -- using short name
Mar  6 03:02:01 <console.info> server kernel: Mar  6 03:02:01 <mail.crit> server sendmail[44481]: My unqualified host name (server) unknown; sleeping for retry
Click to expand...
The reason could be the daily mail processing scripts startet via periodic(8), see /etc/defaults/periodic.conf ( fgrep mail /etc/defaults/periodic.conf | less). If disabling them results in that the messages do not come up again, we found the root cause. Also look at the time: Mar 6 03:02:00, that's when your system crontab(5) fires the periodic daily, right?
echo daily_clean_hoststat_enable=\"NO\" >> /etc/periodic.conf
echo daily_status_mailq_enable=\"NO\" >> /etc/periodic.conf
echo daily_status_mail_rejects_enable=\"NO\" >> /etc/periodic.conf
echo daily_queuerun_enable=\"NO\" >> /etc/periodic.conf
 
PS If that is it, file in a bug report: The periodic(8) scripts should check for the rc.conf(5) variables that you explicitely disabled.
EDIT PS: I could swear sendmail_enable="NONE" should do. BastilleBSD is not FreeBSD, it's a derivate, so there can be some differences.
 
FWIW - disabling sendmail is one of the "hardening" options available on install (after daemon configuration - sshd, moused et al; and before adding a user).
 
Zirias said:
I really think FreeBSD should remove "cruft" from base. sendmail is a perfect candidate, cause MOST installations nowadays don't need a full-featured MTA (which can always be installed from ports), but only a very basic local MDA which can use (if required) a "smarthost" for sending mail out. Sorry, that's slightly off-topic
Click to expand...

Why? Because it is complicated to configure? Because there are "better" MTAs?

It is a small program and it does not make any trouble.
 
Actually, if sendmail is disabled with "sendmail...=NO" in /etc/rc.conf, then all the periodic checks should (and will) pass with flying colors and without any warning messages, as long as the system is correctly configured. I'm not even 100% sure that the periodic tasks that use sendmail should actually all be disabled if sendmail has been turned off. For example, outbound mail queueing up is a problem, whether sendmail is there to send it (and presumably failing), or whether sendmail is not going to try sending it.

Note that I said "the system", not "as long as sendmail is correctly configured". I think the basic problem here is that the OP has some sort of underlying configuration problem, which sendmail happens to complain about. My educated guess from the error messages is that the host and/or domain name aren't set. The sendmail messages are actually quite clear.

If that is indeed the problem, one might want to file a bug report that this kind of configuration error should be caught by something else, rather than by sendmail. But that's cosmetics of error messages.

As to the question whether sendmail should be in base or not: Even though I personally haven't used sendmail in about 3 or 5 years on my *BSD machines, I think it should be there. A lot of experienced BSD admins know by heart up and down in their sleep how to configure it. And while its setup is undeniably complex, it can be made to do just about anything a MTA can do. I think the real problem is that the way that today has become common (namely all mail goes off-host using a smarthost, using some form of SSL) is one that is particularly daunting to configure from scratch with sendmail. That could and should be addressed, for example with pre-cooked install scripts, or guides. But the relationship between sendmail and BSD has been very close and very long-standing (over 50 years, perhaps 50), and it is one of the things that defines *B* SD. If we remove all the annoying Berkeley-isms just because they are sometimes annoying or difficult, we end up with BSD being just "Linux light without systemd".
 
Well, 1st if sendmail is disabled it shouldn't get started, i.e. it's a surprise to see messages from sendmail at all. 2nd, yes it's deepdown config is hairy, but OTOH with the M4 macros (IIRC it's called like that) it's fairly easy for 98% of setup (network) scenarios. To the OP: you could set the time to run the periodic daily to 21:45 UTC, then we know in 15 min if my guess was ok.
 
Sorry ralphbsz , but that makes very little sense to me. What defines BSD certainly isn't sendmail, it's a certain mindset and philosophy around a rock stable (also in terms of APIs), self-contained base system. Sure, a fully functional *nix system must be able to deliver mail, but the inclusion of dma cared about that. It just doesn't make any sense to have a service in base that (at least!) 95 out of 100 users just disable. Those who want to operate a full featured MTA will most of the time install a different one from ports anyways, and there would be nothing wrong with installing sendmail from ports…
 
ipfreak said:
hello guys:

i am trying to stop sendmail completely but it doesn't seem to work as intended. here is my rc.conf and hosts:

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
Click to expand...
According to rc.sendmail(8):

sendmail_enable
(str) If set to "YES", run the sendmail(8) daemon at system boot
time. If set to "NO", do not run a sendmail(8) daemon to listen
for incoming network mail. This does not preclude a sendmail(8)
daemon listening on the SMTP port of the loopback interface. The
"NONE" option is deprecated and should not be used. It will be
removed in a future release.
Click to expand...
 
Mjölnir said:
Well, 1st if sendmail is disabled it shouldn't get started, i.e. it's a surprise to see messages from sendmail at all.
Click to expand...
It's not "exactly" getting started in periodic, in the sense that the daemon isn't running. Instead, the few periodic scripts I looked at run the sendmail executable(s) to perform various checks. If the system is correctly configured (but with sendmail disabled and left in the default configuration), then you should be able to run a program such as mailq or purgestat (all of which are sendmail in various disguises), and they should be well-behaved, meaning harmless.

Furthermore, if the OP has installed another MTA correctly, all these sendmail executables will not even be run, because they all go through the mailwrapper mechanism, which will be redirected to the executables of another MTA. I think this makes me think more and more that the OP's system is misconfigured, with the hostname/domainname not set correctly, and no MTA installed.

On the philosophical question whether sendmail should even be in base: As I said, it is the most powerful, best documented (there are many books about it) and most experienced MTA there is. It is not easy to use, and not always the most secure (it is VERY unforgiving of misconfiguration, but when correctly configured, it's very secure). So I think it passes the "rock stable" test, if the user does their part, of either using it correctly, or making the conscious choice of not using it and executing on that choice (by installing an alternate MTA). And this is *BSD, not a system for sissies, so I expect the user to do their part. Personally, in spite of having configured it a few times (and received help from Eric), I have chosen ssmtp, because it fits my needs better.
 
Block TCP port 25 with pf.

Code: 
### Block to and from port 25
block quick proto { tcp } from any port = 25 to any
block quick proto { tcp } from any to any port = 25
 
ralphbsz said:
It is not easy to use, and not always the most secure (it is VERY unforgiving of misconfiguration, but when correctly configured, it's very secure).
Click to expand...
This is the point imho.
Who wants to read thick books and half-understandingly edit a highly cryptic configuration file, possibly unintentionally opening up some doors wide?
Especially when simple alternatives with less risk for non-gurus exist...

If there is no way to cleanly disable sendmail otherwise, I guess the "NONE" setting will stay alive despite being deprecated.
 
Mjölnir said:
The reason could be the daily mail processing scripts startet via periodic(8), see /etc/defaults/periodic.conf ( fgrep mail /etc/defaults/periodic.conf | less). If disabling them results in that the messages do not come up again, we found the root cause. Also look at the time: Mar 6 03:02:00, that's when your system crontab(5) fires the periodic daily, right?
echo daily_clean_hoststat_enable=\"NO\" >> /etc/periodic.conf
echo daily_status_mailq_enable=\"NO\" >> /etc/periodic.conf
echo daily_status_mail_rejects_enable=\"NO\" >> /etc/periodic.conf
echo daily_queuerun_enable=\"NO\" >> /etc/periodic.conf
Click to expand...

thank you very much.

should i also change following lines or no need to since both relevant "enable" lines have been set to "NO"?

daily_status_include_submit_mailq="YES"
daily_submit_queuerun="YES"

btw, the line <<daily_status_mail_rejects_enable="NO">> is default value for "FreeBSD server 12.2-RELEASE-p4 FreeBSD 12.2-RELEASE-p4 GENERIC i386"
 
Mjölnir said:
PS If that is it, file in a bug report: The periodic(8) scripts should check for the rc.conf(5) variables that you explicitely disabled.
EDIT PS: I could swear sendmail_enable="NONE" should do. BastilleBSD is not FreeBSD, it's a derivate, so there can be some differences.
Click to expand...
thanks. i think you have nailed the issue. i should have stated clearer than what i had done.

those console messages only came out every morning 03:00.

i will check tomorrow morning after the changes.
 
None of the addresses the root cause. What happens when you say "hostname" or "domainname"? What happens when you say "sendmail -q"? All of those ought to work, and give sensible answers (the last one should say "mail queue empty" or something like that).
 
ralphbsz said:
None of the addresses the root cause. What happens when you say "hostname" or "domainname"? What happens when you say "sendmail -q"? All of those ought to work, and give sensible answers (the last one should say "mail queue empty" or something like that).
Click to expand...
thanks. i have confirmed that sendmail daemon is not running.
 
You must log in or register to reply here.
Back
Top