Ok, I checked the code (I think), and it does NOT appear to do variable
substitutions on the send strings.
But unless an SMTP server is set up to be very strict, one can probably get
away with sending "HELO bogus"
i.e. there has to be something after HELO, but the server may not care what
that is. It's redundant with the envelope info in MAIL From: anyway, I
think.
On Thu, Mar 24, 2016 at 6:40 PM, Richard Hamilton <user-af55987f6d56@xymon.invalid>
wrote:
Actually, it's probably not just the malformed MAIL command, but the lack
of an EHLO or (for compatibility with older SMTP servers that are not
ESMTP) HELO command, e.g. HELO myhostname
Do send strings allow variables? e.g. can one do
send "HELO $MACHINEDOTS\r\nQUIT\r\n"
and have it expanded properly?
On Thu, Mar 24, 2016 at 6:25 PM, John Thurston <user-ce4d79d99bab@xymon.invalid>
wrote:
The default test in protocols.cfg is
[smtp]
send "mail\r\nquit\r\n"
expect "220"
options banner
port 25
All of my smtp servers accept the connection, return the 220 response,
and return a 50X response due to the mal-formed "mail" command. The test
result in Xymon is green because of the 220 response, but my smtp logs an
error for each connection.
I can replace the send-string with:
send "quit\r\n"
and get better behavior, but I expect that I'll need to make this change
every time I update Xymon. It does not appear that re-defining the smtp
test in a later (included) .cfg file replaces the first definition.
Two questions:
Is there anyone for whom this test is _not_ filling up the error log on
their smtp server?
If I edit the native protocol.cfg, am I correct that I'll need to replace
protocols.cfg with each code update?
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska