Correct. In this first sample, sent via Courier 0.42.2, the 3rd, 4th, 5th and 6th LF characters (=0A) have CR (=0D) preceding them when they should not. Sample 2 shows the data sent properly, on Courier 0.40.1, which I downgraded to today.
Courier never generates =0A when creating quoted-printable content. Wherever this message came from, it was not encoded by Courier. You may see the logic yourself in rfc2045/rfc2045encode.c:
if ( *p == '\n')
info->input_buf_cnt=0;
else if (*p < ' ' || *p == '=' || *p >= 0x7F)
{
QPUT('=');
QPUT(xdigit[ (*p >> 4) & 15]);
QPUT(xdigit[ *p & 15 ]);It, therefore, is logically impossible for Courier to generate this content.
--BEGIN SAMPLE 1-- filename="WASHDC.pdf" X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.42.2
And, as I recall, I already pointed out that this header indicates that the original message, as received by Courier, already had invalid MIME encoding.
So, you have some other unknown factor involved here.
pgp00000.pgp
Description: PGP signature
