Hi Simon,
--On Friday, November 14, 2003 22:46 +0100 Simon Josefsson
<simon+ietf-822(_at_)josefsson(_dot_)org> wrote:
| I haven't seen a way to support both inline PGP and format=flowed
| without creating one problem or another.
That's been my experience and in fact I deliberately turn off format=flowed
when generating inline PGP signed messages. It remains on for PGP/MIME
messages (which is the default for new users).
| I'd love to be proved wrong on this, since currently I'm stuck in my
| implementation of inline PGP and format=flowed, because of my
| perceived problems.
|
| I thing Gellens is right in that the there are more modes than what
| you describe. There are at least 4 incompatible ways to do inline
| PGP; QP before, QP after sign (but don't touch PGP armor), QP after
| sign (including PGP armor), don't QP at all. I have seen all of them
| in the wild. Incidentally, my experiences is that the last one works
| best, although it breaks the most specifications. The format=flowed
| draft says only one of the SHOULD be used even though it violate MIME.
I think you need to look at this problem from the recipients end to
actually decide what it is the sender needs to do. In particular its
important that the signature verify for both types of recipients: those
that are format=flowed aware and those that aren't. The later type
effectively determines the order of processing for flowing, PGP signing and
CTE:
A non-format=flowed aware client, when processing a received format=flowed
message, will first do CTE decoding and then display the message.
Verification of the signature will then be done on the unflowed text (i.e.
with trailing spaces and CRLFs etc).
Thus a format=flowed aware client that generates a message would first wrap
the text doing flow, then do the PGP signature, and then do CTE encoding.
That is the only way to work with non-aware clients.
That means a format=flowed aware client, when processing a received
format=flowed message, will first do CTE decoding. At that point it will
need to check for inline PGP and verify, then do flowing. Alternatively, it
will do CTE decode, flowing and display to the user. But then if the user
wants to verify, it will have to go back to the CTE decoded but not flowed
version.
All-in-all this is a mess. Frankly I think its better to state that
format=flowed SHOULD NOT be done on inline PGP signatures, instead PGP/MIME
SHOULD be used instead.
--
Cyrus Daboo