What could be causing "lost connection after EHLO"?

[James Egan]

I have one client that cannot send email to our mail server. Everyone
else can send email to the server just fine. Here's the message in the
maillog file:

Dec 7 09:46:39 venus postfix/smtpd[18109]: connect from
outbound-smtp5.somdomain.com[62.87.54.10] Dec 7 09:46:39 venus
postfix/smtpd[18109]: lost connection after EHLO from
outbound-smtp5.somdomain.com[62.87.54.10]

After doing some research, I tried uncommenting this line in the
master.cf file:

-o smtp_helo unix y - n - - smtp o smtp_never_send_ehlo=yes

That didn't help either. I also tried removing almost all of the
smtpd_client_restrictions and smtpd_recipient_restrictions restrictions,
which did not help either. I'm beginning to think that the problem is on
the other end. Anyone have any ideas how to fix this, or troubleshoot it
better? FYI, I didn't post the output of postconf -d because I don't have
access to the server from here.

-Thanks

[Christian Winter]

James Egan wrote:
> I have one client that cannot send email to our mail server. Everyone
> else can send email to the server just fine. Here's the message in the
> maillog file:
>
> Dec 7 09:46:39 venus postfix/smtpd[18109]: connect from
> outbound-smtp5.somdomain.com[62.87.54.10] Dec 7 09:46:39 venus
> postfix/smtpd[18109]: lost connection after EHLO from
> outbound-smtp5.somdomain.com[62.87.54.10]
>
>
> After doing some research, I tried uncommenting this line in the
> master.cf file:
>
> -o smtp_helo unix y - n - - smtp o smtp_never_send_ehlo=yes

This line looks weird somehow. However, if you're the receiving
end, smtp_never_send_ehlo doesn't matter, as it's the sending client
that issues the ehlo keyword. The rule of thumb is that when you
want to influence the receiving end, any rules affecting it start
with "smtpd_" (the smtp _daemon_), as opposed to "smtp_" which means
the client side.

> That didn't help either. I also tried removing almost all of the
> smtpd_client_restrictions and smtpd_recipient_restrictions restrictions,
> which did not help either. I'm beginning to think that the problem is on
> the other end. Anyone have any ideas how to fix this, or troubleshoot it
> better? FYI, I didn't post the output of postconf -d because I don't have
> access to the server from here.

You can try adding the client to debug_peer_list, but from
experience, chances are more than high that it's the client's own
firewall that's causing the trouble.

-Chris