Subject: MIME Question - Boundary Redefined

From: "Carl Hester" <[email-masked]>
Date: Tue, 20 Dec 2005 15:41:57 -0500

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: 

-------------------------------------------------------------clip
(Misc headers)
To: <[email-masked]>
Subject: AP File Export
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"

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.  

Thanks for any help.  

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 20 Dec 2005 22:14:36 +0100

> anything in the RFCs that tells me whether CypherTrust or our mail

CypherTrust is right in flagging it as an error. The 
application/octet-stream type does not have a boundary parameter, so you 
should not be sending it.
RFC 2046 section 4.5.1.

OTOH, CypherTrust is not quite right, because having an extra parameter on 
an inner application/* subpart should not change the parsing of the outer 
part, even though it has the same name as the parameter on the outer part.
No specific reference, but 2046 section 5.1.2 kind of implies that.

How's that for saying "you're both right and both wrong"? :-)

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Dec 2005 16:31:57 -0500

> CypherTrust says the same boundary cannot be redefined.  

the error message is misleading, and it probably does indicate a bug in
CypherTrust.  there is also a bug in the library you are using to
generate these messages.

the application/octet-stream does not have a boundary parameter defined
for it, so this parameter is meaningless and should not be included by
your library.

on the other hand, CypherTrust also seems to be buggy, or at least
confused. content-type parameters are defined on a per-content-type
basis. if there were a boundary parameter defined for
application/octet-stream it would not have the same meaning as the
boundary parameter for multipart.   it is always possible that a
content-type can be redefined to have new parameters.  message reading
software should not make assumptions about the meaning of unrecognized
parameters.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Dec 2005 16:48:46 -0500

--On Tuesday, 20 December, 2005 15:41 -0500 Carl Hester
<[email-masked]> wrote:

> -------------------------------------------------------------c
> lip (Misc headers)
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> boundary="=_622_1135029170_19710" To: <[email-masked]>
> Subject: AP File Export
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 19 Dec 2005 21:56:36.0943 (UTC)
> I believe this looks OK, but CypherTrust IronMail sees this
> line as a MIME violation:
> 

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