• Home
• Blog
• Downloads
• Info
• Reviews
• Virus Warnings
• Search Site

In email from the Cron Daemon to the root account, I found messages with the following within them:

/etc/cron.daily/logrotate:

error: syslog:1 duplicate log entry for /var/log/maillog

I checked /etc/logrotate.conf, but didn't find any references to rotation of the maillog file there.

Contents of /etc/logrotate.conf:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    minsize 1M
    create 0664 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

I then checked the /etc/logrotate.d directory. I found maillogrotate there.

Contents of /etc/logrotate.d/maillogrotate:

# Begin maillogrotate control file
/var/log/maillog {
   daily
   rotate 14
   sharedscripts
   create 0600 root root
   missingok
   postrotate
   /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
   endscript
}
# End maillogrotate control file

I also checked the /etc/logrotate.d/syslog file, since syslog may rotate the file.

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
        /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

So it appears that both the /etc/logrotate.d/maillogrotate and the /etc/logrotate.d/syslog files were attempting to rotate the maillog file on a daily basis.

Checking notes posted on my blog, I found I resolved the problem on another email server, a Redhat Linux server, on Friday, September 17 of 2004, almost exactly 4 years ago, and had posted my notes in Daily Rotation of Mail Logs. In that case, I had removed the /var/log/maillog reference from /etc/logrotate.d/syslog, so I did the same thing in this case as well. But this time, I decided to leave the maillogrotate file in /etc/logrotate.d.

Checking my notes for the CentOS email server, I see that I had in the past removed the /var/log/maillog reference from /etc/logrotate.d/syslog. Some installation or upgrade must of led to the version of the file I created then being overwritten.

References:

1. [Rocks-Discuss] /var/log/maillog in syslog.conf vs. /var/log/mail in logrotate.d/rocks
   Date: September 13, 2006
   SDSC Mailing List Server
2. Pflogsumm issues
   Date: July 16, 2008
   HowtoForge - Linux Howtos and Tutorials
3. Configuration: centos50
   System Configuration Collector (SCC)
4. What the hell is rotating my mail.log?
   Date: February 23, 2007
   Stephan Paukner
5. Rotating Linux Log Files - Part 1: syslog
   Date: Nisan 22, 2007
   Netlojik
6. Logging, Log File Rotation, and Syslog Tutorial
   Wayne Pollock's Home Page
7. Daily Rotation of Mail Logs
   Date: September 17, 2004
   MoonPoint Support

[/network/email/sendmail] permanent link

After the packages were installed, I check the ClamAV definitions with the freshclam command.

# freshclam -V
ClamAV 0.93/6688/Wed Apr  9 10:40:38 2008

I verified that the version of sendmail on the system provides milter support with sendmail -d0 < /dev/null | grep MILTER. If sendmail provides milter support, MILTER will be listed in the output. Sendmail 8.13 enables MILTER support by default. See Clam AntiVirus Milter Setup and Debugging for details on how to add MILTER support for prior versions.

# sendmail -d0 < /dev/null | grep MILTER
                MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6

According to Clam AntiVirus Milter Setup and Debugging, the libmilter* library must be installed on the system to use clamav-milter, so I checked for the presence of libmilter files with locate libmilter, but none were listed. The instructions suggested that if the library is not installed, one should "go to the Sendmail source directory, change into the libmilter subdirectory and run the install script." But there was no sendmail source directory on the system, since sendmail had been installed through a package when I initially set up the system. Since the instructions also stated "Some operating systems provide MILTER support via a port or package", I thought I would just proceed to see what happened.

The next step listed was to configure clamav with --enable-milter . I presumed that was already taken care of when I installed the clamav-milter package, so I proceeded to the "configure clamd.conf" step. I checked /etc/clamd.conf, but didn't make any changes.

The installation of the clamav-milter package placed two files in /etc/init.d.

# ls -l /etc/init.d/clam*
-rwxr-xr-x 1 root root 1258 Mar  7  2007 /etc/init.d/clamav-milter
-rwxr-xr-x 1 root root 1130 Nov  1  2006 /etc/init.d/clamd

It also installed and turned on two system services.

# chkconfig --list clamd
clamd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
# chkconfig --list clamav-milter
clamav-milter   0:off   1:off   2:on    3:on    4:on    5:on    6:off

I started the Clam AntiVirus daemon with /etc/init.d/clamd

# vi /etc/init.d/clamd
# /etc/init.d/clamd start
Starting Clam AntiVirus Daemon:                            [  OK  ]

You then need to configure sendmail for clamav-milter support. If you try launching clamav-milter first, you will get the error shown below:

# /etc/init.d/clamav-milter start
Starting Clamav Milter Daemon: clamav-milter: socket-addr (local:/var/clamav/clm
ilter.socket) doesn't agree with sendmail.cf
                                                           [FAILED]

So I put the following line as the last line in /etc/mail/sendmail.mc

INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav-milter.sock, F=T, T=S:4m;R:4m')

I then rebuilt the sendmail.cf file from sendmail.mc with the following command:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

When I tried restarting sendmail, though, I received a warning message:

# /etc/init.d/sendmail restart
Shutting down sm-client:                                   [  OK  ]
Shutting down sendmail:                                    [  OK  ]
Starting sendmail: WARNING: Xclmilter: local socket name /var/run/clamav/clmilte
r.sock missing
                                                           [  OK  ]
Starting sm-client:                                        [  OK  ]

I then looked in /etc/sysconfig/clamav-milter and saw the following:

### Simple config file for clamav-milter, you should
### read the documentation and tweak it as you wish.

CLAMAV_FLAGS="
    --config-file=/etc/clamd.conf
    --force-scan
    --local
    --max-children=10
    --noreject
    --outgoing
    --quiet
"
SOCKET_ADDRESS="local:/var/clamav/clmilter.socket"

Since according to the SOCKET_ADDRESS in that file, clmilter.socket was expected in /var/clamav, I modified the line I added to the end of /etc/mail/sendmail.mc to be as shown below:

INPUT_MAIL_FILTER(`clmilter', `S=local:/var/clamav/clmilter.socket, F=T, T=S:4m;R:4m')

I then rebuilt the sendmail.cf file from sendmail.mc, restarted clamav-milter, and restarted sendmail.

# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
# /etc/init.d/clamav-milter restart
Stopping Clamav Milter Daemon:                             [FAILED]
Starting Clamav Milter Daemon: Your LANG environment variable is set to 'en_US.U
TF-8'
This is known to cause problems for some clamav-milter installations.
If you get failures with temporary files, please try again with LANG unset.
LibClamAV Error: cl_cvdhead: Can't open file /var/clamav/daily.inc/daily.info
Loaded ClamAV version 0.93, clamav-milter version 0.93
ClamAV: Protecting against 280776 viruses
                                                           [  OK  ]
# /etc/init.d/sendmail restart
Shutting down sm-client:                                   [  OK  ]
Shutting down sendmail:                                    [  OK  ]
Starting sendmail:                                         [  OK  ]
Starting sm-client:                                        [  OK  ]

The "failed" for the restart of clamav-milter was probably because it wasn't started at the time; so I could have used clamav-milter start. I also saw an error message regarding "LibClamAV Error: cl_cvdhead: Can't open file /var/clamav/daily.inc/daily.info", but when I sent a test message to an account on another system, I saw "X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93" in the message's headers. I saw the same header in a message I sent from the account on the other system to the one running ClamAV. I also saw the header "X-Virus-Status: Clean". So ClamAV appeared to be scanning incoming and outgoing email.

References:

1. Clam AntiVirus Milter Setup and Debugging
   Jeremy Mates's Domain
2. Installing clamav-milter on FreeBSD
   Ring of Saturn Internetworking

[/network/email/sendmail] permanent link

The sendmail.mc already had the line FEATURE(`blacklist_recipients')dnl. The blacklist_recipients feature turns on the ability to block incoming mail for certain recipient usernames, hostnames, or addresses. For example, you can block incoming mail to user nobody, host foo.mydomain.com, or guest@bar.mydomain.com. These specifications are put in the /etc/mail/access file.

Immediately below that line, I added the following lines to use the McFadden Associates E-Mail Blacklist, the Spamhaus Block List, and the Passive Spam Block List.

FEATURE(`dnsbl', `bl.csma.biz', `550 Spam Block: mail from $&{client_addr} refused - See http://bl.csma.biz/')dnl
FEATURE(`dnsbl', `sbl.spamhaus.org', `550 Spam Block: mail from $&{client_addr} refused - See http://www.spamhaus.org/sbl/')dnl
FEATURE(`dnsbl', `psbl.surriel.com', `550 Spam Block: mail from $&{client_addr} refused - see http://psbl.surriel.com/')dnl

I removed the "dnl" from the beginning of the following line, which "uncomments" the directive, to allow the system to accept email from users who have authenticated by a trusted mechanism defined by TRUST_AUTH_MECH (see Sendmail Authorization for Outgoing Email).

dnl FEATURE(delay_checks)dnl

I didn't want a user's email to be rejected because the user's system received a dynamically assigned IP address previously assigned to a system sending out spam, which I've seen happen previously. By using the delay_checks feature, you can have sendmail skip the check_mail and check_relay rulesets, if the sender has been authenticated by a "trusted" mechanism, such as by sending the user's userid and password to the server when sending email.

I then regenerated the sendmail.cf file from the sendmail.mc file and restarted sendmail with the commands below.

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
/etc/init.d/sendmail restart

References:

1. Sendmail cf/README - Features
   sendmail.org
2. Sendmail cf/README - Anti-Spam Configuration Control sendmail.org
3. Passive Spam Block List (PSBL) Added
   MoonPoint Support
4. Sendmail Authorization for Outgoing Email. MoonPoint Support
5. McFadden Associates E-Mail Blacklist
6. Spamhaus Block List
7. Passive Spam Block List

[/network/email/sendmail] permanent link

The server was running sendmail, which supports SMTP AUTH as defined in RFC 2554 which is based on SASL.

The Cyrus SASL package should be installed to enable sendmail to support the AUTH command for authorization. I checked on whether it was installed with rpm -qi cyrus-sasl. I saw it was installed. I then tried sendmail -d0.1 -bv root | grep SASL and saw NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS. The "SASLv2" in the output confirmed that support for SASL was present.

But when I connected to the SMTP port by telnet, I didn't see the AUTH command listed when I issued an ehlo command. And I received messages that the "plain", "login", "cram-md5", and "digest-md5" authorization methods weren't supported when I issued auth commands for those authentication methods.

# telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 example.com ESMTP Sendmail 8.13.8/8.13.8; Tue, 6 May 2008 10:34:34 -0400
ehlo laptop
250-example.com Hello localhost.localdomain [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
AUTH LOGIN
504 5.3.3 AUTH mechanism LOGIN not available
AUTH PLAIN
504 5.3.3 AUTH mechanism PLAIN not available
AUTH CRAM-MD5
504 5.3.3 AUTH mechanism CRAM-MD5 not available
AUTH DIGEST-MD5
504 5.3.3 AUTH mechanism DIGEST-MD5 not available
quit

When I used the testsaslauthd command to check that the saslauthd daemon was installed and running properly, I saw that it was working properly.

# testsaslauthd -s smtp -u jdoe -p HerPassword
0: OK "Success."

You can test SASL support with the testsaslauthd command by specifying a username and its associated password on the system with -u username -p password. The -s service option specifies a particular service. Common service names are "imap", "sieve", and "smtp".

I then looked at /etc/mail/sendmail.mc. I saw define(`confAUTH_OPTIONS', `A')dnl, which provides a list of options for SMTP AUTH was not commented out, so I left it as is. I left the "dnl" at the beginning of the following line, which appeared later in the file. The p option in it would result in sendmail not accepting the PLAIN and LOGIN AUTH methos unless they were protected by a security latyer, such as is provided by STARTTLS.

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

      AuthOptions
                [no short name] List  of  options  for  SMTP
                AUTH  consisting  of  single characters with
                intervening white space or commas.

                    A   Use the AUTH= parameter for the MAIL FROM
                        command only when authentication succeeded.
                        This can be used as a workaround for broken
                        MTAs that do not implement RFC 2554 correctly.
                    a   protection from active (non-dictionary) attacks
                        during authentication exchange.
                    c   require mechanisms which pass client credentials,
                        and allow mechanisms which can pass credentials
                        to do so.
                    d   don't permit mechanisms susceptible to passive
                        dictionary attack.
                    f   require forward secrecy between sessions
                        (breaking one won't help break next).
                    p   don't permit mechanisms susceptible to simple
                        passive attack (e.g., PLAIN, LOGIN), unless a
                        security layer is active.
                    y   don't permit mechanisms that allow anonymous login.

                The first option applies to  sendmail  as  a
                client, the others to a server.  Example:

                    O AuthOptions=p,y

                would  disallow  ANONYMOUS as AUTH mechanism
                and would allow PLAIN and LOGIN  only  if  a
                security  layer (e.g., provided by STARTTLS)
                is already active.  The  options  'a',  'c',
                'd',  'f',  'p', and 'y' refer to properties
                of the selected SASL  mechanisms.   Explana-
                tions  of  these  properties can be found in
                the Cyrus SASL documentation.

I removed "dnl" from beginning of the following 2 lines to uncomment them:

dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

The relevant lines were then as follows:

define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

I then rebuilt the sendmail.cf file from the sendmail.mc file using m4 /etc/mail/sendmail.mc > /etc/mailsendmail.cf. I then restarted sendmail with /etc/init.d/sendmail restart.

When I then used telnet to connect to the SMTP port, port 25, on the server, I saw AUTH listed when I issued the ehlo command.

# telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 example.com ESMTP Sendmail 8.13.8/8.13.8; Tue, 6 May 2008 13:44:58 -0400
ehlo laptop
250-example.com Hello localhost.localdomain [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP

Testing with SimpleCheck, I was then able to send a message with it configured to use the PLAIN or the LOGIN authorization mechanism.

References:

1. SMTP AUTH in sendmail 8.10-8.13
   sendmail.org
2. Cyrus SASL for System Administrators
   SEPP Application Catalog
3. sendmail AUTH_OPTIONS
   lists.freebsd.org Mailing Lists
4. Using SMTP AUTH and STARTTLS with sendmail
   A quick start guide for Red Hat/Fedora Linux
   joreybump.com

[/network/email/sendmail] permanent link

# local-host-names - include all aliases for your machine here.
example.com

Then create the local-host-names.db file with makemap hash /etc/mail/local-host-names < /etc/mail/local-host-names . When you restart sendmail, which you can do with /etc/init.d/sendmail restart, sendmail will then accept email for example.com addresses.

Be aware that if you have an account jsmith which previously would receive email addressed to jsmith@someexample.com, that email addressed to jsmith@example.com will now go there as well.

[/network/email/sendmail] permanent link

The steps below can be taken on a Linux system running sendmail to have it send email via a "smart host" server. In essence, instead of the sendmail server sending email directly to other email servers, it transmits all email to another server, the "smart host", which handles the task of transmitting the received email to the recipients' servers.

In /etc/mail/sendmail.mc, look for the following section:

dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
dnl define(`SMART_HOST', `smtp.your.provider')dnl
dnl #

Remove the dnl from the beginning of the dnl define(`SMART_HOST', `smtp.your.provider')dnl line and replace smtp.your.provider with the smart host you will be using, e.g. mail.example.com.

define(`SMART_HOST', `mail.example.com')dnl

In /etc/mail/access add the following line, substituting the actual SMTP server you will need to use for mail.example.com and your actual username and password on the smart host server for myloginname and mypasswd:

Authinfo:mail.example.com "U:myloginname" "P:mypasswd" "M:Plain"

Then regenerate the /etc/mail/access.db file with makemap hash /etc/mail/access </etc/mail/access. Regenerate /etc/mail/sendmail.cf with m4 /etc/mail/sendmail.mc > /etc/mailsendmail.cf. Then restart sendmail with service sendmail restart or /etc/init.d/sendmail restart.

Once you have taken the above steps, you can send a test message from the system. Sending one to a test email address on another system that will allow you to view the message headers is ideal. At the destination, look at the message headers for the email you sent. You should see it passing through the smart host.

When I sent out a test message after making the changes above, the message didn't reach the destination. I checked the mail queue with mailq and saw the message had not gone out because of an "AUTH failure".

# mailq
                /var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
m43M1HT8032701       31 Sat May  3 18:01 <johnsmith@myserver.com>
                 (Deferred: Temporary AUTH failure)
                                         <melvin@example.com>

I had sendmail attempt to send the queued message immediately and display information on its progress with sendmail -q 0 -v (the -v provides "verbose" information).

# sendmail -q 0 -v

Running /var/spool/mqueue/m43M1HT8032701 (sequence 1 of 1)
... Connecting to smtp.atlanticbb.net. via relay...
220 ECHO Labs SMTP Service - MX01
>>> EHLO myserver.com
250-BL-106 says EHLO to 72.45.13.244:1097
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-AUTH=LOGIN
250 AUTH LOGIN
>>> QUIT
221 BL-106 closing connection
... Deferred: Temporary AUTH failure
Closing connection to smtp.atlanticbb.net.

In this case I was using smtp.atlanticbb.net as the smart host. I could see it supports an AUTH type of "LOGIN", but I didn't see "PLAIN" listed. I edited /etc/mail/access, replacing "M:Plain" with "M:Login".

Authinfo:smtp.atlanticbb.net "U:myloginname" "P:mypasswd" "M:Login"

I then ran makemap hash /etc/mail/access < /etc/mail/access again. Then when I had sendmail process the mail queue immediately again, the message was successfully transmitted.

# sendmail -q 0 -v

Running /var/spool/mqueue/m43M1HT8032701 (sequence 1 of 1)
... Connecting to smtp.atlanticbb.net. via relay...
220 ECHO Labs SMTP Service - MX02
>>> EHLO myserver.com
250-BL-206 says EHLO to 72.45.13.244:2430
250-8BITMIME
250-PIPELINING
250-AUTH=LOGIN
250-AUTH LOGIN
250 ENHANCEDSTATUSCODES
>>> AUTH LOGIN
334 VXNlcm4hcWU6
>>> bW9vbnBvbW40
334 UGFzc2dvdmQ6
>>> MVN0b2A1Njd=
235 Authed. Go on.
>>> MAIL From:
250 MAIL FROM accepted
>>> RCPT To:
>>> DATA
250 Recipient Accepted - Will relay per rbIP
354 continue.  finished with "\r\n.\r\n"
>>> .
250 OK D4/2C-23466-1B9EC184
... Sent (OK D4/2C-23466-1B9EC184)
Closing connection to smtp.atlanticbb.net.
>>> QUIT
221 BL-206 closing connection

[/network/email/sendmail] permanent link

I.e., if you can use telnet 127.0.0.1 25 and see the sendmail banner, but when you use telnet 192.168.0.44 25 (presuming 192.168.0.44 is the IP address for the mail server), you get "connection refused" messages, then the default configuration option in sendmail.mc is likely preventing the connection by causing sendmail to only listen on the loopback address.

# telnet 192.168.0.44 25
Trying 192.168.0.44...
telnet: connect to address 192.168.0.44: Connection refused
telnet: Unable to connect to remote host: Connection refused

To resolve the problem, look for the following lines in sendmail.mc , which on a Linux system will likely be in the /etc/mail directory.

dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

Edit the sendmail.mc file from the root account. Put a dnl # at the beginning of the DAEMON_OPTIONS line to comment out the line.

dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

Then issue the following commands:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
/etc/init.d/sendmail restart

The first command rebuilds the .cf configuration file from the modified .mc file. The second restarts sendmail so that it is using the new configuration file.

[/network/email/sendmail] permanent link

I edited /etc/mail/access and added the line below:

someuser@frostdragon.com                  550 Mailbox disabled for this recipient

someuser@frostdragon.com                  REJECT

After executing the command makemap hash /etc/mail/access </etc/mail/access to rebuild the access database file, you can test the block by establishing a telnet connection to port 25 on the server, issuing an helo or ehlo command, then a mail from command with any address as the "from" address, and then a rcpt to command with the relevant recipient address.

mail from: someone@example.com
250 2.1.0 someone@example.com... Sender ok
rcpt to: someuser@frostdragon.com
550 5.0.0 someuser@frostdragon.com... Mailbox disabled for this recipient
rcpt to: someuser@moonpoint.com
250 2.1.5 someuser@moonpoint.com... Recipient ok
quit
221 2.0.0 frostdragon.com closing connection

From the above, I can see that email to the address I wanted marked as invalid is rejected immediately, but email to the same username at a different domain name gets through. Mail with a "from" address of someuser@frostdragon.com would still be accepted, even though it is now rejected as a "to" address.

Since I don't want the server to accept email if that address appears as a "from" address either, I added the line below to /etc/mail/access as well and rebuilt the access database with makemap hash /etc/mail/access </etc/mail/access.

From:someuser@frostdragon.com             550 We don't accept mail from spammers

If you try sending using a "from" address of someuser@frostdragon.com now, the message will be rejected. However, if you test the block by the telnet e.g. telnet frostdragon.com 25 and then issuing an ehlo or helo command followed by mail from and rcpt to commands, you won't see the rejection message until you've entered the rcpt to command, i.e. it doesn't occur when the mail from command is issued.

mail from:<someuser@frostdragon.com>
250 2.1.0 <someuser@frostdragon.com>... Sender ok
rcpt to:<myself@moonpoint.com>
550 5.0.0 <myself@moonpoint.com>... We don't accept mail from spammers

References:

1. FEATUREs for check_* in sendmail 8.9
   Sendmail.Org
2. Configuring sendmail to Reject Unsolicited Mail
   HP Technical Documentation
3. Anti-Spam Configuration Control
   Sendmail.Org
4. SMTP Service Extension for Returning Enhanced Error Codes
   The Internet Engineering Task Force (IETF)
5. 22.6. The /etc/mail/access and access.db files
   Securing and Optimizing Linux
   RedHat Edition -A Hands on Guide

[/network/email/sendmail] permanent link

Aug 16 23:37:57 frostdragon sendmail[3738]: l7H3ak69003738: collect: premature EOM: unexpected close
Aug 16 23:37:57 frostdragon sendmail[3738]: l7H3ak69003738: collect: unexpected close on connection from mail6.tcusa.com, sender=<orders@example.com>

I had also been receiving reports from others that sending even small messages sometimes takes a long time. A couple of times when I checked the number of SMTP connections to the server with netstat -a | grep smtp | wc -l, I found over 60 connections from other email servers. Previously, I would find that there would usually be no more than a dozen such connections at any give time. And, if I connected to the SMTP port with telnet mail.example.com 25, I would sometimes see fairly slow responses.

In searching for information on the problem, I found Sendmail ‘collect: premature EOM: unexpected close’ solution . The author was encountering the same problem, which he traced to the use of a defunct DNSBL, relays.ordb.org. Like the author, I have been using relays.ordb for a long time to block incoming spam to the server. In the /etc/mail/sendmail.mc file on the server, I have the following line.

FEATURE(`dnsbl', `relays.ordb.org', `"550 Mail from " $`'&{client_addr} " refused due to sending server misconfiguration - see http://www.ordb.org/faq/\#why_rejected"')dnl

I removed the above line from /etc/mail/sendmail.mc, but added another DNSBL in its place, the Abusive Hosts Blocking List (AHBL), which I found listed at HOWTO: Sendmail tips for Ensim, by adding the following line to /etc/mail/sendmail.mc.

FEATURE(dnsbl,`dnsbl.ahbl.org', `"550 Host is on the AHBL - Please see [url]http://www.ahbl.org/tools/lookup.php?ip=[/url]"$&{client_addr}')dnl

I then took the following steps to update sendmail's configuration information so that it no longer checks the relays.ordb.org blocklist, but uses the AHBL list instead.

1. I issued the command below
   
   m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
   
   
2. I then stopped and restarted sendmail with the command below
   
   /etc/init.d/sendmail restart

According to DNS Blacklist ORDB.org is shutting down the relays.ordb.org DNSBL has been shut down since December 18, 2006. When I tried pinging it, I don't get a response and an nslookup on the name returns an error message as well.

# nslookup relays.ordb.org
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
;; connection timed out; no servers could be reached

I'm using 5 other blocklists as well, so I checked all of them by pinging them to ensure that no other blocklists that I am using have disappeared. I got responses for all of them, but that just verifies that a system is functioning at the address pinged. To check whether a system is actually functiong as a DNSBL at that address, you should issue use the nslookup, host, or dig commands to query the system using a query in the form 2.0.0.127.blacklist.example.com. All of the commands should result in the address 127.0.0.2 being displayed as the IP address for the query. This is because DNSBL's normally work by storing the IP address of systems to be blocked as reversed mappings so that queries are submitted akin to how you would do a reverse lookup for an in-addr.arpa query (see Chapter 9: Howto Create a DNSBL (DNS Black List), if you wish further details on how DNSBL's work). Since the convention is for DNSBL's to always have the address 127.0.0.2 in the list, querying for that address allows for easy testing. E.g. for AHBL, I could use 2.0.0.127.dnsbl.ahbl.org with nslookup, host, or dig.

# nslookup 2.0.0.127.dnsbl.ahbl.org
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
Server:         207.233.128.10
Address:        207.233.128.10#53

Non-authoritative answer:
Name:   2.0.0.127.dnsbl.ahbl.org
Address: 127.0.0.2

# host  2.0.0.127.dnsbl.ahbl.org
2.0.0.127.dnsbl.ahbl.org has address 127.0.0.2

# dig +short  2.0.0.127.dnsbl.ahbl.org
127.0.0.2

For checking whether a particular IP address is in one of the blacklists, you would reverse the address and then put a period and the name of the blacklist after it when issuing an nslookup, host, or dig query. E.g., if I wanted to find out whether the addresses 62.30.35.75 and 62.30.35.76 are in the Composite Blocking List (CBL), I could use the commands below.

# host 75.35.30.62.cbl.abuseat.org
75.35.30.62.cbl.abuseat.org has address 127.0.0.2
# host 76.35.30.62.cbl.abuseat.org
Host 76.35.30.62.cbl.abuseat.org not found: 3(NXDOMAIN)

From the results, I see that the first address is in the CBL DNSBL, but the second address is not in the blacklist.

Checking other blacklists, aka blocklists, I'm using by querying for the presence of 127.0.0.2 in the lists, I found that opm.blitzed.org is no longer functioning either.

# host 2.0.0.127.opm.blitzed.org
;; connection timed out; no servers could be reached

At OPM status, I learned that opm.blitzed.org has also been shut down. It was shut down in May 2006. Details on the shutdown have been posted at [opm-announce] opm.blitzed.org has shut down.

So I removed the line below from /etc/mail/sendmail.mc.

FEATURE(`dnsbl', `opm.blitzed.org', `"550 Mail from " $`'&{client_addr} " refused - see http://opm.blitzed.org"')dnl

After verifying all of the other blacklists I was using in sendmail.mc still worked, I then rebuilt the sendmail.cf file with the m4 command as above and then restarted sendmail again.

References:

1. Sendmail ‘collect: premature EOM: unexpected close’ solution
   Posted by plattapuss on February 28th, 2007
   Out of Control Image
2. DNSBL
   Wikipedia, the free encyclopedia
3. Abusive Hosts Blocking List
4. HOWTO: Sendmail tips for Ensim
   Posted By: pblinux
   Posted: December 1, 2003
   The Planet Forums
5. DNS Blacklist ORDB.org is shutting down
   Article ID: KBID002925
   GFI Knowledge Base
6. Chapter 9: Howto Create a DNSBL (DNS Black List)
   ZyTrax, Inc.
7. Composite Blocking List
8. OPM Status
   Blitzed Wiki
9. [opm-announce] opm.blitzed.org has shut down
   Posted By: Andy Smith grifferz at blitzed.org
   Posted: May 7, 2006
   lists.blitzed.org Mailing Lists

[/network/email/sendmail] permanent link

I didn't know how to check the expiration date until I found instructions for checking the expiration at Renew SSL certificate in RedHat 9. Sugree, the author of that webpage, suggested running the command openssl x509 -in sendmail.pem -text | grep Not. The instructions were written for a RedHat 9 system. When I ran the command, I saw the following results.

# cd /usr/share/ssl/certs
[root@frostdragon certs]# openssl x509 -in sendmail.pem -text | grep Not
    Not Before: Nov  9 21:26:57 2003 GMT
    Not After : Nov  8 21:26:57 2004 GMT

The author then recommended using the command openssl x509 -in sendmail.pem -text | grep Subject. It produced the following results on my server.

[root@frostdragon certs]# openssl x509 -in sendmail.pem -text | grep Subject
Subject: C=US, ST=Maryland, L=Annapolis, O=MoonPoint, CN=frostdragon.com/emailAddress=support_999@frostdragon.com
Subject Public Key Info:
    X509v3 Subject Key Identifier:

The information above will be needed when you generate a new certificate. I deleted the /usr/share/ssl/certs/sendmail.pem file and generated a new one with make sendmail.pem, which I ran from /usr/share/ssl/certs. The bold text items are the responses I entered to queries and repeat the information I saw when I ran openssl x509 -in sendmail.pem -text | grep Subject.

[root@frostdragon certs]# make sendmail.pem
umask 77 ; \
PEM1=`/bin/mktemp /tmp/openssl.XXXXXX` ; \
PEM2=`/bin/mktemp /tmp/openssl.XXXXXX` ; \
/usr/bin/openssl req -newkey rsa:1024 -keyout $PEM1 -nodes -x509 -days 365 -out $PEM2 ; \
cat $PEM1 >  sendmail.pem ; \
echo ""    >> sendmail.pem ; \
cat $PEM2 >> sendmail.pem ; \
rm -f $PEM1 $PEM2
Generating a 1024 bit RSA private key
...........++++++
..............................................++++++
writing new private key to '/tmp/openssl.Ipeqjd'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Maryland
Locality Name (eg, city) [Newbury]:Annapolis
Organization Name (eg, company) [My Company Ltd]:MoonPoint
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:frostdragon.com
Email Address []:support_999@frostdragon.com

When I then checked the expiration of the sendmail.pem certificate, I saw the following.

[root@frostdragon certs]# openssl x509 -in sendmail.pem -text | grep Not
    Not Before: Aug  8 02:41:22 2007 GMT
    Not After : Aug  7 02:41:22 2008 GMT

So now I've got a certificate that is good for another year.

References:

1. Transport Layer Security
   Wikipedia, the free encyclopedia
2. Renew SSL certificate in RedHat 9
   By Sugree
   howforge.com | Share Know-How

[/network/email/sendmail/tls] permanent link