While I repeat that there is a surfeit of candidates at which to point
a finger in this case, we may not yet have gone deep enough. Let me be
the first to say that at least part of the problem here may be in the
MIME standard itself.
This situation could in theory be avoided by simply applying a suitable
content-transfer-encoding to the embedded message/rfc822 object
*before* PGP-signing it, thus protecting against line wrapping.
However, this is explicitly *prohibited* by the MIME standard, as per
RFC 2046:
> No encoding other than "7bit", "8bit", or "binary" is
permitted for
> the body of a "message/rfc822" entity.
That may still have been the right design decision -- forbidding
protective C-T-E's for multipart and message makes message structure
much more transparent -- but as far as I can tell, there is NO
legitimate way to encode and sign a message/rfc822 object to protect
against line wrapping in the header fields of the embedded
message/rfc822 object. In other words, if you want to forward a full
message including long Received headers, and you want to sign the
forwarding message with PGP, you may be simply out of luck.
The best solution that comes to mind is to revise the PGP signature
computation to be tolerant of inserted white space, at least in the
headers of embedded message objects. -- Nathaniel
On Nov 5, 2004, at 8:14 AM, Arnt Gulbrandsen wrote:
Arnt Gulbrandsen writes:
But IMO, the list processor software is a recipient as far as the
internet mail system is concerned. (You get a final delivery DSN when
the message is delivered to the mailing list processor.)
Let me put it differently.
A sender should either expect the recipient to use the label, or else
put in application/octet-stream.
Saying things like "the label is useful and should be there, but only
human recipients should use it, programs should ignore it" is IMO
nonsensical. I hope I'm not erecting strawmen.
Arnt