16

According to the Ubuntu uuencode manpage: Specifically, email cannot handle binary data and will often even insert a character when the six character sequence "0rom " is seen.

Is (or was) that even true? And why would that be the case? I suspect some historical reason, which is why I ask the question here.

4
  • 15
    I notice that the sequence 0rom is actually 5 characters. I wonder if the manpage intended to say something like >From
    – Bavi_H
    Commented May 24 at 18:48
  • 2
    Can you link the man page version that says this? I don't see it in man7.org/linux/man-pages/man1/uuencode.1p.html Commented May 24 at 18:54
  • 1
    I see it here: manpages.ubuntu.com/manpages/trusty/man1/uuencode.1.html
    – Bavi_H
    Commented May 24 at 19:07
  • 3
    As the answers say, it's From at the beginning of the line. You used to find printed books or published academic papers where you'd see ">From" at the beginning of a paragraph. (Probably still some on Google Books, actually ...)
    – davidbak
    Commented May 24 at 19:58

2 Answers 2

45

The text quoted in the question can be found on this web page. If you download the troff source (conveniently linked at the top of the page as uuencode.1.gz), you'll see that the raw manpage says

insert a character when the six character sequence "\nFrom " is seen.

The groff documentation here says that \n followed by a letter interpolates the value of the register with that name, and "If the register is undefined, it is created and assigned a value of ‘0’".

So it's just a bug in the man page. The correct statement is that some email (and Usenet) software will munge the five characters "From " at the start of a line (usually by adding > before F), because the Unix mbox format made the dubious decision to use that character sequence to mark the start of a new message.

13
  • 20
    @cjs some kind of framing akin to HTTP's chunked encoding, in which you get the length of the message, then the message, then the length of the next message, etc. That way you're not interpreting the whole contents of each message to figure out whether it's actually the start of the next. They can be forgiven for not having invented maildir or MH or sqlite in the 1970s, but real messages with paragraphs beginning "From" would have been an immediately obvious problem.
    – hobbs
    Commented May 25 at 14:12
  • 2
    They can only be "forgiven" in the sense that any programmer can be forgiven for doing something quick and dirty and not thinking carefully about the consequences. Personally, I'm not so forgiving. Commented May 26 at 13:24
  • 2
    @cjs Any format that creates an ambiguity will always, objectively, be worse than one that doesn't. There may be some compromises to do, in terms of data size for example, but ambiguity should simply be unacceptable. The non-dubious descision would have been to choose a non-ambiguous format.
    – dim
    Commented May 27 at 13:16
  • 3
    @cjs The primary issue is that while mbox transforms \nFrom to \n>From , it does not transform \n>From to \n>>From etc. Therefore it is not possible to tell if a sequence \n>From was originally From or >From. That makes it ambiguous, as when reading the mbox, it is not possible to reverse the process.
    – Ben
    Commented May 27 at 15:24
  • 3
    @Ben Some software did escape >From to >>From. Wikipedia says so, and I remember it being common in the wild. If all software had escaped that way when writing and de-escaped when reading then there would have been no problem, but there was no standardization.
    – benrg
    Commented May 27 at 20:15
8

I notice that the sequence 0rom is actually 5 characters. I wonder if the manpage intended to say something like >From

E-mail software sometimes stores multiple e-mail messages together in a single text file called the mbox format. This format uses a line beginning with From to mark the beinning of a stored e-mail message. In order to actually have a line beginning with From in the content of an e-mail message, there has some kind of transformation rules used, called From-munging. If the transformation rules create any ambiguous situations, then when the message is re-opened, the content of the e-mail might be changed from how it was originally composed.

For example, if you wrote an e-mail that contained the following:

From the mountains to the prairies
To the oceans white with foam

The next time you opened the e-mail it might look like this:

>From the mountains to the prairies
To the oceans white with foam

Or if someone quoted the lines like this:

>From the mountains to the prairies
>To the oceans white with foam

it might look like this when they re-open the e-mail:

From the mountains to the prairies
>To the oceans white with foam

I don't think any e-mail transmission servers need to do this transformation, only e-mail client software that you use to read and save your e-mails. However if anyone copies content from a previous e-mail and their e-mail client didn't have a fully reversible transformation, then you might see these kinds of problems even if your e-mail client and the e-mail transmission path itself has no problems.

2
  • 2
    Mail transmission servers do often perform this munging on the recipient side, as traditionally they're the ones that initially deposit the message in the user's /var/spool/mail/xxx mbox file for the client software to see.
    – grawity
    Commented May 25 at 8:21
  • 1
    From-munging would have worked perfectly well if it had been implemented consistently. First of all, it's only an issue while the message is actually in an mbox. So, when putting the message in the mbox, you add one '>' to any line matching /^>*From/, and when taking the message out of the mbox, you delete one '>' from any line matching /^>+From/. No one would ever have noticed.
    – Dave Tweed
    Commented May 25 at 23:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .