Bare line feeds (Email Issue)

[Stephen Hutchinson]

Hi All, is any one suffering from bounce back emails because of Bare line feeds" are unsupported ? I have an example attached. Your help will be appreciated.

 

 

Bare Line Feeds Error.pdf

[Martyn Houghton]

@Stephen Hutchinson

We have been experiencing the same issue as well and have logged a incident with Hornbill to assist with diagnosing if it is something specific to our templates or more with the SMTP outbound connection process. 

We are also using Office 365 for the email delivery mechanism.

Cheers

Martyn

 

[Victor]

@Martyn Houghton did you have a chance to test the template we amended yesterday?

[Martyn Houghton]

@Victor

Just testing at the moment. With emails generated in the mailbox directly and those from an request.

Cheers

Martyn

[Victor]

@Stephen Hutchinson we are now looking to find the root cause for this issue. In @Martyn Houghton case we are now looking at email templates after we ruled out any interference from a 3rd party software.

 

@Stephen Hutchinson do you have any 3rd party software that inserts something into an outgoing email? (like AV disclaimer or security appliances). These are also known to insert bare linefeeds into email messages. 

[Martyn Houghton]

@Victor

From out testing so far it does appear to being triggered by content when using templates or even forwarding an email which is in reply to one generated a template.

Cheers

Martyn

[Victor]

@ALL

We are still looking into this internally. This issue occurs if the source message transfer agent (MTA) didn't append the expected CR-LF combination to the end of the message. MTA in this case is Hornbill.(https://support.microsoft.com/en-us/help/2998901/-smtpsent.barelinefeedsareillegal-ndr-received-by-exchange-online-or-eop-users-in-office-365-dedicated-itar)

Having an email message with lines ending with only LF would not cause any problems until Office 365 is configured to reject bare line feeds.

 From research done by @Martyn Houghton and our platform team we suggest this possible workaround:

If the sender cannot correct the sent messages, or if the gap must be bridged until the message format is corrected, the recipient can create an inbound transport rule to append a disclaimer to the messages from the problematic sender (this being us, Hornbill). The disclaimer will append the expected CR-LF combination to the message so that it can be delivered. (This disclaimer may consist of a single character such as a period or a dash.

[Stephen Hutchinson]

5 hours ago, Victor said:

@Stephen Hutchinson we are now looking to find the root cause for this issue. In @Martyn Houghton case we are now looking at email templates after we ruled out any interference from a 3rd party software.

 

@Stephen Hutchinson do you have any 3rd party software that inserts something into an outgoing email? (like AV disclaimer or security appliances). These are also known to insert bare linefeeds into email messages. 

Hi Victor, we do not have 3rd party software that has inserted anything into our out going email. I have had an Hornbill Consultant that (last week) has performed some changes to my incident Management BPM, including the email notifications. They look fine to an un-trained eye in this field. This definitely triggers when sending content from templates.

 

Regards

Stephen

[Victor]

@Stephen Hutchinson you won't be able to see the lines ending with just an LF even with a "trained" eye  ... I am (we are) almost certain it is the email template editor which creates the LF and not the LF-CR. However I am certain that the issue did not occur due to recent changes made in templates.

I would advise to apply the suggested workaround while our dev team investigate a possible alternative to enhance Hornbill SMTP connector (meaning that Hornbill SMTP could "normalise" the message before sending).

[Victor]

@Stephen Hutchinson just an FYI that there are some updates on this issue discussed here:

 

[Victor]

Just a quick update on this issue. Our investigation so far reveals the issue to be isolated to emails which are using templates (specifically the CK Editor we are using when designing email templates). All other outbound emails (such as email sent from our mail interface and email sent using default and not edited templates) are not affected. This is not caused by any change we have done recently in Hornbill.

For Office 365 users it occurs because until recently, Office 365 automatically removed bare line feed characters from mail to help it get delivered to recipients using email servers that don’t support chunking and the BDAT command (such as Hornbill).To comply with RFC 2822, Office 365 no longer removes bare line feeds from messages. As a result, messages sent to users from Hornbill may be more likely to be rejected.
(https://support.office.com/en-us/article/Fix-email-delivery-issues-for-error-code-5-6-11-in-Office-365-81dafee7-26af-4d79-b174-8f78980dfafb?ui=en-US&rs=en-US&ad=US)

For other mail services users (e.g. MS Exchange) the issue could occur due to SMTP connector changes whereby the connector is now configured to reject bare line feeds.

Currently we working to get Hornbill mail in line with RFC 2822 requirements (https://forums.hornbill.com/topic/10012-dkim-for-outbound-email/).

 

For the time being we suggest the following possible workarounds:

• create an inbound transport rule on your mail server to append a disclaimer to the messages from Hornbill. The disclaimer will append the expected CR-LF combination to the message so that it can be delivered. This disclaimer may consist of a single character such as a period or a dash (https://support.microsoft.com/en-us/help/2998901/-smtpsent.barelinefeedsareillegal-ndr-received-by-exchange-online-or-eop-users-in-office-365-dedicated-itar).
• avoid the use of email templates which have been edited in the email template editor - CK Editor - (out of the box templates which have not been edited should not have this issue).

[Martyn Houghton]

@Victor

Thanks for the detailed reply. 

Are the email templates held in the database itself or on the file system?

Cheers

Martyn

[Victor]

@Martyn Houghton on the file system I'm afraid

[Martyn Houghton]

@Victor
 

Thanks for coming back. That would have made life too easy. 

Cheers

Martyn

[Victor]

@Martyn Houghton maybe it is possible to (temporarily) disable "BareLinefeedRejection" on the receive connector? As far as I know you can do this on an on-premise Exchange using set-receive connector but I don't know if and how this can be done in Office 365

[Stephen Hutchinson]

On 07/06/2017 at 4:18 PM, Victor said:

Just a quick update on this issue. Our investigation so far reveals the issue to be isolated to emails which are using templates (specifically the CK Editor we are using when designing email templates). All other outbound emails (such as email sent from our mail interface and email sent using default and not edited templates) are not affected. This is not caused by any change we have done recently in Hornbill.

For Office 365 users it occurs because until recently, Office 365 automatically removed bare line feed characters from mail to help it get delivered to recipients using email servers that don’t support chunking and the BDAT command (such as Hornbill).To comply with RFC 2822, Office 365 no longer removes bare line feeds from messages. As a result, messages sent to users from Hornbill may be more likely to be rejected.
(https://support.office.com/en-us/article/Fix-email-delivery-issues-for-error-code-5-6-11-in-Office-365-81dafee7-26af-4d79-b174-8f78980dfafb?ui=en-US&rs=en-US&ad=US)

For other mail services users (e.g. MS Exchange) the issue could occur due to SMTP connector changes whereby the connector is now configured to reject bare line feeds.

Currently we working to get Hornbill mail in line with RFC 2822 requirements (https://forums.hornbill.com/topic/10012-dkim-for-outbound-email/).

 

For the time being we suggest the following possible workarounds:

• create an inbound transport rule on your mail server to append a disclaimer to the messages from Hornbill. The disclaimer will append the expected CR-LF combination to the message so that it can be delivered. This disclaimer may consist of a single character such as a period or a dash (https://support.microsoft.com/en-us/help/2998901/-smtpsent.barelinefeedsareillegal-ndr-received-by-exchange-online-or-eop-users-in-office-365-dedicated-itar).
• avoid the use of email templates which have been edited in the email template editor - CK Editor - (out of the box templates which have not been edited should not have this issue).

Thanks for the update around this do far Victor. We currently use O365 and Hornbill templates to notify our customers regarding updates, 3 strike rules & general correspondence which was set up by the Consultants team. Because Hornbill are not yet inline with the RFC 2822 requirements our customers can not receive our emails. Can I ask:

i. When do Hornbill plan on be inline with the RFC2822 requirements?

ii. I'm right in saying that the templates out of the box (untouched) shouldn't be affected? If so can our templates be reset back to the default and re-created?

 

[Victor]

@Stephen Hutchinson

4 minutes ago, Stephen Hutchinson said:

When do Hornbill plan on be inline with the RFC2822 requirements?

I suggest following this thread for updates on this: 

 

7 minutes ago, Stephen Hutchinson said:

the templates out of the box (untouched) shouldn't be affected? If so can our templates be reset back to the default and re-created?

Yes, the should work. I can ask our cloud team to see if they can deploy the default email templates files in your instance.

[Stephen Hutchinson]

Ok that's good news. Regarding the content of our existing templates, can they be replicated back to the default templates so that our notifications to our customers looks the same?

[Victor]

@Stephen Hutchinson I need to have a look at your current templates and see the difference... just a quick note, the "new" templates (templates created as new in your instance) will be removed if we deploy our default templates...

Just a quick question, did you have a look if is possible to (temporarily) deactivate/disable the bare line feed rejection in your Office 365?

[Stephen Hutchinson]

1 hour ago, Victor said:

@Stephen Hutchinson I need to have a look at your current templates and see the difference... just a quick note, the "new" templates (templates created as new in your instance) will be removed if we deploy our default templates...

Just a quick question, did you have a look if is possible to (temporarily) deactivate/disable the bare line feed rejection in your Office 365?

i. Might be an idea to liaise with Daniel Riley because he is aware when our email templates are used i.e. 3 strike rule . We presently use templates in our live incident management BPM. Daniel has created a new incident management BPM to go live end of next week with templates labelled EmailClosureStike v2. Both sets of templates will need amending. If they are remove can they be replaced like for like?

ii. Unfortunately is not possible to deactivate/disable the bare line feed rejection in our Office 365.

 

[Victor]

1 hour ago, Stephen Hutchinson said:

Both sets of templates will need amending. If they are remove can they be replaced like for like

@Stephen Hutchinson I'm afraid not. If they (our cloud team) were to replace the templates they will basically copy the files from our repository and deploy them in your instance. It will basically override all existing templates.

However, I would advise to hold on for now on this. I just had a chat with our platform dev team and they seem to have something ready to fix this issue cater for this scenario early next week. So I think (fingers crossed), if all testing goes well on Monday, we can deploy a fix an update your instance on Tuesday ( @Martyn Houghton FYI).

[Stephen Hutchinson]

Ok thanks for the update Victor and support so far...

[Victor]

@Stephen Hutchinson @Martyn Houghton

We have updated your instances to address this issue. The update includes a revised functionality around email to address the bare line feed rejection. When you have a chance please have a look and let us know if the issue still persists or not in your instances.

[Stephen Hutchinson]

We have not experienced a bounce back since 13:51 today. We will continue to monitor this and let you know if we do.

[Martyn Houghton]

@Victor

We will remove the workaround and monitor.

Thanks.

Cheers

Martyn