Skip to content

Fix issues with smime signatures and smtp dot stuffing

Diego Louzán requested to merge siemens/gitlab:fix/smime-encoding-issues into master

What does this MR do and why?

We discovered on our self-hosted setup, that sometimes emails got broken S/MIME signatures for no apparent reason, even though the content looked perfectly normal. It turns out this is caused by an SMTP feature called dot stuffing.

Per SMTP RFC, single line dot characters are interpreted as the end of a message, so they are forcefully converted to a double dot before delivery.

https://www.rfc-editor.org/rfc/rfc5321#section-4.5.2

Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.

This has the unfortunate effect of sometimes breaking SMIME signatures, since signatures are calculated as an ActionMailer interceptor before SMTP delivery. Any changes of the in-flight email will break the signatures.

This patch forces to always use quoted-printable and encoding of single-line dots to Q-P =2E, hence eliminating the need to perform any dot stuffing.

When could this situation happen?

  • The mail gem will analyze the chars contained in the source before encoding; if only ASCII characters are used, it will choose 7bit transfer encoding, since it adds no overhead to the email parts. But then single dots in the original text are sent as is, and the SMTP delivery chain will perform dot stuffing.
  • If the email contains anything that is not ASCII (e.g. an accented char), the mail gem will use quoted-printable transfer encoding. This does not avoid the possibility of a single-line dot, but in this case, we can force those cases to become =2E, which is the dot-char encoding in quoted-printable. Hence avoiding the possibility that a single dot exits in the source.
  • Forcing quoted-printable always adds some overhead on pure ASCII emails (which would be sent as-is previously), but this should be negligible for email purposes. Whenever any non-ASCII char is involved, there's no overhead change.
  • My knowledge of the RFC is not deep enough, I find this dot stuffing process non-reversible (with confidence). The SMTP in-between processors will never be able to differentiate a single dot in the source that was converted to a double dot, from an actual double-dot on the source that is not transformed at all. This is an issue when signatures are involved, since any change to the text will break the signatures.

Related:

🛠 with ❤ at Siemens

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Diego Louzán

Merge request reports