Re: Formatting problem send_mail in version 2.10.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Daudt <me@xxxxxxxxx> writes:

> On Wed, Oct 12, 2016 at 07:13:22PM -0400, Jeff King wrote:
>
>> I think the answer is pretty clearly no. It's just that historically we
>> have auto-munged it into something useful. I think the viable options
>> are basically:
>> 
>>   1. Tell people not to do that, and to do something RFC compliant like
>>      "Stable [4.8+]" <stable@xxxxxxxxxxxxxxx>. This is a little funny
>>      for git because we otherwise do not require things like
>>      rfc-compliant quoting for our name/email pairs. But it Just Works
>>      without anybody having to write extra code, or worry about corner
>>      cases in parsing.
>> 
>>   2. Drop everything after the trailing ">". This gives a valid rfc2822
>>      cc, and people can pick the "# 4.8" from the cc line in the body.
>
> Comments, surrounded by parenthesis are allowed after the ">" according
> to the RFC, just plain dropping everything comming after that would
> break that support.

Our in-house parser does consider (...) comments, and my patch does not
change how they are handled: they are still kept after the address part.

However, another piece of code does strip everything behind ">":

sub sanitize_address {
        ...
	# remove garbage after email address
	$recipient =~ s/(.*>).*$/$1/;

introduced in 831a488b76e0 (git-send-email: remove garbage after email
address, 2012-11-22).

IMHO, it's OK to continue doing this: removing comments from To: and Cc:
is not really a problem (and I think we've seen nobody complain about it
since 2012). But after my patch, these two lines can probably safely be
removed, as there can no longer be "garbage" after the email, only
comments.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]