On Fri, Mar 23, 2012 at 11:33 AM, francis picabia <fpica...@gmail.com> wrote: > We have a difficulty delivering to a site running a barracuda appliance. > I can email them from a gmail account, or via a telnet session, > but not via postfix on our SMTP gateway. I've contacted the remote > site from my gmail to discuss it but no progress so far. > > I have the default pix conf settings and we are running postfix 2.8.6 > > In the logs we see it times out. > > Mar 21 15:01:30 thabit postfix-internal/smtpd[9296]: 6E7211F44DD: > client=localhost[127.0.0.1] > Mar 21 15:01:30 thabit postfix-internal/cleanup[9274]: 6E7211F44DD: > message-id=<moodlepost153...@acorn.mydomain.ca> > Mar 21 15:01:30 thabit postfix-internal/qmgr[28954]: 6E7211F44DD: > from=<lms.ad...@mydomain.ca>, size=6449, nrcpt=1 (queue active) > Mar 21 15:01:30 thabit postfix-internal/lmtp[9288]: 2A0561F44EE: > to=<usern...@theirdomain.ca>, relay=127.0.0.1[127.0.0.1]:10026, > delay=189085, delays=189084/0.03/0.01/0.3, dsn=2.0.0, status=sent (250 > 2.0.0 Ok, id=09101-06, from MTA([127.0.0.1]:10027): 250 2.0.0 Ok: > queued as 6E7211F44DD) > Mar 21 15:01:30 thabit postfix-internal/smtp[9198]: 6E7211F44DD: > enabling PIX workarounds: disable_esmtp delay_dotcrlf for > barracuda1.theirdomain.ca[24.224.X.Y]:25 > Mar 21 15:11:30 thabit postfix-internal/smtp[9198]: 6E7211F44DD: > conversation with barracuda1.theirdomain.ca[24.224.X.Y] timed out > while sending end of data -- message may be sent more than once > > I saw an older article about delivering to a barracuda gateway and > tried the solution with > > smtp_discard_ehlo_keyword_address_maps = > hash:/etc/postfix-internal/smtp_discard_ehlo > > and that file containing: > > 24.224.X.Y pipelining > > This setting made no difference in the result and error. > > I wonder if the pix settings are not the right fit for this case? > > Is there a method to not use the pix workarounds for a single destination?
I read another old thread about Cisco firewalls associated with the pix workaround. When I telnet to the remote site, the response shows: 220 ************************************************************ Is this a sign of the Cisco firewall or could it be something else masked? Should I look at suppressing dkim headers?
