[Top] [All Lists]

Mail delivery error

1995-07-24 22:22:19
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); Tue 25 Jul 1995 07:06
Received: from HUGBOX.SZTAKI.HU by (MX V4.1 VAX) with SMTP;
          Tue, 25 Jul 1995 06:34:06 MET_DST
Received: from by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP;
          Tue, 25 Jul 1995 06:35:31 gmt+2
Received: (from daemon(_at_)localhost) by
          (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id XAA06554 for
          ietf-822-list; Mon, 24 Jul 1995 23:34:56 -0400
Received: from (root(_at_)ns(_dot_)frontiertech(_dot_)com 
[]) by
          with ESMTP id XAA06551 for 
<ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>; Mon, 24 Jul
          1995 23:34:55 -0400
Received: by FrontierTech.COM (8.6.9/8.6.9) with SMTP id WAA11301; Mon, 24 Jul
          1995 22:29:32 -0500
X-Mailer: SuperTCP Pro for Windows Version 1.1 (Mailer Version 1.02)
Message-ID: <3014655A-00000001(_at_)rock105(_dot_)FrontierTech(_dot_)com>
From: Ray Langford <Ray(_at_)frontiertech(_dot_)com>
Date: Mon, 24 Jul 1995 22:30:33 cdt
Subject: Re: Multipart/Alternative Compatibility Issue
To: Terry Crowley <tcrowley(_at_)aberdeen(_dot_)banyan(_dot_)com>, Ned Freed
CC: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Reply-To: Ray(_at_)frontiertech(_dot_)com
MIME-Version: 1.0
Content-Type: Text/Plain; Charset=US-ASCII

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.


Yes, this is the way our Email works.  We chose to do this because our mail 
system is MAPI compliant.  The MAPI structures define a notetext and flat 
(no hierarchy) attachments. We currently treat a MIME message as an equal 
collection of parts (attachments) and attempt to find a notetext (the first 
text part).  

I agree that mp/alternative could be handled better by only keeping and 
showing one alternative (of the users choice through configuration) but 
there are a number of reasons why this could be problematic in our current 
MAPI compliant mail system.  We are looking into this and also 
Content-Disposition as ways to address these issues.

However, in retrospect, SuperTCP MIME Email has been shipping now for over 
21/2 years (over 200,000 copies) and we haven't received a single complaint 
about how we handle mp/alternative :-).  I also don't think that there are 
many people (programs) that create mp/alternative messages... yet :-).

[Sorry to readers if I have wandered too far off the topic (I am on 
vacation and actually have time to read and respond to the list).]

Ray C. Langford
Engineering Manager, Advanced Products
Frontier Technologies Corp.
Email: Ray(_at_)FrontierTech(_dot_)com
Voice: (414) 241-4555 x205

Tue 25 Jul 1995 07:26

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