On Fri, Apr 15, 2011 at 5:30 AM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Apr 15, 2011 at 12:43:08AM +0200, Erik Faye-Lund wrote: > >> >> 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? >> >> I was just thinking of interpreting everything left of '<' literally >> and encode it (if needed). Currently, we interpret the entire string >> literally, encoding the name would an improvement. > > Won't that be a regression for people who already know that we take > things literally and are manually quoting and/or rfc2047-encoding the > contents? Yes. But won't that always be the case when someone depends on buggy behavior? Besides, send-email takes interprets it's --to and --cc arguments as well as sendemail.to and sendemail.cc config options literally (i.e quoting if needed without any attempts on unquoting first). IMO having two closely related programs with similar options that behave different in border-cases is pretty ugly. ESPECIALLY when one of them has a habit of forwarding unknown options to the other, like send-email does... -- 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