On Wed, 2012-11-28 at 19:16 +0000, Simon McVittie wrote: > * There are certain messages which are losslessly representable in SMTP > without using MIME, but not losslessly representable in mboxo format > without using MIME; yes,... but of course MIME standards neither demand any quoted-printable quoting of From_ lines... so just because a message uses MIME, this doesn't mean one is safe. > namely, those where a line of the message text > starts with "From " (which become indistinguishable from > messages where a line intentionally started with ">From "). And of course the more deeply quoted levels (>>From ...) > * MUAs that perform GPG clearsigning are mandated to avoid sending such > messages (as in: there is an easy and interoperable way not to, and > the OpenPGP RFC says they SHOULD use it). AFAIU, this is only a SHOULD, right? And of course it doesn't help in cases, where one really uses gpg for singing,.. and manually copy&pastes it to the MUA. May I further remind people, that it's not only signatures that may cause trouble: - People may interpret their mails in scripts,... admittedly this is probably less often the case. - "Binary" (in the sense: it should not be modified) content like diff output may easily get mangled up. > * If you don't restrict yourself to avoiding MIME, any piece of text > (or indeed any bytestring) becomes losslessly representable. In > particular, MUAs supporting quoted-printable and/or Base64 can avoid > sending messages matching /^From / by using MIME and > quoted-printable-encoding them. Adam's MUA, which appears to be mutt, > does so by using QP, without special effort from him. See my other post where I mention that a) there is no MUST for this kind of quoting and b) most MUAs I've seen so far that do it, do it incompletely. > There are many other classes of message which are not losslessly > representable via SMTP without using MIME, including messages not > exclusively written in US-ASCII[1], messages where the use of "rich > text" is significant, messages with attachments, messages with very long > lines[1], and messages where choice of newline convention is > significant. Most people seem to solve this by using MIME, rather than > by characterizing SMTP as data corruption. I'm not sure whether you can apply the same principle here. When restricting yourself to plain SMTP (without mime and without UT8SMTP) then you have of course a very limited charset. But this doesn't mean already that you get any form of corruption... There only would be such an issue, if your MUA e.g. allows you to enter Unicode characters, mangles them up to 7-bit SMTP but doesn't warn you. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature