--On Wednesday, 07 September, 2005 23:23 -0400 "Robert A.
Rosenberg" <hal9001(_at_)panix(_dot_)com> wrote:
At 17:56 -0400 on 09/07/2005, John C Klensin wrote about
Classifying gateways in 2821/ 2821bis:
(iii) A gateway, defined as a transition/ translation
point between an SMTP environment and a non-SMTP
environment, as noted above. The expectation is that
gateways will only make those changes to message bodies
(including headers) that are actually necessary to
preserve the maximum amount of information as the
message passes from one environment to another.
Gratuitous "improvements" are inappropriate for
gateways, too.
I guess the AoL Email Gateway falls this "preserve the maximum
amount of information" requirement since it does not covert a
DNT Header into a RRR Flagged Message for incoming messages
from the Internet, Create a DNT Header in RRR Flagged Messages
it injects into the Internet SMTP Server, and when presented
with a incoming message from the Internet that has more than
one attachment, it does not covert all the attachments into
one Archived File unlike what occurs with multi-attachment
messages created on the AoL side of the Gateway,
All gateways lose information. Some lose more information than
others. A vendor with a losing or nonconforming gateway usually
decides to fix (or at least improve) that only when it has a
sudden attack of goodwill toward the general Internet community
or customer pressure pushes it in that direction. If the
vendor's marketing strategy assumes that, when a user gets
sophisticated enough to want and be sensitive too all of the
nuances possible with MIME messages, that user will probably
move on to other vendors or products whether the MIME issues are
corrected or not, there is little incentive to provide improved
MIME (or DN, or whatever) handling.
I observe that this problem doesn't only occur with email
gateways. There is reason to believe that completely adequate
MIME support in an MUA is impossible, or nearly so, as long as
the MUA preserves an "attachment" model rather than a "multiple
body part" one. Yet there is at least one MUA, supported by an
organization which has several employees active in the IETF,
that persists in treating body parts after the first as
"attachments" to be stored in a separate directory structure
without a full set of forward and back linking pointers.
Ultimately, all an IETF standard can do is to specify the
behavior that, if followed, will result in smooth operation and
good interoperability. The decisions of what do actually do and
not do are driven my some combination of the standard and any
given implementer or vendor's perception of market forces and
strategies.
We need to keep that in mind when debates start about what to
order people to do or not do in the text of our standards.
Note that I have not identified any specific vendors or products
above. For any relevant readers of this text, if the shoe fits,
try to enjoy wearing it.
john