Squash line breaks in Subject display
Process messages held by Mailman for approval
Brought to you by:
solbu
For my own uses, readability of listadmin's output would be improved by trying to eliminate unnecessary line breaks in Subject lines. With the rfc2047 encoding that's available, it seems these things can pretty easily creep into Subject lines. For example, a recent spam I received had this Subject header:
Subject: =?utf-8?B?MTk2MzQ4OTY3NEBxcS5jb23mmJPoqJgxOTc5ODTjgIJDME3pgoDmgqg=?= =?utf-8?B?6Ki75YaK5ba64pGkOOeAmzXiko8w5o+Q6YKE6IO95pC257SF5YyF5bCI5ZOh?= =?utf-8?B?MjEyOTI5MDY2?=
listadmin displays this as:
Subject: 钳羋摩統流坠鯽铿柬蒙靡<0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> <0d> 可靠银河 197984點COM您紸冊嶺⑤8贏5⒏0 提拿紅bao專員291212028
Oops. I think I copy and pasted the wrong mail's Subject header in the ticket description. I got several spams from the same sender with similar Subjects. But still, the fact remains that looking at such a multi-line display of the Subject line hurts readability when incrementally crawling through dozens of messages held for moderation.
Also, I can't explain where the
<0d>
bits are coming from. If I was guessing, I'd say the original header may have had (encoded) Windows-style\r\n
(CRLF) line endings, with\n
getting handled by the rfc2047 decoder and the\r
just showing up as some representation of an unprintable character.Nice.
Havent seen one of these myself, yet.
Merged.