On Mon, Mar 09, 2015 at 05:08:24PM -0400, James B. Byrne wrote:
> I have no idea what is going on.
So it seems, but you're also thinking clearly.
> This was traced from a CLI session
> on our primary MX host, inet08.hamilton.harte-lyne.ca. I do not see
> a shortened HELO in this. And it seems to have been accepted?
>
>
> swaks --to=x...@cuttingedgegrowersupply.com --from=y...@harte-lyne.ca \
> --copy-routing=cuttingedgegrowersupply.com --tls-optional
Swaks is not Postfix, and naturally sends the valid HELO name you
reported, and the remote server is of course fine with that.
Which further supports all the overwhelming evidence that the
problem is a different HELO name sent by Postfix, as a result of
a configuration issue you've not been able to identify and report.
Reports by Postfix that remote servers "refused to talk to me" can
ONLY happen when processing the remote SMTP banner or remote SMTP
ehlo/helo/lhlo response.
Since the remote server can't reasonably complain about invalid
parameters at banner time (it speaks first), the ONLY remaining
possibility (which thanks to Mr. Holmes, however implausible, must
be correct) is that HELO it is. We also see that sending this
server a non-fqdn HELO elicits exactly the response observed.
So, plausile or otherwise, we stick with logic, and figure out what
HELO name your server actually sends.
This requires "debug_peer_list = remote-address, remote-address, ..."
or a tcpdump.
--
Viktor.
