Sendmail problem: Keep getting NOQUEUE errors.

October 1, 2004 4:20 PM

Sendmail problem: Keep getting NOQUEUE errors. [more inside]

I've got Sendmail running on Linux.... generally problem free now for a couple of years or more. Recently some problems have cropped up that have me banging my head against the wall. Hoping someone can help?

The gist of it is that, while everything else seems to be running smoothly, mail from some places does not get thru. In many cases, I suspect this is due to spammers sending from fake domains, or something like that, but other times it is mail from someone well known, like eBay. I get this line in the logs a lot:

NOQUEUE: mxpool19.ebay.com [66.135.197.25] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Is there some sort of timeout setting I can tweak to clear up these log jams? As time goes on, its happening more and more and more, and I can't find any useful info on the subject from the usual sources. Originally I thought it was because I was using the Spamhaus blacklist, but I took that out and no change.

Any thoughts, theories, tips, tricks, or pointers would be most appreciated!

posted by spilon to computers & internet (7 comments total)

not really any help, but i've foud exim pretty reliable. i believe it emulates sendmail if called as sendmail, so you might try it with your current config (but don't quote me on that).
posted by andrew cooke at 4:39 PM on October 1, 2004

If the remote end didn't issue a MAIL command during the session, no mail was submitted. You might want to check exactly what kind of chatter is going on but I suspect it's the remote end just making a connection but not actually sending a mail, perhaps for checking if there's an SMTP server running. Are you sure this is the cause of mail not getting through?

ALso, exim doesn't work with sendmail config files, nothing but sendmail does (And for a good reason, those things are extremely complex), it only emulates the /usr/bin/sendmail interface, which means clients programs don't need to be changed. The good news is if you have a simple mail setup it shouldn't be much effort to switch to a different mail transfer agent, which will probably make life a lot easier for you and also the frequency with which you have to upgrade to patch vulnerabilities. The MTA I'd advise is postfix however, it has some extra security features out of the box and is more modular. Matter of taste though, I suppose.
posted by fvw at 8:47 PM on October 1, 2004

I suspect it's the remote end just making a connection but not actually sending a mail...

Well, that's what I thought, until I started watching it closer. I used the eBay example, because it was very easy to watch it happen. I bid on something, and then from that point on, I got the NOQUEUE message I pasted above in the log about every two minutes all day long, until about 7 hours later when the bid confirmation message was finally delivered to me. There were many other messages today that followed this same pattern, mostly from eBay and cox.net. I've been banging my head against this all day long, with little to show for it. I suppose I could install a whole new MTA from scratch, but I'd really rather not if at all possible. I also just sort of hate to give up on the search for an answer.....
posted by spilon at 9:37 PM on October 1, 2004

Could it be severe lag, are you saturating your link or something? If the remote SMTP client doesn't get a 220 "Ok I'm here start talking" message from your server in time it'll decide the connection is borked and tear it down to try again later.
posted by fvw at 10:49 PM on October 1, 2004

(you know about ngrep? it's a wonderful tool for watching protocols like this at work, which can really help understand errors).
posted by andrew cooke at 5:32 AM on October 2, 2004

Sever lag is a definite possibility, not sure how to test it or tweak it though. Any tips or things to look for?

No, I don't know about ngrep.

Off to Google I go.
posted by spilon at 8:36 AM on October 2, 2004

Ngrep is nice, but if you have X you might as well use ethereal, which does proper tcp stream reassembly. Especially if there is packet loss, this might be more enlightening.

As for checking for lag, just keep an eye on your mail log and when this message crops up try pinging the remote host (from the mail server) and see if there's any packet loss. (Ideally you'll want to use hping, as ICMP might be given priority by one of the intermediate systems).

If there is indeed packetloss occuring, use a tool like mtr to see where it's occuring. Either complain to those responsible, fix the hardware in question, or if it's just congestion due to overloading of a link by you, set up traffic shaping.

All tools mentioned should be easily googleable, otherwise feel free to ask.
posted by fvw at 12:01 PM on October 2, 2004