|Main Archive Page > Month Archives > postfix-users archives|
On Fri, Mar 23, 2012 at 12:43 PM, Giles Coochey <email@example.com> wrote:
> On 23/03/2012 15:37, francis picabia wrote:
>> On Fri, Mar 23, 2012 at 11:33 AM, francis picabia<firstname.lastname@example.org>
>>> 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: 6E7211F44DD:
>>> Mar 21 15:01:30 thabit postfix-internal/cleanup: 6E7211F44DD:
>>> Mar 21 15:01:30 thabit postfix-internal/qmgr: 6E7211F44DD:
>>> from=<email@example.com>, size=6449, nrcpt=1 (queue active)
>>> Mar 21 15:01:30 thabit postfix-internal/lmtp: 2A0561F44EE:
>>> to=<firstname.lastname@example.org>, 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: 6E7211F44DD:
>>> enabling PIX workarounds: disable_esmtp delay_dotcrlf for
>>> Mar 21 15:11:30 thabit postfix-internal/smtp: 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 =
>>> 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
>> 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?
> It is a sign of the PIX firewall removing data.
> To disable:
> 1. Logon to firewall command line
> 2. type enable
> 3. enter enable password or secret
> 4. type configure terminal
> 5. use 'no fixup protocol smtp 25' to disable SMTP protocol mangling
> 6. type 'write memory' to save config to device
> 7. restart or reload the PIX firewall
Thanks, but this issue is on the remote site. Given they can receive
email from gmail and other sites, I'm not sure I can convince
them to make these changes on their firewall. There must
be another solution so that I'm sending email to them
they can digest.