segfault on rfc2047-like subject

[David Relson]

On Sat, 09 Oct 2004 01:27:29 +0200
Matthias Andree wrote:

> Clint Adams <schizo at debian.org> writes:
> 
> > Subject: [Broken]
> > =?ISO-8859-1?Q?Re=3A_=5BBroken=5D_=3D=3FISO-8859-1=3FQ=3F=3D5B?=
> >  =?ISO-8859-1?Q?Broken=3D5DBlah=3D20Foo=3DE4=3D20Bar=3D20Blah
> >  _?= =?ISO-8859-1?Q?Foo=3D3D28=3D5F=3F=3D_Bar=5F=5F=3F=3D_t=E4Blah?=
> >  =?ISO-8859-1?Q?Foo=E4t=29?=
> 
> Gee. qp_validate was tampering with the string it was passed, turning
> the LF into a NUL and replacing underscores by blanks (that surely
> doesn't belong into a "validate" function.)

Yep.  Sounds like a fix is needed.  Do you want to do it or shall I?

Looking at RFC-2045, I see:

  token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
              or tspecials>

  tspecials :=  "(" / ")" / "<" / ">" / "@" /
                "," / ";" / ":" / "\" / <">
                "/" / "[" / "]" / "?" / "="
                ; Must be in quoted-string,
                ; to use within parameter values

Looks like new-lines aren't allowed in the middle of a token.
Unfortunately, bogofilter can't restrict itself to RFC compliant
messages and needs to accept b0rked ones.

> The NUL then choked text_decode which was supposed to treat word_t
> rather than C strings.

AFAICT, the NUL causes strstr() to not find the end of the token.  The
NULL returned by strstr() then causes "uint size = (uint) (txt - beg)"
to give a bogus result.  Bah, humbug!

> I think we need to tell the quoted-printable decoder whether it is
> decoding RFC-2047 (transform underscore to blank; blank and tab
> illegal) or RFC-2045 (pass underscore, blank and tab allowed).

Do you want to tackle RFC-2045 vs RFC-2047???