I am receiving the messages: sendmail[14612]: NOQUEUE: [65.112.230.34] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Should I be alarmed? How do I deny such traffic?
Am Dienstag, 5. März 2002 19:13 schrieb Shonne Beavers:
I am receiving the messages:
sendmail[14612]: NOQUEUE: [65.112.230.34] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Should I be alarmed?
Perhaps. If you are receiving more entries than 1 per hour. If you are receiving them with alternating IP-adresses. But in general: No, don't be alarmed. It *may* be a breakin attempt. It may be a probe for your sendmail version number. I could have caused messages like these. I'm a Network Administrator and sometimes I have to debug mail delivery problems. I use sometimes the telnet program to connect to remote mail server and I'm not caring everytime if my typing matches a RFC. Your sendmail is reporting a smtp connection which doesn't transferred any useful command.
How do I deny such traffic?
It's only possible if you never received and don't expect that you ever receive any useful mail from the host with that IP adress. Because I can't think of any useful block which doesn't deny every connection from that host to your mail server. My .02 EUR: Patch your system with the vendor supplied patches. Look for other unusual events. But don't put to much into a single log line. Peter
Yay, Am Dienstag, 5. März 2002 19:13 schrieb Shonne Beavers:
I am receiving the messages:
sendmail[14612]: NOQUEUE: [65.112.230.34] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
a possible reason for this (apart from a network/host scan, which is
also very likely) may be anti-spam configurations of your sendmail.
Namely RLB's and DUL's DNS blacklist feature disconnects the offending
hosts shortly after they initiated the handshake, which sometimes gives
sendmail headaches. If the problem persists, try to remove the blacklist
rules for a short period of time and check your logs.
If you run sendmail via (x)inetd and tcpd wrapper, make sure your access
rules (hosts.deny, hosts.allow, etc.) are properly set; localhost should
always be able to connect to itself, otherwise things like mail
notification/receipts may break.
Boris Lorenz
participants (3)
-
Boris Lorenz
-
Peter Wiersig
-
Shonne Beavers