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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26572>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* component: Uncategorized => Core (Mail)
* needs_tests: => 0
* needs_docs: => 0
* type: Uncategorized => Bug
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:1>
* has_patch: 0 => 1
Comment:
I tried the "lower level" technique in
[https://github.com/django/django/pull/6550 that PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:2>
* needs_better_patch: 0 => 1
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:3>
* needs_better_patch: 1 => 0
Comment:
The [https://github.com/django/django/pull/6551 new PR].
pdewacht, what was your issue with subject line length?
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:4>
Comment (by pdewacht):
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:5>
Comment (by claudep):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:6>
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:7>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:8>
Comment (by Claude Paroz <claude@…>):
In [changeset:"c3e108694966f045adcc0ba11133a2b3bf238770" c3e10869]:
{{{
#!CommitTicketReference repository=""
revision="c3e108694966f045adcc0ba11133a2b3bf238770"
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.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:9>
* status: new => closed
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/26572#comment:10>