On 05/19/2011 05:44 PM, Shawn Heisey wrote: > > 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: postmas...@mcp.example.com > 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: postmas...@mcp.example.com > 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?
>From the documentation of smtpd_data_restrictions "Optional access restrictions that the Postfix SMTP server applies in the context of the SMTP DATA command" If you do not issue the data command, don't expect the restriction to be in effect. Martijn Brinkers -- Djigzo open source email encryption
