Remove email subject length truncation in AdminEmailHandler

[Peter De Wachter]

AdminEmailHandler.format_subject() is careful to stay under the 998 character limit of RFC 2822:

Escape CR and LF characters, and limit length.
RFC 2822's hard limit is 998 characters per line. So, minus "Subject: "
the actual subject must be no longer than 989 characters.

However, it forgets that the mail_admins function will prepend EMAIL_SUBJECT_PREFIX. After that's done, the subject line will again exceed to RFC limit.

Either the truncation needs to be moved to a lower level in the mail system, or format_subject needs to be adjusted to account for EMAIL_SUBJECT_PREFIX.

[Claude Paroz]

I tried the "lower level" technique in ​that PR.

[Claude Paroz]

After some more consideration, I discovered that headers are not limited in total length by the spec, only individual lines are. Read ​https://tools.ietf.org/html/rfc5322#section-2.1.3: An unfolded header field has no length restriction and therefore may be indeterminately long..
Then Python is automatically folding headers when sending messages, by default to 78 characters. So now I think that the subject line truncation is simply wrong. Of course, it's not nice to receive very long headers, but we have no reason to truncate subject or any other header.
We might even question the refusal to accept newlines in headers, but that would be the subject of a separate ticket.

[Claude Paroz]

The ​new PR.

pdewacht, what was your issue with subject line length?

[Peter De Wachter]

We're using django-post-office as email backend. It stores the messages in a database table and tries to put the subject in a varchar(989). That blew up when we had a log message that was unexpectedly long.

Personally I prefer truncating over line wrapping -- multiline subject headers seem esoteric even if it's true that it's technically allowed. I fear it will cause interoperability problems (see e.g. django-post-office breaking).

[Claude Paroz]

An alternative would be to truncate at a much shorter length, 120 chars comes to mind. Would that risk of stripping valuable data? Should we then repeat the record message in the body of the message?

[Tim Graham]

I'm inclined to say that applications like django-post-office should take care of truncating data as they see fit rather than Django making some arbitrary choice about it.

[Claude Paroz <claude@…>]

In c3e10869:

Stopped truncating AdminEmailHandler message subjects

Refs #26572, #17281. The RFC doesn't limit total length, just the line length
which is already taken care of by Python itself.
Thanks Tim Graham for the review.