Stan, thanks for your answer. Searching heavily the list I found that this problem was related to firewall issues, specially when the firewall does a sort of SMTP (layer 7) validation or check.
I disabled some features on my H3C firewall (ASPF - Application Specific Packet Filter) related only to SMTP and everything works fine now again. I like to thanks all the other members of the list for their contribution on this issue, specially Wietse. I am surprised how some modern firewalls are poorly implemented when dealing with SMTP. Postfix really opens a wide knowledge about RFCs and all the SMTP resources. Your suggestions about reject_unauth_destination are right and now implemented in my production server. Thank you again for this advise. Regards, -- Klaus Engelmann CCNA CCDA - CSCO10971632 LPIC-2 - LPI000138061 On Fri, Aug 20, 2010 at 3:08 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: > Klaus Engelmann put forth on 8/20/2010 11:25 AM: >> Hi list, >> >> I searched the forum looking for some ideas about the following error >> that is growing increasingly in my POSTFIX deployment: >> >> Aug 20 08:41:40 prometeu postfix/smtpd[16568]: lost connection after >> EHLO from mail2.netpoint.com.br[187.16.24.50] > > I doubt this has anything to do with load. > > Look at _all_ the log entries for this transaction queue ID, and the others. > I'm guessing you'll see that the following restrictions are likely involved. > These entries are _not errors_ but are informational only. These > disconnections all occur during the helo phase, which is likely due to the > client hanging up after a Postfix rejection based on a helo restriction. > > reject_non_fqdn_helo_hostname, > reject_invalid_helo_hostname, > check_helo_access regexp:/etc/postfix/helo-blacklist/smtp_helo_blacklist, > > Also, I recommend moving reject_unauth_destination to just below > permit_sasl_authenticated. Having it after your whitelist checks, as you > currently do, could potentially make your host an open relay under some > circumstances. > > -- > Stan >
