Re: the right bug severity in case of mbox formats
On 28/11/12 15:34, Darren Salt wrote:
> Having just viewed the raw text of my message (as sent), there's one other
> little wrinkle which I already knew but had failed to consider and which
> makes testing of this useless: gpg handles any 'From ' lines itself in a
> reversible manner, using '- ' as the prefix.
So, so far in this thread we've seen that:
* There are certain messages which are losslessly representable in SMTP
without using MIME, but not losslessly representable in mboxo format
without using MIME; namely, those where a line of the message text
starts with "From " (which become indistinguishable from
messages where a line intentionally started with ">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). Darren's, which appears to
be "Messenger-Pro", appears to do so without special effort from him.
* 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.
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. May I suggest the same
approach to mboxo?
I would personally say that an appropriate severity would go something
like this:
foo produces/consumes mboxo format: wishlist, potentially wontfix (poor
design choice)
foo produces/consumes "mbox format" without documenting whether it means
mboxo or mboxrd: minor (documentation bug)
foo produces emails formatted for transmission and does not avoid them
matching /^From /, e.g. by using QP: minor or perhaps normal, depending
on context (interop bug, Postel's principle)
foo receives general-purpose email but does not understand MIME,
quoted-printable and Base64: important (severe interop bug, Postel's
principle, deficient i18n, and applications have already had 20 years to
implement MIME)
Regards,
S
[1] may work, or not, depending on the chain of MTAs involved
Reply to: