Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

[Ken Hornstein]

>Well, gosh. I stand corrected; I should have read RFC 822 before
>making that decision (back whenever it was). I can only assume
>that I had based it on what I thought was allowed in mail before
>RFC822. If I had been designing SMTP I wouldn’t have allowed all
>128 ASCII characters. The first 8 would have been forbidden, for
>a start. Then we could have used ETX to mark the end of the
>body, and not <CRLF>.<CRLF>, which can legitimately appear in a
>text message. But I wasn’t, so they weren’t and we couldn’t. Oh
>well.

Yeah, I was curious and I went and looked at RFC 733 (the precursor to
RFC 822); it also allows 0-177 for message bodies.  You have to read it
carefully, though, to get that information out.

However, regarding SMTP ... I think you're conflating things a bit.
There are, AFAIK, no issues with the SMTP _protocol_ in terms of message
mangling; the end-of-message indicator and dot-stuffing protocol used
there is well defined and reversable.  The issue is the _maildrop_ format,
which as far as I can tell never has been formally defined nor did anyone
ever sit down and try to design the format properly.

FWIW, if you have a local maildrop and you don't want From-munging, looks
like the simplest thing to do is just switch to Maildir, which inc(1)
does support (and it has for a while).  For archiving (I know that's your
particular use case, Jón), I think something like tar makes sense.

--Ken