Re: Trailing whitespace and PGP/MIME

[Simon Josefsson <jas@extundo.com>]

Jesper Harder <harder@ifa.au.dk> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Jesper Harder <harder@ifa.au.dk> writes:
>>
>>>    implementations MUST make sure that no trailing whitespace is
>>>    present after the MIME encoding has been applied.
>>>
>>> Fixing it the obvious way would, however, break the intention of this
>>> change:
>>>
>>> 2003-10-27  Simon Josefsson  <jas@extundo.com>
>>>
>>> 	* mm-bodies.el (mm-body-encoding): Don't use QP when message body
>>> 	only consists of short lines and ASCII, when
>>> 	mm-use-ultra-safe-encoding.
>>
>> I think detecting if there are trailing SPC, and using QP in that case
>> is reasonable.  Does this work?
>>
>> -		     (save-excursion (re-search-forward "^From " nil t))))
>> +		     (save-excursion (or (re-search-forward "^From " nil t)
>> +					 (re-search-forward " $" nil t)))))
>
> Yes, but this was what I meant by "the obvious way" :-)

Ah.

> It'll fix pgp/mime, but it will also force QP for inline pgp if you
> use a signature -- which for a lot of people means _always_ -- thus
> more or less reverting the intention of your previous change.

Ah.  Hm.  Er.  So what IS the right thing?  The MUST above is for
PGP/MIME, yes, but the _reason_ the MUST is there in the document is
about as valid for plain PGP as it is for PGP/MIME, I think, arguing
that the obvious approach is the right.

One (non-)solution is to warn the user whenever the message content
may not work reliably with plain PGP and ask the user if she wants to
continue, or use PGP/MIME instead.  There are many things on this list
now, e.g., non-ASCII, trailing unencoded SPC, data that look dash
escaped.  This would be a useful feature, but just move the problem
into the face of the user instead of solving it, and I doubt most
users understand nor want to understand the problem.