On Fri, Apr 15, 2011 at 12:21:24AM +0200, Erik Faye-Lund wrote: > >> True. But since the fix is as simple as it is, perhaps it's worth it > >> just for the clean conscience? > > > > Fair enough. Patch to follow. > > > > Thinking about it a bit more, I'm getting a bit more unsure: > - The 78-limit is about user-interfaces, not protocol robustness. True. In theory we should also be limiting to avoid the 998-character hard protocol limit, but that is getting ridiculously unlikely. > - Since send-email unwraps the line and does not re-wrap it, even if > we have a name like this it's likely that the work gets undone right > away. Not everybody uses send-email. So you are also helping MUAs which consume the output of format-patch. That being said, I doubt that this will make a difference to anybody. The real reason that we put wrapping into add_rfc2047 was for subjects, which _do_ get long. > - So that means that send-email should probably also be fixed. But now > I'm wondering if we've crossed the point where this will just lead to > less obvious code for very little gain. It is ugly code. I'm just as happy if we drop it. > > Because it means we have to _parse_ those > > headers and understand which part is a name and which is an address. > > That part is surprisingly easy: If it contains a '<', then it's on the form > "Foo Bar Baz <foo@xxxxxxx>". If not, it's "foo@xxxxxxx" (assuming it's > UTF-8 encoded rfc5322 mailbox'es we assume, which would make the most > sense to me) What about: "Foo \"The Bar\" Baz" <foo@xxxxxxxxxxx> or Foo "The Bar" Baz <foo@xxxxxxxxxxx> or Foo (The Bar) Baz <foo@xxxxxxxxxxx> I.e., are we taking rfc822-style addresses, or are we taking something that looks vaguely like an email address, and just treating everything left of "<" as literal? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html