Sendmail Oddities

[Stuart Browne]

Been a while since I started a new thread :)

Anyway.

I have multiple machines running Sendmail with mail queues in excess of 8000. Using normal queue runs is impossible due to the sizes involved, but that's a whole different thread. Due to the sheer number of messages though, the time it takes to run through a queue (regardless of how it's managed) is too big.

The issue I've got is with regards to timing out individual SMTP connections to remote servers.

I've tried setting Timeout.iconnect, Timeout.aconnect, Timeout.connect and Timeout.initial to small values, but it seems as if none of them wish to actually control the connection timeout.

Has anybody had any experience with timing out these connect openings?

RHEL4, Sendmail from RH package 'sendmail-8.13.1-3.RHEL4.5'.

[Steven E. Protter]

Shalom Stuart,

I recently had this problem with some remote servers. The problem was scripted queueing of outbound messages.

The first step is to take a random look at /var/spool/mqueue and see if there is a lot of junk that does not belong.

I found if there is junk a scripted rebuild of access database based on virtusertable leads to faster reject and a drastic reduction of what is in the queue. Trying to avoid complete domain forwarding and use of user lists to build virtusertables is helpful.

If the mail is however legitimate, you may wish to work on it from sendmail.mc to change a value. I've got a 400 page book on the subject and will have to dive into it or the sendmail.org site to provide specific recommendations.

Please let me know if the traffic is mostly legitimate or not.

Regards,

SEP
Newly minted RHCE

[Stuart Browne]

It's all legit. I've got the book as well (Go the bat book!), but all the descriptions of the Timeout values are about the same.

I'm trying to avoid doing backend scripting to split the queues based on run age so that the newly added stuff has shorter queue runs etc. (as sendmail cannot do this on it's own, even with queue ordering and minqueueage).

But yea, one step at a time ;)

[Steven E. Protter]

So you have the bat book and know it doesn't really help.

define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`confTO_MAIL', `2')
define(`confTO_HELO', `2')
define(`confTO_RCPT', `2')
define(`confTO_DATAINIT', `4')
define(`confTO_DATABLOCK', `4')
define(`confTO_DATAFINAL', `4')
define(`confTO_QUIT', `1')
define(`confTO_AUTH', `1')
define(`confMAX_RCPTS_PER_MESSAGE', `4')
define(`confSMTP_MAILER_MMAXRCPTS', `4')

This section should help:

dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
dnl define(`confQUEUE_LA', `12')dnl
dnl define(`confREFUSE_LA', `18')dnl

Hopelly this is not the section you tried.


The above parameters drive spammers happy.

I'm still not clear if this traffic is legitimate or not. If its not, all deliveralbe mail is usually off the system in a minute or so thereby leaving anything over a certain age as a candidate for deletion using a cron job.

SEP