Xymon Mailing List Archive search

Replacing the smtp test in protocols.cfg

7 messages in this thread

list John Thurston · Thu, 24 Mar 2016 14:25:52 -0800 ·
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
list Richard Hamilton · Thu, 24 Mar 2016 18:40:15 -0400 ·
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>
quoted from John Thurston
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

list Japheth Cleaver · Thu, 24 Mar 2016 16:39:03 -0700 ·
quoted from Richard Hamilton
On Thu, March 24, 2016 3:40 pm, Richard Hamilton 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?

It could unfortunately be either of those issues. So long as the xymonnet
tester is not performing real send/expect cycles but simply pre-loading
the buffer, there's always the chance of this type of message.

I don't believe the send string is parsed for variables, however you may
be able to get away with hard-coding the current server itself there.
quoted from Richard Hamilton

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?
One option here is to place your edits in a separate file included at the
top. But generally, yes. A later one will have no effect.


HTH,
-jc
list Richard Hamilton · Fri, 25 Mar 2016 06:35:57 -0400 ·
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>
quoted from Japheth Cleaver
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

list John Thurston · Fri, 25 Mar 2016 10:12:05 -0800 ·
On 3/24/2016 3:39 PM, J.C. Cleaver wrote:
- snip -
quoted from Richard Hamilton
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?
One option here is to place your edits in a separate file included at the
top.
Dang. I hadn't thought of that.  I've now done this and the new test definitions behave as expected.

My first question, however, remains unanswered.

Is there anyone using the SMTP test for whom the test is _not_ generating smtp 50X error results?

Why is the xymon protocol test sending a blatantly invalid command "mail\r\n" to the smtp server?

The smtp verb MAIL must be followed with something to mail. Xymonnet isn't considering the response to this "send" string, only the response the smtp server gives to the initial connection. Where is the benefit of sending anything other than a "quit\r\n" to politely close the connection and free the smtp server-resources?
quoted from Richard Hamilton


-- 
    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
list Richard Hamilton · Fri, 25 Mar 2016 15:25:50 -0400 ·
Unless someone remembers the origin of that, I doubt you'll ever know for
sure why.  It might have been a workaround for some mail server quirk, or
simply a mistake.  If for some reason it works better with _any_ extra
command before QUIT, perhaps NOOP (no-op) would be the best candidate. :-)

On Fri, Mar 25, 2016 at 2:12 PM, John Thurston <user-ce4d79d99bab@xymon.invalid>
quoted from John Thurston
wrote:
On 3/24/2016 3:39 PM, J.C. Cleaver wrote:
- snip -
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?
One option here is to place your edits in a separate file included at the
top.
Dang. I hadn't thought of that.  I've now done this and the new test
definitions behave as expected.

My first question, however, remains unanswered.

Is there anyone using the SMTP test for whom the test is _not_ generating
smtp 50X error results?

Why is the xymon protocol test sending a blatantly invalid command
"mail\r\n" to the smtp server?

The smtp verb MAIL must be followed with something to mail. Xymonnet isn't
considering the response to this "send" string, only the response the smtp
server gives to the initial connection. Where is the benefit of sending
anything other than a "quit\r\n" to politely close the connection and free
the smtp server-resources?


--
   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

list Japheth Cleaver · Fri, 25 Mar 2016 15:03:41 -0700 ·
My memory is a bit hazy from back then, but there seemed to be cases where
mail servers would immediately respond with a 4xx or 5xx error state after
a MAIL from in certain cases, which would mean the service was down enough
that you'd want a banner check to note it.

That being said, it's been a while since the heyday of MTA craziness and
there are probably fewer of us running sendmail servers on single-core
Athlon's with sky-high load averages.

The MAIL command itself doesn't seem to cause errors to be logged on my
systems, but I know it has for others.

-jc
quoted from Richard Hamilton


On Fri, March 25, 2016 12:25 pm, Richard Hamilton wrote:
Unless someone remembers the origin of that, I doubt you'll ever know for
sure why.  It might have been a workaround for some mail server quirk, or
simply a mistake.  If for some reason it works better with _any_ extra
command before QUIT, perhaps NOOP (no-op) would be the best candidate. :-)

On Fri, Mar 25, 2016 at 2:12 PM, John Thurston <user-ce4d79d99bab@xymon.invalid>
wrote:
On 3/24/2016 3:39 PM, J.C. Cleaver wrote:
- snip -
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?
One option here is to place your edits in a separate file included at
the
top.
Dang. I hadn't thought of that.  I've now done this and the new test
definitions behave as expected.

My first question, however, remains unanswered.

Is there anyone using the SMTP test for whom the test is _not_
generating
smtp 50X error results?

Why is the xymon protocol test sending a blatantly invalid command
"mail\r\n" to the smtp server?

The smtp verb MAIL must be followed with something to mail. Xymonnet
isn't
considering the response to this "send" string, only the response the
smtp
server gives to the initial connection. Where is the benefit of sending
anything other than a "quit\r\n" to politely close the connection and
free
the smtp server-resources?


--
   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