>>>>> In <15566.1139355525@juniper.net> >>>>> "Mark D. Baushke" wrote: > > See RFC3156, section 4: > > > > 4. OpenPGP encrypted data > > > > Before OpenPGP encryption, the data is written in MIME canonical > > format (body and headers). > > > > Though I couldn't find the definition of "MIME canonical format", I > > believe that it was intended to have CRLF line-ending. > Hmmm... I also do not see the definition for "MIME canonical format" > so I am not sure. I found a clue in sylpheed-claws-users ML. http://sourceforge.net/mailarchive/message.php?msg_id=1636575 RFC 2045 (MIME) clearly says that CRLF is the normal line separator for MIME header fields. For body text, see RFC 2046 : The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden. > > > > For non-MIME encryption, line-ending conversion is not needed at all. > > > > > I disagree. This is what started the debate in the first place. > > > > > If I am sending a text message, then changing the line endings to CRLF > > > as is done in pgg-gpg-encrypt-region should also tell the remote end > > > that a text packet is coming rather than arbitrary binary data. > > > > I doubt that it is really necessary to be a text packet. Sorry, I misunderstood the problem. Now my understanding is that, the problem is, unless --textmode is specified, a sender and a receiver using non-MIME encryption have to make an out-of-band agreement to specify line endings. Right? If so, --textmode is still needed for non-MIME encryption. And also, if "MIME canonical format" in RFC3156 is intended to have CRLF line endings, specifying --textmode in PGP/MIME is harmless. However, always specifying --textmode might not be a good idea. Because applications other than MUA will need encryption of raw binary data. I attach a patch which allows users to select text-mode or binary-mode by setting pgg-text-mode.