Closed Bug 393196 Opened 16 years ago Closed 16 years ago
_rfc2047 _encoding() erroneously inserts whitespace for addr-spec-only addresses
When encountering addresses with an addr-spec part only (such as "email@example.com"), libmime's apply_rfc2047_encoding() erroneously inserts a space (0x20) character - i.e. when composing a message with Thunderbird or Seamonkey, the final message will have headers like these: To: firstname.lastname@example.org CC: email@example.com, firstname.lastname@example.org, email@example.com (same for From headers, though these usually aren't addr-spec-only) This can lead to problems with signing mechanisms such as DKIM (RFC 4871), if the header is first signed with the extra white space included, but later on in the SMTP chain removed by another MTA (it will break the original signature). Sendmail is one (prominent) example of such an MTA - it will strip unnecessary whitespace from To header fields automatically (can't even be disabled by means of configuration settings). To prevent this problem, libmime shouldn't add extra whitespace in the first place. The proposed patch fixes this by checking if the preceding displayname is non-empty (and only adds a space character if that's the case). Phil, I hope you're (one of) the right person(s) to ask for a review - if not, please let me know whom this should go to otherwise. Thanks!
Comment on attachment 277718 [details] [diff] [review] Proposed patch I could review it, but it wouldn't do you any good since my r+ doesn't count outside of mail/. If David isn't the right person, he'll certainly know who is.
Comment on attachment 277718 [details] [diff] [review] Proposed patch that looks good, thx, Kaspar.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M8
Thanks for the fast review and checkin, David and Phil! Is there any chance of getting this into Tb 2? If so, who is supposed/allowed to set the approval188.8.131.52 flag? (If these are questions with trivial answers, then I'm sorry for asking and obviously didn't look at the right place [Wiki? Tinderbox?] - thanks for pointing me to the right direction in this case.)
Comment on attachment 277718 [details] [diff] [review] Proposed patch Is it possible to get this into 184.108.40.206?
Attachment #277718 - Flags: approval220.127.116.11?
Comment on attachment 277718 [details] [diff] [review] Proposed patch I think this has baked enough.
Attachment #277718 - Flags: approval18.104.22.168? → approval22.214.171.124+
I've landed this on the 126.96.36.199 branch.
(In reply to comment #7) > I've landed this on the 188.8.131.52 branch. Thanks, Scott!
I don't know how to verify this bug for the 1.8 branch. This sounds more like a mail issue than a browser issue, right? Is there any way to verify that this is fixed on the 1.8 branch?
Martijn: So much more a mail issue than a browser issue that I wonder whether you meant to make that comment on some other bug. To verify it, send an email with two or more cc's from a pre-20070930 branch Tbird, check that you receive it with two spaces between the addresses in the Cc: header in the message source (to be sure you aren't getting them normalized along the way, as I do with two out of three recipient addresses), then send another in a post-20070930 build. Which I just did on the trunk, so, verified fixed there.
Status: RESOLVED → VERIFIED
(In reply to comment #10) > (to be sure you aren't getting them normalized > along the way, as I do with two out of three recipient addresses) Just as a side note - saving the message as a draft will also do the trick here.
You need to log in before you can comment on or make changes to this bug.