none
Email bounces 550-'5.6.0 Lone CR or LF in headers RRS feed

  • Question

  • Today we are seeing several email bounces with following error which indicates that email wasn't properly formatted by our Exchange 2010 (fully patched) and Outlook 2016 (fully patched).

    ] #5.0.0 smtp; 5.3.0 - Other mail system problem 550-'5.6.0 Lone CR or LF in headers (see RFC2822 section 2.2)' (delivery attempts: 0)> #SMTP#

    Any idea what could be causing this? 

    <o:p></o:p>

    Monday, March 18, 2019 4:28 PM

All replies

  • Interesting, we are seeing this on a couple email addresses today also.  So far I haven't found any reason why.
    Monday, March 18, 2019 5:05 PM
  • Seeing it here on a couple addresses as well.
    Monday, March 18, 2019 5:17 PM
  • I have 2 user requests with the same error. 2 separate recipients.
    Monday, March 18, 2019 5:20 PM
  • I'm getting theses too today as well. And I can confirm no changes were made over the weekend. 
    Monday, March 18, 2019 5:20 PM
  • We are also experiencing the issue for a handful of external recipients starting today. 
    Monday, March 18, 2019 5:23 PM
  • Do you all by chance run Cisco ESA (ironports)?

    Monday, March 18, 2019 5:25 PM
  • Something is up, I had two different customers call me today saying their emails are bouncing back with the same message. What gives?  
    Monday, March 18, 2019 5:25 PM
  • I do
    Monday, March 18, 2019 5:27 PM
  • One of the emails that are failing for me are getting the response from the recipients Cisco device.
    Monday, March 18, 2019 5:29 PM
  • Same here, however in our case we are the intended recipient. In case this helps, it appears the senders we have issues with are hosted exchange users and our receiving end is rackspace (non-exchange acccount).

    Content does not matter, all messages are rejected, but we requested and received the NDR sent to a hotmail account to see the issue.

    I see Ironport headers as well, so that's in the mix.

    Monday, March 18, 2019 5:29 PM
  • I do as well
    Monday, March 18, 2019 5:30 PM
  • I'm digging deeper, and about to open a TAC case, I see the Ironport-data field has a second ":" in it, which is against the RFC, Trying to see when it started on our end.
    Monday, March 18, 2019 5:30 PM
  • Hi, we opened a TAC case with Cisco and they are aware of the issue and working on it.  They have it set as a P2 on their end.
    Monday, March 18, 2019 5:39 PM
  • I feel anyone with an ESA should call in as well, p2 seems low?
    Monday, March 18, 2019 5:41 PM
  • We have one report of this and yes, our Exchange 2016 servers have IronPorts in front of them for inbound/outbound Internet mail.
    Monday, March 18, 2019 5:41 PM
  • I validated for us at least, The ESA is the issue, If I bypass it, email flows as expected.
    Monday, March 18, 2019 5:42 PM
  • I received this message and it appears the receiving party is on a blacklist.  Have you checked the destination mx records for blacklist?

    I only have received a message for one domain so far.  We use ESA's.

    Monday, March 18, 2019 5:46 PM
  • Same issue using ESA. We use the following workaround and seems working now, off course waiting for a root cause and a final solution

    1 Hover mouse over Network 2. Select Listeners from the drop down menu. 3. Select  listener 4. Expand Advanced, by selecting it. 5. In the CR and LF handling section you need to select Allow messages with bare CR and LF characters. The default is Clean messages of bare CR and LF characters. 

    Monday, March 18, 2019 5:51 PM
  • I doubt you look up blacklists to servers you send to, if the NDR is #5.0.0 smtp; 5.3.0 - Other mail system problem 550-'5.6.0 Lone CR or LF in headers (see RFC2822 section 2.2)' (delivery attempts: 0)>' The problem is not a blacklist but a change cisco (Apparently) made. Ironport-data header contains a second colon (:) which breaks the RFC for headers.
    Monday, March 18, 2019 5:52 PM
  • Same issue using ESA. We use the following workaround and seems working now, off course waiting for a root cause and a final solution

    1 Hover mouse over Network 2. Select Listeners from the drop down menu. 3. Select  listener 4. Expand Advanced, by selecting it. 5. In the CR and LF handling section you need to select Allow messages with bare CR and LF characters. The default is Clean messages of bare CR and LF characters. 

    worked for me!!!
    Monday, March 18, 2019 5:54 PM
  • Hi, will making that change have a negative affect on other domains, like if we use TLS and SPF, DKIM etc?
    Monday, March 18, 2019 6:07 PM
  • Those that are proposing that the allow CR and LF was the fix, was your issue sending or receiving? It played no effect on sending for me. As the Cisco added header is the fault.
    Monday, March 18, 2019 6:11 PM
  • This solution worked for me too. 

    Thanks!!!!
    Monday, March 18, 2019 6:14 PM
  • Hi,

    What is result of below:-

    get-receiveconnector | fl BareLinefeedRejectionEnabled

    if it is true then make it false  by running below:-

    Set-ReceiveConnector -Identity "Internet Receive Connector" -BareLinefeedRejectionEnabled:$false

    Note:- It is not recommended to modify it and sender needs to check why these characters are used.

    https://support.office.com/en-us/article/Fix-email-delivery-issues-for-error-code-550-5-6-11-in-Office-365-81dafee7-26af-4d79-b174-8f78980dfafb

    You need to restart transport service to take this change affect immediately.



    Thanks,

    Ashish

    MCITP, MCT, MCSE

    “Tell me and I forget, teach me and I may remember, involve me and I learn.”

    Note:- Please remember to vote and mark the replies as answers if they help.

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees and confers no rights.


    Monday, March 18, 2019 6:17 PM
  • To All: It looks like Cisco has removed the troubled header, for now, the proposed fix probably should be reverted, as the change does affect security posture but allowing non-conforming emails through. The fix I believe was a coincidence in timing, as I tried the same thing earlier (Before the proposed fix) with no working result.
    Monday, March 18, 2019 6:28 PM
  • Cisco tech had me log into my ESA:

    go into Security Services -> Anti-Spam and click on the button "Update now".

    This appears to have fixed the issue for us.


    Monday, March 18, 2019 6:29 PM
  • Yes, these can be spam emails so before changing anything investigate non delivery messages.

    Thanks,

    Ashish

    MCITP, MCT, MCSE

    “Tell me and I forget, teach me and I may remember, involve me and I learn.”

    Note:- Please remember to vote and mark the replies as answers if they help.

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees and confers no rights.

    Monday, March 18, 2019 6:33 PM
  • @ Ernet Oranday: Did you go to Security Services and then Iron Port Anti-Spam to update ?

    Emanulelerossi: the setting in the work around you have listed, that option is deprecated - did you get this work around from TAC ?

    Looking forward to your responses.


    • Edited by Zoomy22020 Monday, March 18, 2019 6:37 PM
    Monday, March 18, 2019 6:37 PM
  • As odd as it sounds, a simple work-around until a fix is applied is to have at least two emails in the to: line.  So if it's an outbound email enter yourself and the person you want to receive the email.

    I would use this only if you are unable to apply the workaround mentioned earlier.

    Monday, March 18, 2019 6:38 PM
  • @ Ernest Oranday: Did you go to Security Services and then Iron Port Anti-Spam to update ?


    Looking forward to your responses.


    Yes, Security Services - Ironport Anti-Spam - Update Now
    Monday, March 18, 2019 6:41 PM
  • No luck after update.
    Monday, March 18, 2019 7:07 PM
  • I got a call from Cisco TAC ... they fixed the problem .. Everyone should be alright now. 
    Monday, March 18, 2019 8:05 PM
  • Nope
    Tuesday, March 19, 2019 8:16 AM