On 5/18/2011 10:30 PM, Noel Jones wrote:
On 5/18/2011 8:11 PM, Shawn Heisey wrote:
monitor.example.com[10.2.1.39]: 503 5.5.1 Error: send
HELO/EHLO first
But that's a different error message. For this, you need to set
# main.cf
smtpd_helo_required = no
(which is the default). This setting is not affected by
permit_mynetworks, nor any other smtpd_*_restrictions settings.
Thank you. This gets me a lot closer. I need to change what Xymon
sends, which is easy enough to do. I need to upgrade it to the newest
version anyway, might as well tinker with the source code at the same time.
However, I am still having a similar problem even when I add a helo and
use proper commands. This time it looks like it's because I am
emulating Xymon and pasting these three commands all at once. This is
against SMTP pipelining rules because you're supposed to wait for a
response after each command. The "improper command pipelining" message
is not logged if I manually do the three commands and wait for
responses. I'm stuck, because Xymon's network probes don't have the
ability to wait, and I doubt that adding this capability is trivial.
helo mcp.example.com
mail from: [email protected]
quit
Here's what this looks like in context:
mcp:/usr/src# telnet ns2 25
Trying 10.8.0.22...
Connected to ns2.example.com.
Escape character is '^]'.
220 nexus2.example.com ESMTP Postfix (Debian/GNU)
helo mcp.example.com
mail from: [email protected]
quit
250 nexus2.example.com
250 2.1.0 Ok
221 2.0.0 Bye
Connection closed by foreign host.
Here's the level 9 peer debug from that session:
http://pastebin.com/7sfpDqXa
For the world at large, I want to require correct pipelining, but have a
mechanism to bypass it for certain hosts. I might end up using
check_client_access instead of permit_mynetworks, because I don't want a
zombified internal Windows client to be able to break the rules, just my
monitoring system.
Can you look into whether this is unique to Debian? If it's not, do you
consider it to be a bug?
Thanks,
Shawn
