On 2001-04-14 01:33:53 +0200, Florian Weimer wrote:
Multipart/signed and multipart/encrypted are to be treated by
agents as opaque, meaning that the data is not to be altered
in any way [2], [7]. However, many existing mail gateways
will detect if the next hop does not support MIME or 8-bit
data and perform conversion to either Quoted-Printable or
Base64. This presents serious problems for multipart/signed,
in particular, where the signature is invalidated when such
an operation occurs. For this reason all data signed
according to this protocol MUST be constrained to 7 bits
(8-bit data MUST be encoded using either Quoted-Printable or
Base64).
of the 7 bit constraint fails to mention the binary/text mode
signature interoperability problem which can only be addressed if
there aren't any 8-bit characters.
Eh? It may be because I didn't have any coffee so far, but somehow,
I don't understand what you are trying to say here.
The text/binary mode interop problem is related to trailing
whitespace. It is not related to the presence or absence 8bit
characters. The next section basically says that, and makes
suggestions on how to fix things:
Additionally, implementations MUST make sure that no trailing
whitespace is present after the MIME encoding has been applied.
Note: In most cases, trailing whitespace can either be removed,
or protected by applying an appropriate
content-transfer-encoding. However, special care must be taken
when any header lines - either in MIME entity headers, or in
embedded RFC 822 headers - are present which only consist of
whitespace: Such lines must be removed entirely, since replacing
them by empty lines would turn them into header delimiters, and
change the semantics of the message. The restrictions on
whitespace are necessary in order to make the hash calculated
invariant under the text and binary mode signature mechanisms
provided by OpenPGP [1]. Also, they help to avoid compatibility
problems with PGP implementations which predate the OpenPGP
specification.
Note: If any line begins with the string "From ", it is strongly
suggested that either the Quoted-Printable or Base64 MIME
encoding be applied. If Quoted-Printable is used, at least one
of the characters in the string should be encoded using the
hexadecimal coding rule. This is because many mail transfer and
delivery agents treat "From " (the word "from" followed
immediately by a space character) as the start of a new message
and thus insert a right angle-bracket (>) in front of any line
beginning with "From " to distinguish this case, invalidating the
signature.
Of course, implementations are free to find other
standards-compliant ways of protecting whitespace - however, I doubt
they'll find such ways.
(USEFOR currently overrides the analogous requirement in RFC 2015.)
I hope you're joking. Could you please send the relevant sections
from the latest usefor draft to this list?
--
Thomas Roessler <roessler(_at_)does-not-exist(_dot_)org>