[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: MIME Question - Boundary Redefined
From:       John C Klensin <john-ietf () jck ! com>
Date:       2005-12-20 21:48:46
Message-ID: 7F64EDE16E8B6434C697B9E8 () scan ! jck ! com
[Download RAW message or body]



--On Tuesday, 20 December, 2005 15:41 -0500 Carl Hester
<chester@haymakertech.com> wrote:

> Please excuse me if this is not the correct place to ask this
> question.
> 
> 
> 
> We are currently using libraries which send our mail in this
> format: 
> 
> -------------------------------------------------------------c
> lip (Misc headers)
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> boundary="=_622_1135029170_19710" To: <chester@xxxxxxxx.com>
> Subject: AP File Export
> Return-Path: systemadmin@xxxxxxx.com
> X-OriginalArrivalTime: 19 Dec 2005 21:56:36.0943 (UTC)
> FILETIME=[156365F0:01C604E7]
> 
> --=_622_1135029170_19710
> Content-Type: text/plain; charset="us-ascii"
> 
> --=_622_1135029170_19710
> Content-Type: application/octet-stream;
> boundary="=_622_1135029170_19710"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="AP File Export.dat"
> 
> 
> --=_622_1135029170_19710--
> --------------------------------------------------------------
> --clip
> 
> 
> I believe this looks OK, but CypherTrust IronMail sees this
> line as a MIME violation:
> 
> Content-Type: application/octet-stream;
> boundary="=_622_1135029170_19710"

Yes, you are confused.  The short answer is that "boundary" is
normally a parameter only to multipart types.  It cannot be a
parameter for application/octet-stream.

> CypherTrust says the same boundary cannot be redefined.  I
> believe this line would be OK if the boundary was removed
> altogether or if the boundary was unique and appropriately
> closed.  I am unable to find anything in the RFCs that tells
> me whether CypherTrust or our mail libraries are wrong.  

Whatever you are trying to do with that parameter is invalid
because it is not permitted to appear there.  And, yes, there is
no way to redefine the boundary at a given level midway through
the message.

FWIW, it looks like there may be some other problems with your
libraries.  For example, only the final delivery MTA is supposed
to insert a Return-path header.  If you are inserting one when
the message is sent, something is broken.   And, while it isn't,
if I recall, precisely a violation of the standard, the empty
first (text/plain) body part suggested by the above is at best
in bad taste.


> Thanks for any help.  

Good luck.
    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
[prev in list] [next in list] [prev in thread] [next in thread]