error in sendmail standard config?
Hi I recently changed our mailserver from an old sendmail installation (SuSE 6.3 and sendmail 8.9.3) to SuSE 8.1 with sendmail 8.12.6 (with latest security-patch form SuSE of course). After that change I realized _a lot_ of entries in the mail log with "[SENDER-IP] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA" This alone would be no problem, since we know all that there are a lot of people out there probing mailservers or using strange MTAs for sending spam. _But_ from two of these sender MTAs I got complaints about being not reachable for them to send normal mail to our users! They also sent me an extract of their maillog, which looked (in both cases) like this: [senders log extract] Attempting SMTP connection to [MY-SERVERS-IP : 25] Waiting for socket connection... Socket connection established Waiting for protocol initiation... 30 second wait for protocol timeout exceeded. [/senders log extract] It looked like they have a connection timeout of 30s - and it seems that this timeout was coming from my server :-( (Funny, that both complaints came apparently from the same sort of MTA, probably MDaemon). Checking some RFCs about recommended timeouts gave me a vague information like '5 min would be nice'. But the RFC was from 1989... and to be honest, 5 minutes would be nice in 1989 but isn't it a little bit long for today? After searching the sendmail docu for the "did not issue..." error, I found a hint in the "enhdnsbl"-section of "cf/README" of sendmail version 8.12.9 (the special hint is not in the README of prior versions...): [hint] Set the EDNSBL_TO mc option to change the DNS retry count from the default value of 5, this can be very useful when a DNS server is not responding, which in turn may cause clients to time out (an entry stating did not issue MAIL/EXPN/VRFY/ETRN will be logged). [/hint] I'm not sure if taking this value from 5 to 1 really helped and I also tried to tweak the "confTO_RESOLVER_RETRANS" and "confTO_RESOLVER_RETRY" until I realized that the DNSRBL, which is activated in a standard SuSE setup (in /etc/sysconfig/sendmail, SENMAIL_DNSRBL), is "relays.orbl.org". Trying to do a manual nslookup on that list timed out after 10s!! Counting the standard values for resolving names together gave me: first try 10s + timout 5s + second try 10s + timeout 5s (and so on, until 4 retries are done) more than 60s! I assume, that this was the reason for at least _many_ of the "did not issue MAIL..." error-messages. [thank you for reading until here ;-) ] Now my question is: Am I right, with assuming that the "did not issue..." errors came from a lookup timeout? If so, shouldn't SuSE take the "relays.orbl.org" out of the default config, if it is unreachable anyway? Or did I completely miss something in my investigations? It _seems_ at least, after replacing "relays.orbl.org" with "list.dsbl.org" that the "did not issue..." error appears much fewer (but it's weekend now and therefore less traffic anyway). All comments are welcome! Patrick
The 03.04.26 at 18:07, Patrick wrote:
Counting the standard values for resolving names together gave me: first try 10s + timout 5s + second try 10s + timeout 5s (and so on, until 4 retries are done) more than 60s! I assume, that this was the reason for at least _many_ of the "did not issue MAIL..." error-messages.
Could be. Do you have a local dns server? If you don't, perhaps you could set one as cache, and perhaps the "not found" answer would be inmediate. I'm unsure of this, but you could try. I think I remember that rbl lookup was optional before, with suse 7.3, somewhere on the main mail config. I use postfix now, I can not check. -- Cheers, Carlos Robinson
At 14:41 28.04.2003 +0200, Carlos wrote:
The 03.04.26 at 18:07, Patrick wrote:
Counting the standard values for resolving names together gave me: first try 10s + timout 5s + second try 10s + timeout 5s (and so on, until 4 retries are done) more than 60s! I assume, that this was the reason for at least _many_ of the "did not issue MAIL..." error-messages.
Could be. Do you have a local dns server? If you don't, perhaps you could set one as cache, and perhaps the "not found" answer would be inmediate. I'm unsure of this, but you could try.
I use a local dns server - but I think, since the the inactive RBL is like a dead dns server, you cannot avoid the timeout.
I think I remember that rbl lookup was optional before, with suse 7.3, somewhere on the main mail config. I use postfix now, I can not check.
RBL is still optional in SuSE sendmail, but its on by default (at least in SuSE 8.1).
-- Cheers, Carlos Robinson
Thanks, Patrick
The 03.04.29 at 08:22, Patrick wrote:
Could be. Do you have a local dns server? If you don't, perhaps you could set one as cache, and perhaps the "not found" answer would be inmediate. I'm unsure of this, but you could try.
I use a local dns server - but I think, since the the inactive RBL is like a dead dns server, you cannot avoid the timeout.
Mmm :-? Yes, probably. But... that would be once you find the correct rbl server, and I think you said the default one was wrong. Once you configure the right one, then speeding it up would be a different matter, I guess. Could be documented somewhere :-? -- Cheers, Carlos Robinson
At 21:14 29.04.2003 +0200, Carlos wrote:
Could be. Do you have a local dns server? If you don't, perhaps you could set one as cache, and perhaps the "not found" answer would be inmediate. I'm unsure of this, but you could try.
I use a local dns server - but I think, since the the inactive RBL is like a dead dns server, you cannot avoid the timeout.
Mmm :-? Yes, probably. But... that would be once you find the correct rbl server, and I think you said the default one was wrong. Once you configure the right one, then speeding it up would be a different matter, I guess. Could be documented somewhere :-?
I believe that it should be possible with the following options (found them in /usr/share/sendmail/m4/proto.m4): _OPTION(Timeout.resolver.retrans, `confTO_RESOLVER_RETRANS', `5s') _OPTION(Timeout.resolver.retrans.first, `confTO_RESOLVER_RETRANS_FIRST', `5s') _OPTION(Timeout.resolver.retrans.normal, `confTO_RESOLVER_RETRANS_NORMAL', `5s') _OPTION(Timeout.resolver.retry, `confTO_RESOLVER_RETRY', `4') _OPTION(Timeout.resolver.retry.first, `confTO_RESOLVER_RETRY_FIRST', `4') _OPTION(Timeout.resolver.retry.normal, `confTO_RESOLVER_RETRY_NORMAL', `4') Lower the values for RETRANS and RETRY could lower the overall-time for dns lookups (that's my assumption...). I tried it with RETRANS of 3s and RETRY of 1, but I realized more "IP name lookup failure" messages in /var/log/mail (I 'realized', that doesn't mean that there were really more). Now I'm going with a RETRANS of 2s and a RETRY of 2 - this should be high enough for a good RBL and low enough for some other servers only waiting 30sec for an answer after the initial connect. Bad is only, that I don't know how to proof, that this config-changes really do what I want them to do. Perhaps starting sendmail in debug-mode could reveal some informations, but in _which_ debug-mode (there seem to be a lot!)? Patrick
The 03.04.30 at 18:55, Patrick wrote:
I tried it with RETRANS of 3s and RETRY of 1, but I realized more "IP name lookup failure" messages in /var/log/mail (I 'realized', that doesn't mean that there were really more). Now I'm going with a RETRANS of 2s and a RETRY of 2 - this should be high enough for a good RBL and low enough for some other servers only waiting 30sec for an answer after the initial connect.
The problem is with mails you receive, right? Then, if the system is waiting for a longer time it won't be much of a problem, because sendmail will accept more incoming connections while one of them is waiting, I think. Thus, you could increase those delays, as long as total delay is below 30". Maybe 4" and 3" (RETRANS/RETRY) would be safer :-?
Bad is only, that I don't know how to proof, that this config-changes really do what I want them to do. Perhaps starting sendmail in debug-mode could reveal some informations, but in _which_ debug-mode (there seem to be a lot!)?
I used to call sendmail with -v parameter from my ip-up script; that might be enough. Then you could edit "/etc/syslog.conf" like this: mail.notice -/var/log/mail mail.debug -/var/log/mail.debug The mail.debug file could be cycled faster than the normal mail log file, depending on your traffic; like keeping a week of logs, say. -- Cheers, Carlos Robinson
participants (2)
-
Carlos E. R. -
Patrick