patchbomb (python email module?) breaks lines after 990 chars

David Champion dgc at uchicago.edu
Mon Apr 20 16:39:02 CDT 2009


* On 20 Apr 2009, Martin Geisler wrote: 
> Dirkjan Ochtman <dirkjan at ochtman.nl> writes:
> > On 20/04/2009 21:56, Martin Geisler wrote:
> >> I tried looking at patchbomb and it seems to me that we are not encoding
> >> the patches using base64 or quoted-printable -- this is only done for
> >> attached bundles. Maybe we should encode the body as well?
> >
> > Wouldn't that make it unreadable/harder to review?
> 
> Eh, wont the nice mail programs we all use (right?) decode it before
> displaying it? :-)

They should, yes, provided that the content-type is one suitable for
display.  (text/plain is good.)

Even if patchbomb does not truncate lines at 998 characters (as it well
should), well-behaved MTAs will do so.  You must assume that truncation
will occur, so the question is in what manner to support patches with
lines longer than this.

One handy solution is to prescan the content and encode only when
truncation would occur.  It's arguably more polite than encoding
everything, which will always consume more space in transit.  But it
still leaves patches vulnerable to aggressive MTAs which might truncate
sooner.  (It's unstated in RFC 2822 whether an implementation MUST
accept 998-character lines; it is only specified that it MUST limit
lines to 998 characters.)

But the bottom line is that if you want content protected from transit
munging, it needs to be encoded.  B64 and QP are both reasonable ways
to do that.

-- 
 -D.    dgc at uchicago.edu    NSIT    University of Chicago


More information about the Mercurial-devel mailing list