protocols.cfg smtp chat
Hi,
I am trying to monitor the health of a couple of smtp servers (sendmail) with a xymon instance.
As part of spam prophylaxis, these servers delay the initial response to contact by a few seconds, and drop any rogue clients that forego the handshake and just start pipelining their payload. Unfortunately, xymonnet(?) does the same, gets shown the door, and sulks with "Service smtp on $server is not OK : Unexpected service response".
I tried to play with the smtp chat in protocols.cfg
[smtp] expect "220" send "ehlo xymonnet.localdomain\r\n" expect "250" send "quit\r\n" expect "221" options banner port 25
without success. tcpdump(8)ing the communication, I was quite surprised to find that whatever I entered for the smtp chat, I always see xymon sending a 'quit', and sendmail returning a "220" banner.
This is confirmed by the xymon banner output.
My questions:
o Is it even possible for the xymon client to first wait for the server's "220" greeting before shooting off its mouth? o Where in the code does the smtp client communication happen? o What could have gone wrong for xymon to ignore the configuration in protocols.cfg without any trace in the logs?
Cheerio, Hauke
-- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
On 09/12/2024 10:10, Hauke Fath wrote:
I tried to play with the smtp chat in protocols.cfg
[smtp] expect "220" send "ehlo xymonnet.localdomain\r\n" expect "250" send "quit\r\n" expect "221" options banner port 25
without success. tcpdump(8)ing the communication, I was quite surprised to find that whatever I entered for the smtp chat, I always see xymon sending a 'quit', and sendmail returning a "220" banner.
I think you've misunderstood how protocols.cfg works. Rather than definining a series of send/expects in a conversational manner, you get to specify a single "send" string and a single "expect" string (though you can omit either or both when defining your service). See "man protocols.cfg". Also, based on past mailing list posts, if you specify multiple send/expect lines for a service in protocol.cfg it looks like in practice only the last instance of each type of line in the cfg file is used, i.e. your config is equivalent to:
[smtp] send "quit\r\n" expect "221" options banner port 25
which seems to match your described behaviour.
I think you need a custom script to perform this test rather than using a service defined in protocols.cfg (NB tests of services defined in protocols.cfg are performed by xymonnet; there's no specific code for handling smtp. The only impact of naming the service "smtp" in protocols.cfg is that that's the column name used when generating the xymon report)
Adam
On 12/9/24 04:10, Hauke Fath wrote:
As part of spam prophylaxis, these servers delay the initial response to contact by a few seconds, and drop any rogue clients that forego the handshake and just start pipelining their payload.
#beenThereDoneThat
As Adam points out, I don't think you can get Xymon to do what you're wanting.
I went the other route, configure Sendmail to not use the GreetPause for the Xymon (proxy) host doing the network tests:
Put something like the following in your access (text) file and rebuild the database file.
--8<-- GreetPause:xymonhost 0 -->8--
-- Grant. . . .
participants (3)
-
Adam Thorn
-
Grant Taylor
-
Hauke Fath