<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<blockquote type="cite"
cite="mid:66506f22-1b80-4f6b-9bc4-ae381593e62e@dolce-energy.com">
<p> a smart server would have received the data, and decoded once
for all, like this, it'll have been network efficient and
storage efficient, but this introduce the issue of PGP
signing... since the message is "modified" and don't know how to
scope with this matter... is it possible to "sign" each part
before encoding? (like a checksum file containing all the
checksum of every attached file for example)</p>
<p>if it's assumed that the message MUST not be altered, you have
to go the safe way : encode everything in 7bit ASCII</p>
<p>if the signing can be done "part by part in binary" then there
is nothing to worry about "re-formating" and a SMTP server can
choose to send it binary (if BINARYMIME and BDAT is supported)
or re-code it.... </p>
</blockquote>
<p>replying to myself after reading the </p>
<ul>
<li>rfc4880 " OpenPGP Message Format"</li>
<li>rfc3156 "MIME Security with OpenPGP"</li>
</ul>
<p>the latter state that, because the message can be reformated,<br>
<br>
However, many existing mail gateways will detect if the next<br>
hop does not support MIME or 8-bit data and perform conversion
to<br>
either Quoted-Printable or Base64. This presents serious
problems<br>
for multipart/signed, in particular, where the signature is<br>
invalidated when such an operation occurs. For this reason all
data<br>
signed according to this protocol MUST be constrained to 7 bits
(8-<br>
bit data MUST be encoded using either Quoted-Printable or
Base64).<br>
<br>
that's too bad, since in fact the "format" is enforced before
signing, while they could have chosen the opposite : enforcing all
binary fike to be presented into binary format in the mime
message, and signing versification should only be performed once
restored to original format.... </p>
<p>and in fact a false issue... the signature won't be invalidated
if the presentation change, since the presentation shall not alter
the original content and is reversible... so it just needed to
force the orginal format to create the message with binary data
when binary data, 8bit strings when 8bits strings, eg removing the
formating process. </p>
<p>On reception, the receiver remove the formating, going back to
binary for things that are binary, and validate the unformatted
content... it would have been compatible with other RFC effort to
allow binary data to go through the smtp protocol...</p>
<p>really, too bad...</p>
<p><br>
</p>
</body>
</html>