Joel Uckelman wrote:
I see what's causing the problem now, sort of. This URL appears in a footer
appended by SourceForge:
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
The message has in it's header
Content-Transfer-Encoding: quoted-printable
which results in the '=cl' in the appended footer being interpreted as a
quoted-printable character code. The tiny attached example message is
sufficient to reproduce the behavior I saw.
You're right that this is not valid Q-P encoding. RFC 2045 says
(in section 6.7):
# (2) An "=" followed by a character that is neither a
# hexadecimal digit (including "abcdef") nor the CR
# character of a CRLF pair is illegal. This case can be
# the result of US-ASCII text having been included in a
# quoted-printable part of a message without itself
# having been subjected to quoted-printable encoding. A
# reasonable approach by a robust implementation might be
# to include the "=" character and the following
# character in the decoded data without any
# transformation and, if possible, indicate to the user
# that proper decoding was not possible at this point in
# the data.
I think we should make nmh follow this recommendation (and the
others like it in that section); it's sensible enough and it makes
nmh more usable in the face of duff input.
-- PMM
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers