[Top] [All Lists]

Re: Format=Flowed/RFC 2646 Bis (-02)

2003-11-14 17:56:02

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