[Top] [All Lists]

Mail delivery error

1995-07-24 12:33:31
Note: This message was generated automagically. An error was detected,
while processing the enclosed message.

--> Error description: No such local user
--> Error for: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu

Returned mail follows.
X-Envelope-To: gyurik(_at_)frodo(_dot_)tii(_dot_)matav(_dot_)hu
Return-Path: <owner-ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>
Received: from ([]) by 
(SMTPSRV); Mon 24 Jul 1995 20:57
Received: from HUGBOX.SZTAKI.HU ([]) by (MX
          V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST
Received: from by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP;
          Mon, 24 Jul 1995 17:08:12 gmt+2
Received: (from daemon(_at_)localhost) by
          (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for
          ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400
Received: from ( []) by
          with SMTP id JAA17471 for 
<ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>; Mon, 24 Jul
          1995 09:55:54 -0400
Received: from by with SMTP
          ( id AA22427; Mon, 24 Jul 1995 10:02:19 -0400
Received: from by (5.0/SMI-SVR4) id
          AA11799; Mon, 24 Jul 1995 09:56:53 +0500
Received: by (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995
          10:01:01 +0500
From: tcrowley(_at_)kilsythe(_dot_)banyan(_dot_)com (Terry Crowley)
Message-ID: <BMSMTP80659212276(_at_)aberdeen(_dot_)banyan(_dot_)com>
In-Reply-To: <01HT7FU4EXI08ZFTD0(_at_)INNOSOFT(_dot_)COM>
Reply-To: Terry Crowley <tcrowley(_at_)aberdeen(_dot_)banyan(_dot_)com>
Date: Mon, 24 Jul 1995 10:01:00 -0500
Subject: Re: Multipart/Alternative Compatibility Issue
To: Ned Freed <NED(_at_)innosoft(_dot_)com>
CC: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Content-Length: 4243

It depends on what you mean by "bad".  ("Imagine every atom in your body
exploding at the speed of light...OK, good safety tip, don't cross the
beams.")  OK, not that bad if you get one of these messages every couple 
but imagine you have 150 messages in your inbox, every one of which 
that you go through this multi-step process just to look at what might be a
two sentence message.  I think that's worse than bad, that's horrible.  And 
can guarantee it would be sufficient to be a deal-breaker in many cases.  
sure you're familiar enough with the commercial market to know that 
fingers and saying "it's their fault!" doesn't get you very far with a
customer who just wants things to work.

Say what? What you've effectively done here is argue against your own chosen
approach! You're the one that has chosen to package multipart/alternative as
multipart/mixed, not me! 

By packaging things as multipart/mixed instead of using 
properly you guarantee that everyone with a *compliant* MIME agent has to go
through the very process you deplore. Were you to choose to package things
properly you would only have this problem with clients that treat
multipart/alternative as multipart/mixed, and no choice you make is going to
fix this behavior, so you'd best stop trying.

Hmm, well this conversation is definitely resulting in diminishing returns, 
but I'll try to clarify one point and keep it short.  I haven't argued against 
my approach.  The painful process described above results from 
multipart/alternative embedded in multipart/mixed.  If multipart/mixed is sent 
alone, then the text shows up right where it should, the problem is that this 
"useless" attachment, which can be ignored, also shows up.  The reader of the 
message is forced to look upon an attachment indicator, but doesn't need to 
take any extra steps to actually see the message body.

Perhaps we should attempt to shed some light on this topic.  How about some 
reports from the field about how different clients are actually handling 
multipart/alternative.  Does your client force you to make an explicit choice 
about which alternative you want to see on every multipart/alternative message 
you receive or do you configure it once?  Does it treat multipart/alternative 
as multipart/mixed?  If the message contains a nested hierarchy, are you 
forced to go through a two-step interaction to see embedded elements?

Maybe I'm not getting my real point across.  From a UI perspective, 
multipart/alternative and nested hierarchies are difficult to handle in a real 
clean way.  I'd say virtually every mail client that's being modified to 
handle MIME started off with no model of alternative content or of 
hierarchical structure.  Therefore, the MIME implementor needs to make a 
choice about how to handle it.  By far the simplest approach is to just treat 
mp/alternative as mp/mixed.  Another approach is to query the user, but I 
consider that a total mistake.  The best approach is to make a choice based on 
configuration information, perhaps provide some subtle indication that a 
choice was made, and then provide a way for the user to examine the choices 
and possibly make a different one explicitly.  I haven't seen any system that 
actually does this (Slate came close, but it wasn't always completely clear 
what part of the document the alternatives were tied to.)

Making these decisions consistently across clients is critical to 
interoperability.  As an analogy, look at the issue of line lengths.  
Everyone's read those virtually unreadable messages from someone writing in a 
window that lets them put 85 characters on a line.  Sure its 822 compliant, 
but that doesn't make it easy to read.

Anyone want to add some case histories to this discussion?

One example: A side conversation with Ray Langford from Frontier Technologies 
indicates that their SuperTCP mail client flattens hierarchy and treats 
mp/alternative as mp/mixed.  It also treats the first inline text part as the 
message body that is presented to the user.  The result of these choices is 
that both our encodings result in the same appearance to the user.


<Prev in Thread] Current Thread [Next in Thread>