NOQUEUE messages in sendmail - related to sendmail.cw?

[Jeff Lightner_1]

Basic question:
Am I correct in thinking adding proddb and proddb.water.com to the sendmail.cw (and maybe relay-hosts) would likely prevent me from getting NOQUEUE messages for virtual server proddb?

DETAILS:
In the mail.log there are many messages of the form:
May 31 15:48:11 prod1 sendmail[29634]: NOQUEUE: Null connection from proddb.water.com [xx.xx.xx.xx]

In the above:
“prod1” = real name of the active node in a Veritas Cluster.
“proddb.water.com” = a virtual hostname used for this system (For Oracle server).
“xx.xx.xx.xx” = Obfuscated IP address for proddb.water.com.

From Google searches and reading it appears that NOQUEUE isn’t usually an issue unless one is seeing “many” of these messages.

“Many” of course being undefined but the assumption is seeing them every time an email occurs on a system that sends hundreds of emails per day would be considered “many”.

In /etc/mail there is a file called “relay-hosts” and another called “sendmail.cw” that both contain names such as
localhost
prod1
prod1.water.com

They do not contain reference to proddb or proddb.water.com.

Note on relay-hosts:
There is absolutely no mention of this anywhere in relation to sendmail in Google or the HP-UX Sendmail guide. I suspect it is either a holdover from some earlier system that possibly had an earlier version of Sendmail and/or a misconception based on relay-domains which DOES exist in Sendmail documentation. Neither sendmail.cf nor any other file in /etc/mail refer to relay-hosts. It may be something that can be ignored.

This is on HP-UX 11.11 on RP8420.
Sendmail 8.9.3 (PHNE_35484)/8.9.3

[Steven E. Protter]

Shalom,

Probably not the cause of the problem. I don't think you are adding them properly.

I would add the relay hosts to the access file and use the m4 command to generate a new sendmail.cf

I'd go to software.hp.com and get the latest sendmail and then go to http://www.sendmail.org and use their procedures to handle virtual domains.

Its 1 minute to the Sabbath here, I have no more time and will check back with you in 25 hours.

http://www.hpux.ws/builmail.hpux.text
Hope thats right.

SEP

[Jeff Lightner_1]

Thanks for your reply.

I'm not trying to relay through these hosts. In fact I relay to two other hosts using a mailer table we'd set up back in August (prior to that we just used the DS smart relay).

The email is generated by Oracle (Work Flow Manager probably) and goes OUT as if from proddb.water.com rather than prod1.water.com.

My read of the sendmail.cw is it contains all the names the local host may be known as which would include proddb. I was just hoping someone had dealt with a similar setup before and had resolved it.

[Matti_Kurkela]

NOQUEUE means that the log message is not related to any mail processed by sendmail, i.e. this connection did not cause any mail delivery work.

"Null connection from ..." gives more detail: it seems that a connection to port 25 of your host was opened and then closed without issuing any meaningful SMTP commands. It also reveals where the connection came from.

This might be caused by some sort of monitoring agent that is testing whether sendmail is alive or not.

MK

[Steven E. Protter]

Shalom again,

As promised back 25 hours later.

NONQUEUE messages in a DS relay situation indicate the relay server itself is rejecting or refusing to queue the mail. This means the logs of that server need to be looked at.

You can change the sending domain with sendmail. You can set the DJ domain in sendmail.cf or sendmail.mc in order to change the outbound domain of the mail. It may also be possible to do it by changing the hostname of the system or its DNS domain identity.

I suspect if all mail is going to a DS relay server the problem is not on the oracle server generating the mail but on the DS relay box itself.

Note: If you are covered by SOX running this sendmail release is a sure audit failure. Unrelated to this question, use the latest available sendmail from software.hp.com

SEP
Spelling improved by firefox 2.x from Ubuntu. Definitely worth it.

[Jeff Lightner_1]

Matti: My reading had gotten me that far. However it also said one shouldn't worry about such messages unless there were "many" of them (see my original post) and there ARE "many" - I see these nearly every time a message posts. I'm trying to troubleshoot the "many" as I'm assuming it has an unnecessary performance cost. The system isn't bogged down - just something I noticed while looking into another issue.

Steven: Apparently I'm missing something. This is NOT a relay host per se. All the email sent by this host is generated on this host. No email is relayed TO this host by any other host. Both the "physical host name" and the "virtual host name" are pointing to IPs on NICs on this server.

Are you saying that because the host has a virtual name in addition to a physical name I have to setup sendmail as if it were relaying from the virtual host name to the physical host name?

[Steven E. Protter]

Shalom,

What I'm saying is that if the email is traveling through the Public Internet it must have a from address that is a valid verifyable domain name or it will end its life in a spam filter database.

An aside and then back on topic.

There is little performance cost for sendmail to refuse to queue up your messages. Space is being wasted in your mail queue and eventually the mail is going to be returned to the original sender on your system.

This problem has symptoms pointing to the fact that an another server is refusing to accept mail from it.

You state the message happens every time a mail is sent this message appears.

You say this is not a relay host per say. The original configuration file you were changing relates only to the hosts this server will RELAY from external hosts. Those files do not deal with the core issue.

In most corporate firewall environments, the sendmail.cf DS directive is used to get mail of your system. To help further, I need to know if its set. If it is set, then the relay server referred to in your DS directive is probably rejecting the mail.

It is possible however that your previous configuration changes are causing the problem because the wrong configuration files were changed in the first place.

I'd back them up, clear them restart sendmail and try again. This version of sendmail does not even require the sendmail daemon to be running to send mail to external hosts. That deamon only applies to inbound mail, which I safely assume we are not dealing with.

If your sendmail.cf is not using the DS directive then the mail may be failing to queue merely because the DNS MX (mail exchange) record for the domain in question is pointing to a host that does not listen on port 25 for mail.

There is a finite possibility that the issue at hand has nothing to do with this system and is external.

SEP

[Jeff Lightner_1]

Thanks again. I fear we're getting off track with the discussion about relaying. Again NO email comes TO this host from outside this host (except possibly as bounced by our internal switch going from the virtual IP to the physical IP). All requests for validity of mailboxes come in via the internet to our Exchange server (on different IPs for the two different domains) NOT to the HP-UX host from which it originated. Outbound relay from WITHIN the HP-UX host is done by use of smarttable rather than DS due to this dual domain setup. I should mention that we are successful in mailing out from both domains from this HP-UX host. (In fact the only thing I've seen we can NOT send to is addresses in Korea and China because our Network Security blocks both those countries totally.)

We do this same dual domain on our test server and I do not see the NOQUEUE messages there and the only difference between that server and this one in this regard is we do NOT have a virtual host name being used to send email from Oracle on the test server (it uses the physical host name).

Your earlier post makes me think the issue may be Sendmail thinking of the virtual host as attempting to relay through the physical host so it may be to the point for me to focus on allowing inbound relay from the virtual host name because it isn't smart enough to realize the virtual host name is just another NIC on the same host.

Prior to that I think I'll go ahead and modify the sendmail.cw though you are likely right that it will have no effect. I'd asked the original question because my read of its purpose made me think it might not help but then again it should contain all possible "names by which this host might be known" and the virtual host name is certainly one of those.