On 2000-12-05 17:23:30 -0500, Sam Varshavchik wrote:
> Well, I really think it's not really the MUA, but it's PGP/MIME
> that's broken.
As would be S/MIME (that stuff used by Outlook and Netscape). Sam,
I'd seriously suggest that, for the time being, you just implement
the standards which are generally accepted. If you want to change
these standards, go to www.ietf.org and suggest it to any relevant
working groups, or IETF circles. And, of course, to all those who
have implemented software based on these standards, including
Microsoft, RSA, and others.
> Doesn't anyone think that there's something wrong when some part
> of your SOP (Standard Operating Procedure) is to go through
> gyrations to make sure that your generated mail is encoded only
> by a *subset* of the allowed MIME encoding, as it seems that this
> RFC indicates?
Frankly, there is a design flaw in MIME, and that's permitting for
an 8bit encoding... I know some quite ugly and complex portions of
mutt which could be omitted if this encoding wasn't used at all.
Note, BTW, that using this encoding isn't strictly conformant to RFC
822.
> MIME provides a number alternative ways to encode mail content,
> so why should anyone have to restrict oneself to just a subset of
> the available encodings, for the purpose of implementing
> something? Doesn't it make sense to instead design your
> application, whatever you're trying to accomplish, so that it can
> be accomodate any kind of MIME encoding?
The problem is this: When signing MIME objects, you want to sign the
metadata (such as content-type and charset information, eventual
parameters, ...) as well. You can't confine yourself to just the
content, because this may leave interesting ways to tamper with
content - just consider those old exercises in writing programs
which compile in N+1 programming languages. Now, you could of
course invent some encoding which covers the metadata and the actual
content, before it's encoded.
BUT: How do you handle nested multiparts in such a scheme? How do
you handle nested multiparts, messages, etc, in such a scheme?
The simplest and most efficient way is to encode the actual content
in the most conservative way possible, and to sign the entire MIME
object.
As a rule of thumb, the fact that MIME permits for lots of encodings
doesn't mean you have to use all of them when sending messages, and
there's more than one argument for using only the most conservative
ones.
> If all you want to accomplish is to make sure that the *encoded
> content* is not altered during transport, than that's what
> PGP/MIME is apparently designed to do, so go ahead and use it.
See above.
> If you have mutt configured to submit mail by running sendmail,
> reconfigure it to submit mail by talking SMTP to localhost
> instead, after setting MIME=none.
Mutt does not talk smtp to localhost. There's ssmtp to do this.
> That's still will only help you with your own machine. You still
> have no control over what someone else will do to your mail.
Things would be fine if everyone, including you, would stick to the
relevant standards. I predict that your MTA will be discarded in
most production environments as soon as it turns out that it
corrupts messages by default. If you absolutely have to do MIME
mangling, make it optional, and tell users that they may be breaking
things.
--
Thomas Roessler <[EMAIL PROTECTED]>
