On 11/20/2010 7:19 PM, Xymon User in Richmond wrote:

The test is in netservices.c. You could try patching in a HELO before the MAIL command. Or check postfix's main.cf for reject_unauth_pipelining directive. Not sure what removing it might result in for everything else. The "feature" of logging this for every occurrence appears to have been introduced in 2.6.

I do have that in my configuration. It's an important part of spam fighting, and it's something that I am not willing to turn off. Many spam clients will just send the entire SMTP conversation at once, for speed. That directive keeps those clients from being able to get through.

The real problem is *not* the missing HELO. It's caused by Xymon sending the QUIT before the server has responded. I tried a manual session where I sent MAIL, then after it responded, sent QUIT. The message was not logged.

Thanks, Shawn

On 11/21/2010 8:36 AM, White, Bruce wrote:

You can change what Xymon sends during an smtp test by editing the <install dir>/etc/bb-services file.

That helped me eliminate the error from the log. I put in this for smtp with a similar setup for smtps, it seems to work:

[smtp] send "mail\r\n" expect "503" send "quit\r\n" expect "220" options banner port 25

This does not actually work completely as expected. After I looked at what it was doing, I would have expected it to fail, because the last thing the server says is "221 2.0.0 Bye". This doesn't seem to matter, the 220 that it received as part of the initial banner was enough to make the test succeed. If the test were working as I had expected, this would be the correct configuration:

[smtp] expect "220" send "mail\r\n" expect "503" send "quit\r\n" expect "221" options banner port 25

With either of the configs above, the "503" error from the mail command is not shown in the results on the webpage.

Thanks, Shawn

On 11/22/2010 2:58 PM, Henrik Størner wrote:

Not easily. The network test code in Xymon is pretty "dumb", it doesn't support a communication scenario with multiple stages. After connecting to the port, if there's a "send" string in the protocols.cfg (bb-services) file it will send that, and then it will just wait to see if the "expect" string arrives. It doesn't support multiple expect/send sequences.

In the old days, the smtp check just waited for the "220" greeting in the banner from the smtp daemon and then disconnected. However, that caused sendmail to log connections from Xymon because *that* behaviour is also not RFC-compliant. I don't know what Postfix thinks of it - you could try just commenting out the "send" string of the smtp-test in protocols.cfg.

I did get it to stop logging the nasty message using multiple send commands, with thanks to Bruce White. It sends mail, then it sends quit. This separates the two commands into separate TCP packets, which seems to be enough for Postfix. That could be because I have Xymon installed on the same machine and therefore network latency is pretty much nil. I do have multiple expect commands in the config too, but those are not handled correctly, as you said above.

I'm mostly satisfied with the current outcome, though the pedant in me does want to see multiple expect/send pairs work correctly. If that worked, many things that currently have to be handled by external scripts could be done in Xymon through config files alone.

Thanks, Shawn

On 11/23/2010 1:30 AM, Andreas Kunberger wrote:

...

I'm mostly satisfied with the current outcome, though the pedant in me does want to see multiple expect/send pairs work correctly. If that worked, many things that currently have to be handled by external scripts could be done in Xymon through config files alone. One could also put the 'reject_unauth_pipelining' in postfix main.cf after 'permit_mynetworks'

This is already in my postfix config, in that order.

The permit_mynetworks directive should bypass all later restrictions, from what I recall of reading their documentation. That would make this a postfix bug, if they are willing to see it that way. I've got my workaround in Hobbit, but I will see what I can do about filing a bug report on postfix.

Shawn