Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

non RFC conform behaviour of SmtpMonitor

Description

Hi,

When I want to check a mail server with service="SMTP" OpenNMS keeps telling me that the service is down "Did not receive expected response within timeout timeout". I traced the problem and saw, that OpenNMS stop the communication after the first answer of the SMTP server.

On my server the first answer ist "220-ESMTP ..." and a CR.
After 3 seconds postfix continues with a "220 ESMTP ..." and CRLF.

According to the RFC clients have to wait until the CRLF is sent. OpenNMS does not wait. So it sees the wrong banner.

I have to reconfigure my postfix to make an exeption for my opennms server and to deliver the correct banner from the start.

I would be nice, if the problem could be fixed within OpenNMS.

Michael.

Environment

Debian 7

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Ronny Trommer April 1, 2016 at 7:45 PM

Can we delete this branch as well? https://github.com/OpenNMS/opennms/tree/pr/jira/NMS-7582

Chandra Gorantla March 30, 2016 at 1:24 PM

Changed line terminations to check for CRLF always. This will force monitor to wait for CRLF to process any info.

Jesse White March 29, 2016 at 5:04 PM

Michael Schwartzkopff March 25, 2016 at 7:22 AM

No. See: http://www.postfix.org/POSTSCREEN_README.html

A very powerful measure to prevent SPAM is to set
postscreen_greet_action = enforce

This also will prevent ONMS to monitor the SMTP service.

Chandra Gorantla March 24, 2016 at 10:30 PM

Hi Michael / Jesse,

From RFC documents, There seems to be no such hard requirement for CRLF. It advises to check based only on REPLY CODE.
Let me know if I m wrong, I m new to this so this is just based on google search not through experience on SMTP.
Quoting from the RFC standard.
https://www.ietf.org/rfc/rfc2821.txt , http://tools.ietf.org/html/rfc5321#section-4.5.3.2.1

An SMTP client MUST determine its actions only by the reply code, not
by the text (except for the "change of address" 251 and 551 and, if
necessary, 220, 221, and 421 replies); in the general case, any text,
including no text at all (although senders SHOULD NOT send bare
codes), MUST be acceptable. The space (blank) following the reply
code is considered part of the text. Whenever possible, a receiver-
SMTP SHOULD test the first digit (severity indication) of the reply
code.

Formally, a reply is defined to be the sequence: a
three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
reply (as defined in section 4.2.1). Since, in violation of this
specification, the text is sometimes not sent, clients which do not
receive it SHOULD be prepared to process the code alone (with or
without a trailing space character). Only the EHLO, EXPN, and HELP
commands are expected to result in multiline replies in normal
circumstances, however, multiline replies are allowed for any
command.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created March 24, 2015 at 5:38 PM
Updated April 1, 2016 at 7:45 PM
Resolved March 30, 2016 at 12:44 PM

Flag notifications