Daniel B. Thurman schrieb:
I am having a bit of trouble getting sendmail to work
properly. Strangely, I encountered something that I
never saw before (in messages log file when (re)starting
sendmail), but found resolution for, was this:
in Messages log file:
STARTTLS: CRLFile missing
If you have Sendmail setup to run TLS support it is complaining if a
revocation list is missing. Although it depends on the log level of
Sendmail whether you see the complaints in your log. See my last comment.
The message itself is not harmful and Sendmail works with STARTTLS not
having a CRL.
The solution is:
1) cd /etc/pki/tls/certs
2) wget http://www.cacert.org/revoke.crl
3) Edit /etc/mail/sendmail.mc and add line:
4) chcon -u system_u /etc/pki/tls/certs/revoke.crl
5) service sendmail restart
... and the message in messages no longer appears.
With that out of the way, I am still unable to figure
out why I am not able to get Thunderbird (IMAP) to
connect to my local system, sendmail port 25.
Sound as mixing IMAP and SMTP. Sendmail is an MTA, making use of the
SMTP protocol, typically listening on port 25. You for sure know that.
So you mean, using Thunderbird to send a mail talking to your Sendmail
server fails? Please check your Thunderbird settings. Is it running on
the same system as Sendmail? It may not and your Sendmail is bound to
port 25 localhost only (which is the default setup). Please see the
`DAEMON_OPTIONS' instructions in your sendmail.mc.
But I do notice, that I can telnet localhost 25, and the sendmail
prompt appears, I can, on other machines local to my network
`telnet <host-under-test> 25' and sendmail prompts as well.
`lsof -i :25' will tell you whether the MTA is just on localhost.
I am still trying to figure this out to no resolution at this point,
and do not know what to do...
Another issue. I get the following, also appearing in Messages log file:
Dec 21 14:08:01 bronze sendmail: mBLM81Fn010866: --- 250 2.0.0
mBLM81Fn010866 Message accepted for delivery
Dec 21 14:08:01 bronze sendmail: mBLM81eu010865: to=apache,
ctladdr=apache (48/48), delay=00:00:00, xdelay=00:00:00, mailer=relay,
pri=30449, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent
(mBLM81Fn010866 Message accepted for delivery)
Dec 21 14:08:01 bronze sendmail: mBLM81Fn010866: alias
<apache localhost localdomain> => root
Dec 21 14:08:01 bronze sendmail: mBLM81Fn010866: alias root => dant
Dec 21 14:08:01 bronze sendmail: STARTTLS=read, info: fds=6/4, err=2
Dec 21 14:08:01 bronze sendmail: mBLM81Fo010866: <-- QUIT
Dec 21 14:08:01 bronze sendmail: mBLM81Fo010866: --- 221 2.0.0
localhost.localdomain closing connection
Dec 21 14:08:01 bronze sendmail: STARTTLS=server, SSL_shutdown
Dec 21 14:08:01 bronze sendmail: mBLM81Fo010866: Milter
(clamav-milter): quit filter
Dec 21 14:08:20 bronze sendmail: mBLM81Fn010866: to=dant,
ctladdr=<apache localhost localdomain> (48/48), delay=00:00:19,
xdelay=00:00:19, mailer=local, pri=31141, dsn=2.0.0, stat=Sent
Dec 21 14:08:20 bronze sendmail: mBLM81Fn010866: done;
Clearly, apache is sending a local message of a problem,
but what I do not understand are these lines:
1) Dec 21 14:08:01 bronze sendmail: STARTTLS=read, info: fds=6/4,
2) Dec 21 14:08:01 bronze sendmail: STARTTLS=server, SSL_shutdown
Does anyone have any suggestions what I can do for further
investigation as to what is going on, if there is a problem,
or if these issues can be fixed?
I guess you have set your Sendmail log verbosity to a higher level. `9'
is the default and should not print out so much informations. Do you
have set LogLevel to 12 or higher? From `12' on you get TLS verification
You can deactivate STARTTLS for localhost communications of Sendmail by
to your access file an building up a new access.db based on this.
You find all the TLS checks and logging messages in the Sendmail source
code, i.e. in:
I don't know a document explaining the STARTTLS debug log messages in
For instance see line 1382 for logging "SSL_shutdown not done". So you
are seeing a higher debug level here (>15). Following your mail flow
from the shown maillog there is no problem. The mail was generated by
user "apache" and successfully sent to "dant".