perl script generates sendmail NOQUEUE: connect from root@localhost

[Jhary-a-Conel]

Hello,

I have numerous administrative scripts that contain the following
chucnk of perl:


# Mail Procedure
#
&send_mail;

sub send_mail
{
open(MAIL,"|$MAIL -s \"$SUBJECT\" admin.report\@multiverse.org");

# Test output for string
#
if($output eq "")
{
print MAIL "Good news. None of the eth devices are in PROMISC
mode. Take no action.
\n\n";
}
else
{
print MAIL "Bad news. There is an eth device in PROMISC mode.
Take immeadiate actio
n.\n\n";
}

close(MAIL);
}


When this script is run it generates the following output in
/var/log/maillog:

Jul 3 04:26:45 prod sendmail[8843]: NOQUEUE: connect from
root@localhost
Jul 3 04:26:45 prod sendmail[8843]: h63BQjj08843: from=root,
size=150, class=0, nrcpts=1,
msgid=<[email protected]>, relay=root@localhost
Jul 3 04:26:45 prod sendmail[8846]: h63BQjj08843:
[email protected], ctladdr=root (0/0), delay=00:00:00,
xdelay=00:00:00, mailer=local, pri=30150, dsn=2.0.0, stat=Sent
Jul 3 04:26:45 prod sendmail[8846]: h63BQjj08843: done;
delay=00:00:00, ntries=1

My research indicates that when a client doesn't close a connection
properly with Sendmail it throws the NOQUEUE line into the logs.
<eyeroll>I guess Outlook is a big offender </eyeroll>.

My understanding of the situation is that this is more of a report
message than an error message. But one thread suggested that there
might be network issues. Since these scripts run via crontab, my
assumption is that I have written my script poorly and that the script
is disconnecting unceremoniously or the mail client needs to be passed
something or sendmail needs to be passed a parameter that better
terminates the transaction. BTW, this is on Redhat 7.3 and I'm using
the version of mail installed by default and $MAIL='mail'

I'd like to eliminate this report message, but have a feeling the
NOQUEUE message is inconsequential. When I reduce the logging level,
the message stops being recorded. Should I ignore this and get on
with my life or what?

Also, if you see any other clueless newbie nonsense ocurring in the
above script, please let me know.

Thanks,
Jerry Cornelius

 

[Greg Bacon]

: # Mail Procedure
: &send_mail;
:
: sub send_mail
: {
: open(MAIL,"|$MAIL -s \"$SUBJECT\" admin.report\@multiverse.org");
:
: # [snip message]
:
: close(MAIL);
: }

How do you set the value of $SUBJECT? If this is a setuid program,
it would be safer to invoke sendmail -- and the qmail folks would say
it's never safe to invoke sendmail -- with the -t option, which
tells sendmail to scan the message for recipients. You're also not
checking system calls for failure.

Consider rewriting send_mail as

sub send_mail {
# XXX: or wherever sendmail is
open MAIL, "| /usr/lib/sendmail -oi -t"
or die "$0: failed fork: $!";

my $status = $output ? <<EOBad : <<EOGood;
Bad news. There is an eth device in PROMISC mode.
Take immeadiate action.

EOBad
Good news. None of the eth devices are in PROMISC
mode. Take no action.

EOGood

my $subj = $SUBJECT;
$subj =~ s/([^[rint:]]|[\r\n])+/ /g;

my $message = join "\n",
"To: admin.report\@multiverse.org",
"From: eth device monitor <root>",
"Subject: $subj",
"", # end of header
$status;

print MAIL $message or warn "$0: print MAIL: $!";

close MAIL
or warn $! ? "$0: error closing sendmail pipe: $!"
: "$0: exit status $? from sendmail";
}

Hope this helps,
Greg

 

[Per Hedeland]

When this script is run it generates the following output in
/var/log/maillog:

Jul 3 04:26:45 prod sendmail[8843]: NOQUEUE: connect from
root@localhost
Jul 3 04:26:45 prod sendmail[8843]: h63BQjj08843: from=root,
size=150, class=0, nrcpts=1,
msgid=<[email protected]>, relay=root@localhost
Jul 3 04:26:45 prod sendmail[8846]: h63BQjj08843:
[email protected], ctladdr=root (0/0), delay=00:00:00,
xdelay=00:00:00, mailer=local, pri=30150, dsn=2.0.0, stat=Sent
Jul 3 04:26:45 prod sendmail[8846]: h63BQjj08843: done;
delay=00:00:00, ntries=1

My research indicates that when a client doesn't close a connection
properly with Sendmail it throws the NOQUEUE line into the logs.

You need to redo your research then - the FAQ says:

Note 1: The significant part of the message isn't the NOQUEUE, but
the "Null connection from ...". In particular, NOQUEUE isn't an error
indication, but just a "place-holder" when no queue ID has been
assigned, typically because message collection hasn't started
(yet). It can occur in other messages too, and there too the
significant part is what comes after the NOQUEUE.

I'd like to eliminate this report message, but have a feeling the
NOQUEUE message is inconsequential. When I reduce the logging level,
the message stops being recorded. Should I ignore this and get on
with my life or what?

Right, the message does not occur at the standard/default LogLevel 9:

if (LogLevel > 9)
{
/* log connection information */
sm_syslog(LOG_INFO, NULL, "connect from %s", authinfo);
}

By raising the LogLevel from the default, you get more logging
(surprise, some of it more or less of a debugging nature - so you're
just getting what you asked for...

--Per Hedeland
(e-mail address removed)