Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
2649 Views 6 Replies Latest reply: Sep 20, 2012 8:36 AM by theescapist RSS
kollross Newcomer 3 posts since
Nov 7, 2011
Currently Being Moderated

Nov 7, 2011 4:03 PM

Attachment Delivery

We are having problems with our Ironmail not delivery emails with medium to large attachment sizes (5MB+).


Here is what I'm seeing in the logs.  It looks like the DATA portion of the connection is created but after 5 mins or so the connection is closed.   What I don't know is if this is an issue with the Ironmail not sending the data, or the backend smtp not receiving the data.


Of note:   internally we do NOT go through Ironmail, and not noticed any delivery issues (internal smtp is postfix).


Version 6.7.2 Hotfix 6.




20111103:00:22:57|1373391|9474|Channel outbound flag -|0|

20111103:00:22:57|1373391|9475|Max retry attempts -|4|

20111103:00:22:57|1373391|9476|Starting to process msgid -|1373391|

20111103:00:22:57|1373391|9481|Processing Domain -||

20111103:00:22:57|1373391|9515|DNS Lookup Returned -|[(1, '', ('',))] fromCache=False|

20111103:00:22:57|1373391|9516|Connecting to Domain -||

20111103:00:22:57|1373391|9487|Block timeout in seconds -|300|

20111103:00:22:57|1373391|9488|Connecting to MX -||

20111103:00:22:57|1373391|9489|Connecting to A -||

20111103:00:22:57|1373391|9491|Channels Vip vipid:bindhost -|0:|

20111103:00:22:57|1373391|4099|Connecting to <BindHost:ConnectHost:ConnectPort> -|<>|

20111103:00:22:57|1373391|4139|-|Reply: '220 -- Server ESMTP (Sun Java System Messaging Server ))'|

20111103:00:22:57|1373391|9492|Connection Status <status> -|1|

20111103:00:22:57|1373391|4139|-|Sending: EHLO|

20111103:00:22:57|1373391|4139|-|Reply: '











250-XLOOP CFF1A11E248DB79ABD6F1D77785F868C


250 SIZE 0'|

20111103:00:22:57|1373391|9523|Starting SendSmtpMsg in domain -||

20111103:00:22:57|1373391|9570|BATV values are DSN_BVP_enable: <IsEnabled> mail_from: <Mail From> mdoutbound <IsOutbound> selfdeliveryMode <Delivery Mode> -||

20111103:00:22:57|1373391|4139|-|Sending: MAIL FROM:<> size=32945431|

20111103:00:22:57|1373391|4139|-|Reply: '250 2.5.0 Address and options OK.'|

20111103:00:22:57|1373391|4139|-|Sending: RCPT TO:<>|

20111103:00:22:57|1373391|4139|-|Reply: '250 2.1.5 OK.'|

20111103:00:22:57|1373391|4139|-|Sending: DATA |

20111103:00:22:57|1373391|4139|-|Reply: '354 Enter mail, end with a single ".".'|

20111103:00:27:57|1373391|9563|Exception occurred: Type=<error type> Exception=<exp>  -|<class 'ct_smtplib.SMTPServerDisconnected'>:Socket error sending DATA|

20111103:00:27:57|1373391|9525|Generating DSN||

20111103:00:27:57|1373391|9526|No DSN to be generated for this message.||

20111103:00:27:57|1373391|9561|Delivery failure. <Notification message id> : <Retry Count> -|4|

20111103:00:27:57|1373391|9506|Closing SMTP Connection||

20111103:00:27:57|1373391|9480|Finished processing msgid -|1373391|

  • ijahnke McAfee Employee 118 posts since
    May 12, 2010
    Currently Being Moderated
    1. Nov 7, 2011 7:03 PM (in response to kollross)
    Re: Attachment Delivery

    my first thought would be that it was a size issue, however I see that shouldnt be the case with the ehlo response. A packet capture would certainly shed some light here. For a timeout to occur would mean that we are not recieving any packets for 5 minutes which could be a network issue.


    Seeing that this occured after the DATA command can mean a number of things that can range from an appliance thats between the ironmail and mail server running as a transparent bridge and applying some sort of policy on the contents of the message to a  poor network or mis-matched ethernet (half-duplex).


    These are the steps I would take:


    1.) You can try running the console command "show network interface" to determine the ethernet settings:


    [McAfee]: show network interface



        ID  Intf    Type    Address         Netmask         mtu

        --  ----    ----    -------         -------         ---



    Interface-1: (MAC Address: a4:ba:db:46:f8:9c    Status: active)

           Media: (Ethernet autoselect (1000baseT <full-duplex>))

        1   1       PRIMARY   1500


        2   1       ALIAS N/A

            (Assigned To: IWM_PORTAL)

        3   1       ALIAS N/A

            (Assigned To: EUQ)



    2.) Make sure that the ironmail has a direct connection to your mail server. If you dont have a network diagram you can run a packet capture from your mail server to determine if the mac address from the ironmail is the same that you see after you run the command above.


    3.) Check the settings of your mail server, it could be set to accept and then drop a message at a certain point.


    The key thing to remember here is that it is failing after the DATA command, so at this point the packets will grow to be about 1500 bytes (depending on the network) and there is now content that can be analyzed for policy violations.

  • theescapist Newcomer 3 posts since
    Jul 13, 2012
    Currently Being Moderated
    3. Jul 13, 2012 1:01 PM (in response to kollross)
    Re: Attachment Delivery

    I see this is old, but we upgraded to hf6 and hf7 a few weeks ago and Ironmail is having issues with large emails.  Support is clueless.

  • michael2323jordan Newcomer 3 posts since
    May 19, 2011
    Currently Being Moderated
    4. Jul 13, 2012 1:24 PM (in response to theescapist)
    Re: Attachment Delivery

    ...go on...

  • theescapist Newcomer 3 posts since
    Jul 13, 2012
    Currently Being Moderated
    5. Jul 13, 2012 1:40 PM (in response to michael2323jordan)
    Re: Attachment Delivery

    It seems emails with large attachments are being stuck inbound.  We receive Alert ERROR: Service <SMTPO> Cause: <ERROR> every 5 minutes.  The messages eventually get sent, but some are taking days.  I can go in to the gui, search the queue, and release the emails... but these messages shouldn't be taking this long to leave the queue.  I've been on the phone with McAfee for hours and the last call they said the email server was taking a long time to accept the messages.  Our email admins report everything looks normal.  The only thing that changed is the HF6 and HF7.



    At: Fri, 13 Jul 2012 13:28:17

    Host: localhost

    Service: SMTPO

    Cause: ERROR

    Info: Unchanged Domain: 3 msgs (id:36582485 36596446 36596448 ) idle in between 35min 40sec and 38min 30sec



  • theescapist Newcomer 3 posts since
    Jul 13, 2012
    Currently Being Moderated
    6. Sep 20, 2012 8:36 AM (in response to kollross)
    Re: Attachment Delivery

    The solution was to set the nic to full duplex.  We're not sure if the hotfixes changed nic setting.  I only ended up discovering this because I resorted to checking basic settings.  McAfee support was little help.  They applied some support script that was supposed to fix the issue we were having, but this didn't work either.

More Like This

  • Retrieving data ...

Bookmarked By (0)


  • Correct Answers - 5 points
  • Helpful Answers - 3 points