unknown
1970-01-01 00:00:00 UTC
Nobody should be using vanilla mbox format - it was obviously an appalling
idea even when it was invented, and it's absurd that anybody's still
using it now.
I use MMDF format, which is less fragile; but can still be bitten by
having its message delimiters ("\001\001\001\001\n") appear within
message text.
So yes, if one uses such primitive formats, one has to worry about
this.
It would be better if we could force everybody to use a format with
content-length, or file-per-message; but content-length is also
fragile, as a single error breaks things badly.
messages, so why would you be reading non-text data?
automatically handle 8bit mail.
idea even when it was invented, and it's absurd that anybody's still
using it now.
I use MMDF format, which is less fragile; but can still be bitten by
having its message delimiters ("\001\001\001\001\n") appear within
message text.
So yes, if one uses such primitive formats, one has to worry about
this.
It would be better if we could force everybody to use a format with
content-length, or file-per-message; but content-length is also
fragile, as a single error breaks things badly.
But there are ramifications to having raw binary data in email
messages beyond the scope of vm. Imagine reading a message with raw
binary data in an xterm with emacs -nw - see your terminal window go
Most people don't insert random binary junk into the text of theirmessages beyond the scope of vm. Imagine reading a message with raw
binary data in an xterm with emacs -nw - see your terminal window go
messages, so why would you be reading non-text data?
catty-wompus with the right combination of bytes. Or through a telnet
session. Also trying to send non 7-bit ascii in a message through
some mailers might cause issues (possibly less so in this day and
I'd be surprised if there are any mailers left that don'tsession. Also trying to send non 7-bit ascii in a message through
some mailers might cause issues (possibly less so in this day and
automatically handle 8bit mail.