Tobi:
> Hi
>
> as usual: thanks to Wietse :-)
>
> Adding the info rule to the pcre maps solved more than expected. After
> adding the info rule postfix cleanup did not segfault anymore and the
> mail could be accepted --> we have the source now.
> From what I see that is a massively oversized mime part header. I
> counted about 500 times the filename= in the mime part header as well as
> name= contains hundreds of values. All nicely utf8
>
> Like
>
> > Content-Type: image/png; name="=?UTF-
> > 8?B?xILChMOCwoLEgsKCw4LChMOEwoLDgsKCxILCgsOCwoLEgsKEw4LCgsSC?=
> > =?UTF-8?B?woLDgsKCw4TCgsOCwoLEgsKCw4LChMOEwoLDgsKExILCgsOCwoLDhMKC?=
> > =?UTF-8?B?w4LCgsSCwoLDgsKCxILChMOCwoLEgsKCw4LCgsOEwoLDgsKCxILCgsOC?=
>
> and
>
> > Content-Disposition: inline; filename*0*=UTF-8''%C4%82%C2%84%C3%82%C2
> > %82%C4%82%C2%82%C3%82%C2%84%C3%84;
> > filename*1*=%C2%82%C3%82%C2%82%C4%82%C2%82%C3%82%C2%82%C4%82%C2%84
> > %C3%82;
>
> First of all any idea why cleanup did not segfault with the info rule in
> place?
When something accesses wrong memory, what happens next is totally
dependent on memory layout, execution history, and so on. For example
the program may not crash (but still produce incorrect behavior).
> 2nd: could such mime headers be the reason for a pcre pattern to let
> libpcre segfault?
Sure, there are sometimes bugfixes for libpcre.
You can test such things.
$ postmap -h -q - pcre:pattern-file < data-file
$ valgrind --tool=memcheck postmap -h -q - pcre:pattern-file < data-file
where data-file contains the complete crashing message header and
pattern-file contains the crashing pattern.
Note that Postfix logs only a limited portion of very large lines.
You may need to "postcat" the original message if it is available.
valgrind will report incorrect memory access even when a program
does not crash. And yes, I do sometimes run Postfix daemons under
valgrind to find non-crashing bugs.
I'd be interested if you can reproduce the bug.
Wietse
