SMTP test needs much more capability 🔗 link

I have been chasing down the following.  The first is the smtp status reported on the xymon status page (which is green), debian package version 4.3.0-0.beta2. The second is a corresponding message from mail.log on the Postfix (2.7.1 debian package) server.

220 nexus2.example.com ESMTP Postfix (Debian/GNU)
503 5.5.1 Error: send HELO/EHLO first
221 2.0.0 Bye

May 20 10:08:15 nexus2 postfix/smtpd[8689]: improper command pipelining after MAIL from mcp.example.com[10.2.1.39]

After a lengthy exchange with Wietse Venema on the postfix-users mailing list, I got to the bottom of it, and there's no problem with postfix.  The 503 error is because Xymon does not send a HELO.  I've determined that if I send the following, I can avoid the 503 error:

helo xymon
mail from: user-e49400df80ec@xymon.invalid
quit

If I modify the smtp test to send these strings, the "improper pipelining" message is still logged.  This is because Xymon is breaking SMTP rules by not waiting for the response to each command before sending the next one.  There are no longer any errors logged during the actual SMTP session, because I have added the xymon server to a list that allows it to get away with improper pipelining, and to another one that lets it send invalid HELO strings and FROM addresses.

This would be a problem if I had to monitor a remote postfix server whose configuration I could not control, though.  The only reason that the test passes is that the string it looks for (220) is returned in the initial banner, before any SMTP commands are sent.  It is not actually a real test.  Any number of postfix configuration errors would keep the server from working, yet still return the banner on initial connect.

Does anyone know how to make Xymon smart enough to wait for a defined response on each command before sending the next, and to put custom commands into a config file, rather than built in at compile time via protocols.cfg?  Ideally it would be able to understand that any 4nn or 5nn code is a problem as well.  I will take a look at the code, but my programming skills are rusty.

Thanks,
Shawn

Add an "expect" clause in your bb-services entry after the "send helo"
clause.  I have an "expect "220" as that is the response I get from a
helo being sent to our Exchange server.b  The response you get will
probably be different.

      .....Bruce
  

 
 Bruce White
 Senior Enterprise Systems Engineer | Phone: X-XXX-XXX-XXXX | Fax: XXX-XXX-XXXX | user-58f975e8bf9d@xymon.invalid | http://www.fellowes.com/
 
 
 
Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
 
-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf
Of Shawn Heisey
Sent: Friday, May 20, 2011 11:32 AM
To: xymon at xymon.com
Subject: [Xymon] SMTP test needs much more capability

I have been chasing down the following.  The first is the smtp status reported on the xymon status page (which is green), debian package version 4.3.0-0.beta2. The second is a corresponding message from mail.log on the Postfix (2.7.1 debian package) server.

220 nexus2.example.com ESMTP Postfix (Debian/GNU)
503 5.5.1 Error: send HELO/EHLO first
221 2.0.0 Bye

May 20 10:08:15 nexus2 postfix/smtpd[8689]: improper command pipelining after MAIL from mcp.example.com[10.2.1.39]

After a lengthy exchange with Wietse Venema on the postfix-users mailing

list, I got to the bottom of it, and there's no problem with postfix.  The 503 error is because Xymon does not send a HELO.  I've determined that if I send the following, I can avoid the 503 error:

helo xymon
mail from: user-e49400df80ec@xymon.invalid
quit

If I modify the smtp test to send these strings, the "improper pipelining" message is still logged.  This is because Xymon is breaking SMTP rules by not waiting for the response to each command before sending the next one.  There are no longer any errors logged during the actual SMTP session, because I have added the xymon server to a list that allows it to get away with improper pipelining, and to another one that lets it send invalid HELO strings and FROM addresses.

This would be a problem if I had to monitor a remote postfix server whose configuration I could not control, though.  The only reason that the test passes is that the string it looks for (220) is returned in the

initial banner, before any SMTP commands are sent.  It is not actually a

real test.  Any number of postfix configuration errors would keep the server from working, yet still return the banner on initial connect.

Does anyone know how to make Xymon smart enough to wait for a defined response on each command before sending the next, and to put custom commands into a config file, rather than built in at compile time via protocols.cfg?  Ideally it would be able to understand that any 4nn or 5nn code is a problem as well.  I will take a look at the code, but my programming skills are rusty.

Thanks,
Shawn

Never mind


 
 Bruce White
 Senior Enterprise Systems Engineer | Phone: X-XXX-XXX-XXXX | Fax: XXX-XXX-XXXX | user-58f975e8bf9d@xymon.invalid | http://www.fellowes.com/
 
 
 
Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
 
-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of White, Bruce
Sent: Friday, May 20, 2011 12:11 PM
To: Shawn Heisey; xymon at xymon.com
Subject: Re: [Xymon] SMTP test needs much more capability

Add an "expect" clause in your bb-services entry after the "send helo"
clause.  I have an "expect "220" as that is the response I get from a
helo being sent to our Exchange server.b  The response you get will
probably be different.

      .....Bruce
  

 
 Bruce White
 Senior Enterprise Systems Engineer | Phone: X-XXX-XXX-XXXX | Fax: XXX-XXX-XXXX | user-58f975e8bf9d@xymon.invalid | http://www.fellowes.com/
 
 
 
Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
 
-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf
Of Shawn Heisey
Sent: Friday, May 20, 2011 11:32 AM
To: xymon at xymon.com
Subject: [Xymon] SMTP test needs much more capability

I have been chasing down the following.  The first is the smtp status reported on the xymon status page (which is green), debian package version 4.3.0-0.beta2. The second is a corresponding message from mail.log on the Postfix (2.7.1 debian package) server.

220 nexus2.example.com ESMTP Postfix (Debian/GNU)
503 5.5.1 Error: send HELO/EHLO first
221 2.0.0 Bye

May 20 10:08:15 nexus2 postfix/smtpd[8689]: improper command pipelining after MAIL from mcp.example.com[10.2.1.39]

After a lengthy exchange with Wietse Venema on the postfix-users mailing

list, I got to the bottom of it, and there's no problem with postfix.  The 503 error is because Xymon does not send a HELO.  I've determined that if I send the following, I can avoid the 503 error:

helo xymon
mail from: user-e49400df80ec@xymon.invalid
quit

If I modify the smtp test to send these strings, the "improper pipelining" message is still logged.  This is because Xymon is breaking SMTP rules by not waiting for the response to each command before sending the next one.  There are no longer any errors logged during the actual SMTP session, because I have added the xymon server to a list that allows it to get away with improper pipelining, and to another one that lets it send invalid HELO strings and FROM addresses.

This would be a problem if I had to monitor a remote postfix server whose configuration I could not control, though.  The only reason that the test passes is that the string it looks for (220) is returned in the

initial banner, before any SMTP commands are sent.  It is not actually a

real test.  Any number of postfix configuration errors would keep the server from working, yet still return the banner on initial connect.

Does anyone know how to make Xymon smart enough to wait for a defined response on each command before sending the next, and to put custom commands into a config file, rather than built in at compile time via protocols.cfg?  Ideally it would be able to understand that any 4nn or 5nn code is a problem as well.  I will take a look at the code, but my programming skills are rusty.

Thanks,
Shawn

On Fri, May 20, 2011 12:31, Shawn Heisey wrote:

There have been conversations on the list about this in the past, and I
think Henrik said that getting rid of the issue entirely would require
recoding the network tester to be able to use a series of expects.  I
think that the cleanest you can get currently is to remove the send
section from the smtp test, letting xymon be happy with the initial 220,
but the server will still log a NOQUEUE because no commands were issued by
the client.