Re: DOS text file attachments.

[Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday, February  7 at 12:01 AM, quoth scott.mutt@xxxxxxxxxxxxxx:
> I think the point that the people on the Postfix mailing list were trying 
> to make is that the MUA (in this case mutt) should not be sending 
> something to the MTA that is marked as text/plain, but has CRLF line 
> endings since text/plain on Unix has just LF line endings.

Mmmm, I would put it slightly differently, because it depends on who 
should be responsible for MIME encoding: the MTA or the MUA.

Each platform has it's own line-ending standard for "plain old text 
files". On the other hand, "text/plain" has a very specific 
line-ending meaning in the context of MIME encoding. As specified in 
RFC 2046, section 4.1.1:

     The canonical form of any MIME "text" subtype MUST always
     represent a line break as a CRLF sequence.  Similarly, any
     occurrence of CRLF in MIME "text" MUST represent a line break.
     Use of CR and LF outside of line break sequences is also
     forbidden.

It seems clear, then, that in sending a MIME-encoded object, labeled 
"text/plain", with the wrong line endings, someone is at fault. The 
line endings CANNOT be preserved if the file is to be sent encoded as 
a MIME text/* object.

But, and here's the trick: it *WAS* correctly formatted. It's just 
that ordinarily, things are *NOT* correctly formatted. The MTA world 
has gotten so used to converting line endings on behalf of the user 
that the MUA world now rarely considers line-endings to be a problem 
they need to address (unless the MUA will be speaking SMTP directly).

So who is wrong? Is mutt wrong for being inconsistent: handing 
incorrectly encoded text to the MTA most of the time but correctly 
encoded text some of the time? Or is the MTA wrong for being lazy and 
assuming that the MUA *always* sends incorrectly encoded text? In the 
end, I don't think it matters.

What if the file had been left as-is, and the line endings had been 
recognized as not needing conversion? The receiver would receive a 
correctly encoded text/plain attachment, and when saving that 
attachment to disk, his MUA would convert the line endings to whatever 
the native scheme happened to be. There would be no extra lines, BUT 
the file's status as a "DOS text" file would vanish the instant the 
"DOS" was dropped from the label---there's no such thing as 
"dostext/plain", after all.

In the end, I think it all comes down to expectations. Mutt deals in 
text files, and expects that all files labeled as text files will be 
"native" text files (for the obvious reason that this is almost always 
a correct assumption). Text is a special-case MIME category: it is a 
category that indicates that line-ending preservation is unimportant 
and may be converted to whatever is most convenient. This is 
relatively easy to work around with proper labeling: the goal is 
simply to avoid labeling the file as something whose line-endings can 
change as necessary (in other words: *any* non-text label will work). 
For example, one could add a line to the mime.types file like this:

     application/dostxt dostxt

Then all files ending in ".dostxt" will be safely base64 encoded 
before being sent. The file's line endings would be preserved, and all 
the recipient would have to do is decode the base64 encoding and 
rename the file back to ending in ".txt".

Unfortunately, there is no way to tell mutt that the ".txt" ending is 
ambiguous and files ending in ".txt" need to be handled two different 
ways depending on whether they're *native* text or weirdly-encoded 
text.

> Maybe I just tell mutt to use a shell script as the MTA and I get 
> that to convert all text to LF line endings then pass it on to the 
> real MTA. Would that work ?

That would assure that the DOS file was correctly encoded as a 
text/plain attachment, yes. However, it would also make it impossible 
to identify as a DOS-text file on the recipient's end. It would appear 
as a DOS-text file on a Windows system, and as a Unix-text file on a 
Unix system, and as a Mac-text file on a Mac.

So it depends on what problem you're trying to solve: if you're trying 
to send a DOS-file, intact, through email, this is a bad idea. If 
you're trying to send a recipient-dependent text file, no matter what 
format it's saved in on your own system, then this would work 
perfectly.

At that point, though, I'd question why on earth you were dealing in 
DOS files on your Unix box. :)

> I assume all data from mutt to the MTA will be text ? i.e.  already 
> be base64 encoded if needs be ?

Yes.

Does that help?
~Kyle
- -- 
If I were you, I'd run!
- -- Mesh-Head
If you were me, you'd be 
good-looking.
- -- the Six-String Samurai
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iD8DBQFHqqGqBkIOoMqOI14RAmcvAKCVXhBQgCRduyQdGLuToFBqmJxMIACfZc+q
SgQrTqfWZB7RUzZJsDbTY50=
=5W9G
-----END PGP SIGNATURE-----