-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday, February 7 at 12:01 AM, quoth [EMAIL PROTECTED]:
> 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-
