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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
