Hornetsecurity is implementing an update to enhance email security by enforcing checks on the "Header-From" value in emails, as per RFC 5322 standards.
This initiative is driven by several key reasons:
- Preventing Email Delivery Issues: Historically, not enforcing the validity of the originator email address has led to emails being accepted by our system but ultimately rejected by the final destination, especially with most customers now using cloud email service providers that enforce stricter validation.
- Enhanced Protection Against Spoofed Emails: By strictly validating the "Header-From" value, we aim to significantly reduce the risk of email spoofing.
- Enhance Email Authentication for DKIM/DMARC Alignment: By enforcing RFC 5322 compliance in the "Header-From" field, we can ensure better alignment with DKIM and DMARC standards, thereby significantly improving the security and authenticity of email communications.
The cause of malformed "From" headers often stems from incorrect email server configurations by the sender or from bugs in scripts or other applications. Our new protocol aims to rectify these issues, ensuring that all emails passing through our system are fully compliant with established standards, thus improving the overall security and reliability of email communications.
Implementation Timeline
- Stage 1 (Starting 4 March 2024): 1-5% of invalid emails will be rejected.
- Stage 2 (Second week): 30% rejection rate.
- Stage 3 (Third week): 60% rejection rate.
- Final Stage (By the end of the fourth week): 100% rejection rate.
Impact Assessment
Extensive testing over the past six months indicates that the impact on legitimate email delivery is expected to be minimal. However, email administrators should be prepared for potential queries from users experiencing email rejections.
Handling Rejections
When an email is rejected due to a malformed "Header-From", the sender will receive a bounce-back message with the error "510 5.1.7 malformed Header-From according to RFC 5322". This message indicates that the email did not meet the necessary header standards.
Identifying Affected Emails
Email administrators can identify affected emails in the Hornetsecurity Control Panel (https://cp.hornetsecurity.com) using the following steps:
- Navigate to ELT in the Hornetsecurity Control Panel.
- Select your tenant in the top right field.
- Choose a date range for your search. A shorter range will yield quicker results.
- Click in the "Search" text box, select the "Msg ID" parameter, and type in "hfromfailed" (exact string).
- Press ENTER to perform the search.
When email administrators identify emails affected by the "Header-From" checks in the Email Live Tracking (ELT) system, immediate and appropriate actions are necessary to verify if the email application or server settings are correctly configured to comply with RFC 5322 standards. This will help maintain email flow integrity.
Defining Exceptions
In implementing the new "Header-From" checks, Hornetsecurity recognizes the need for flexibility in certain cases. Therefore, we have provisioned for the definition of exceptions to these checks.
This section details how to set up these exceptions and the timeline for their deprecation:
Configuring Exceptions
- Accessing the Control Panel: Log in to the Hornetsecurity Control Panel at https://cp.hornetsecurity.com.
- Navigating to the Compliance Filter.
- Creating Exception Rules: Within the Compliance Filter, you can create rules that define exceptions to the "Header-From" checks. This should be based on the envelop sender address.
- Applying the Exceptions: Once defined, these exceptions will allow certain emails to bypass the strict "Header-From" checks.
Timeline for Deprecation of Exceptions applied to the new Header-From checks
- Initial Implementation: The ability to define exceptions is available as part of the initial rollout of the "Header-From" checks.
- Deprecation Date: These exception provisions are set to be deprecated by the end of June 2024.
The provision for exceptions is intended as a temporary measure to facilitate a smoother transition to the new protocol. By June 2024, it is expected that all email senders would have had sufficient time to align their email systems with RFC 5322 standards. Deprecating the exceptions is a step towards ensuring full compliance and maximizing the security benefits of the "Header-From" checks.
Conclusion
The enhancement of our RFC-compliance is a significant step toward securing email communications. Adherence to these standards will collectively reduce risks associated with email. For further assistance or clarification, please reach out to our support team at support@hornetsecurity.com.
Invalid "Header From" Examples:
Header From | Reason |
From: <> | Blank addresses are problematic as they cause issues in scenarios requiring a valid email address, such as allow and deny lists. |
From: John Doe john.doe@hornetsecurity.com | Non-compliant with RFC standards. The email address must be enclosed in angle brackets (< and >) when accompanied by a display name. |
From: "John Doe" <john.doe@hornetsecurity.com> (Peter's cousin) | While technically RFC-compliant, such formats are often rejected by M365 unless explicit exceptions are configured. We do accept certain email addresses with comments. |
From: John, Doe <john.doe@hornetsecurity.com> | Non-compliant with RFC standards. A display name containing a comma must be enclosed in double quotes. |
From: "John Doe <john.doe@hornetsecurity.com>" | Non-compliant with RFC standards. The entire 'From' value is incorrectly enclosed in double quotation marks, which is not allowed. |
From: "John Doe <john.doe@hornetsecurity.com>" john.doe@hornetsecurity.com | Non-compliant with RFC standards. The display name is present, but the email address is not correctly enclosed in angle brackets. |
From: "John Doe"<john.doe@hornetsecurity.com> | Non-compliant with RFC standards due to the absence of white-space between the display name and the email address. |
From: "Nested Brackets" <<info@hornetsecurity.com> | Nested angle brackets are not allowed in the “addr-spec” part of the email address. |
From: Peter Martin <e14011> | Non-compliant with RFC standards. The domain part of the email address (“addr-spec”) is missing. |
From: "News" <news.@hornetsecurity.com> | Non-compliant with RFC standards. The local part of the email address must not end with a dot. |
Missing “From” header altogether | A “From” header is mandatory in emails. The absence of this header is a clear violation of RFC standards. |
Valid "Header From" Examples:
Header From | Reason |
From: john.doe@hornetsecurity.com | RFC-compliant |
From: <john.doe@hornetsecurity.com> | RFC-compliant |
From: "Doe, John" <john.doe@hornetsecurity.com> | RFC-compliant |
From: "John Doe" <john.doe@hornetsecurity.com> | RFC-compliant |
From: < john.doe@hornetsecurity.com > | RFC-compliant but not recommended because of the spaces between the email address and angle brackets |
From: John Doe <john.doe@hornetsecurity.com> | Acceptable, although it is recommended that the display name is enclosed in double quotes if it contains any white-space. |