--On Sunday, 14 July, 2002 06:50 +0900 Dave Crocker
<dcrocker(_at_)brandenburg(_dot_)com> wrote:
...
Ever since multi-recipient addressing was introduced, we have
had downgrading, by virtue of users having to choose the least
common denominator approach to sending attachments.
So the fact that this new mechanism allows that downgrading to
happen later in the transmission sequence should not confuse
anyone into thinking that downgrading is a new or unusual
requirement.
...
Dave, I want to be sure I understand what you are saying here,
because, if I am reading it correctly, I find it astonishing.
First of all, I don't find, anywhere in the document, a statement
that the originator, in attempting to use CONNEG, is authorizing
any intermediate MTA that might touch the message to alter its
content. Nor do I find in the "security considerations" an
explanation of that authorization and the associated risks. If
such text is actually there, then some of what follows may be
irrelevant (although it wouldn't convince me it is a good idea).
Certainly, originating MUAs downgrade and change formats based on
what they, on behalf of the user, believe the recipient will be
able to process and have done that for a long time. But they do
so before the message enters a transmission stream. We have
typically tried to keep that transmission stream as opaque to
message content as possible. In recent years, we have made some
formal allowances for fixups by originating MTA for
low-capability MUAs, but we have rather carefully delimited them
(see sections 3.7, 6.1, and 6.3 of RFC 2821 (the references to
section 2.4.1 are incorrect and should refer to 6.3)).
We also permit downgrading through ESTMP options like 8BITMIME,
which is quite explicit that an initiator who asks for this
feature is agreeing to a (very specific, known-result) downgrade
by relaying systems.
But, unless I read the above incorrectly, you are suggesting that
* Since the originating MUA clearly has the ability and
authority to alter content to reflect its assumptions
about receiver capability (before the content is handed
off to an SMTP server and placed into the transport
stream)
* Other alterations to content ("downgrades") are just
moving the process "later in the transmission sequence"
* Hence intermediate/relay MTAs have the right/authority
to make content changes based on their inferences about
what the receiver wants.
I hope that isn't what you meant, because it is pretty scary. It
also creates a contradiction between this draft and RFC 2821 (as
well as the way most of us have read 821 for years), raises a
collection of security issues (e.g., in-transit downgrading would
seem to me to be quite hard on signed content), and so on.
Could you explain what you did mean?
john