[Top] [All Lists]

Re: 2 MIME questions re: message/rfc822

2004-11-05 06:32:37

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.