Re: [PATCH] generate a valid rfc2047 mail header for multi-line subject.

From: Jeff King <peff@peff.net>
Date: Feb 23, 2011, 08:08 UTC
Message-ID: <20110223080854.GB2724@sigill.intra.peff.net>
In-Reply-To: <7vsjvfby0z.fsf@alter.siamese.dyndns.org>

On Tue, Feb 22, 2011 at 12:43:40PM -0800, Junio C Hamano wrote:

Show 20 quoted lines

> So the general idea of this change (I am thinking aloud what should be in
> the updated commit log message as the problem description) is that:
> 
>  - We currently give an entire multi-line paragraph string to the
>    add_rfc2047() function to be formatted as the title of the commit;
> 
>  - The add_rfc2047() functionjust passes "\n" through, without making it a
>    folding whitespace followed by a newline, to help callers that want to
>    use this function to produce a header line that is rfc 2822 conformant;
> 
>  - The patch introduces a new function add_rfc2047_multiline() that splits
>    its input and performs line folding for such a caller (namely, the
>    pp_title_line() function);
> 
>  - Another caller of add_rfc2047(), pp_user_info, is not changed, and it
>    won't fold the name of the user that appear on the From: line.
> 
> It is unclear if the last point is really the right thing to do, though.
> It is not a new problem that an author name that has a "\n" in it would
> break the output, but we probably would want to fix that case too here?

Yeah, I think the best path forward is:

  1. Stop feeding "pre-folded" subject lines to the email formatter.
     Give it the regular subject line with no newlines.

  2. rfc2047 encoding should encode a literal newline. Which should
     generally never happen, but is probably the most sane thing to do
     if it does.

  3. rfc2047 should fold all lines at some sane length. As it is now, we
     may sometimes generate long lines in headers (though in practice, I
     doubt this is much of a problem).

I started to work on this, but got stuck on (3). Our existing wrap functions want NUL-terminated strings, and we are operating on a substring. I tried converting the wrap functions to handle lengths, but it got way uglier than I had hoped. I think just strdup'ing the subject temporarily is probably fine, though. Let me see what I can come up with.

-Peff