[Top] [All Lists]

Mail delivery error

1995-07-21 17:47:16
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); Sat 22 Jul 1995 01:56
Received: from HUGBOX.SZTAKI.HU by (MX V4.1 VAX) with SMTP;
          Thu, 20 Jul 1995 16:18:28 MET_DST
Received: from by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP;
          Thu, 20 Jul 1995 16:20:04 gmt+2
Received: (from daemon(_at_)localhost) by
          (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA29623 for
          ietf-822-list; Thu, 20 Jul 1995 09:11:08 -0400
Received: from ( []) by
          with SMTP id JAA29620 for 
<ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>; Thu, 20 Jul
          1995 09:11:01 -0400
Received: from by with SMTP
          ( id AA21478; Thu, 20 Jul 1995 09:17:33 -0400
Received: from by (5.0/SMI-SVR4) id
          AA10517; Thu, 20 Jul 1995 09:12:08 +0500
Received: by (5.0/SMI-SVR4) id AA03539; Thu, 20 Jul 1995
          09:16:11 +0500
From: tcrowley(_at_)kilsythe(_dot_)banyan(_dot_)com (Terry Crowley)
Message-ID: <BMSMTP80624467710(_at_)aberdeen(_dot_)banyan(_dot_)com>
In-Reply-To: <01HT2BTZ7TRWASBNL0(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
Reply-To: Terry Crowley <tcrowley(_at_)aberdeen(_dot_)banyan(_dot_)com>
Date: Thu, 20 Jul 1995 09:16:10 -0500
Subject: Re: Multipart/Alternative Compatibility Issue
To: Ned Freed <NED(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
CC: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Content-Length: 1817

I use a couple of different MIME clients, none of which have any problems 
getting at the data in multipart/alternative. The worst I've seen is where
multipart/alternative is treated as multipart/mixed, and this just isn't 

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 days, 
but imagine you have 150 messages in your inbox, every one of which requires 
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 I 
can guarantee it would be sufficient to be a deal-breaker in many cases.  I'm 
sure you're familiar enough with the commercial market to know that pointing 
fingers and saying "it's their fault!" doesn't get you very far with a 
customer who just wants things to work.

The MIME spec says that "Receiving user agents should pick and display the 
last format they are capable of displaying."  I'd argue that by just showing 
the multipart/alternative object, those user agents have not done any picking. 
 From a practical point of view, this behavior, if typical of MIME user agents,
 makes multipart/alternative significantly less useful.  These aren't 
abstractions.  We give the customer a choice of what format to use, and they 
are choosing to use the multipart/mixed form since they find that it 
introduces less problems (e.g. users complaining to the mail administrator) in 
real day-to-day heterogeneous message exchange.  That's a fact, and no amount 
of explaining the advantages of semantic accuracy will make them happy.  They 
just want to read the damn message (and probably delete it).

From ITUDOC(_dot_)ITUDOC(_at_)ITU(_dot_)CH Sat 22 Jul 1995 02:16

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