--On Tuesday, 20 December, 2005 15:41 -0500 Carl Hester
<chester(_at_)haymakertech(_dot_)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(_at_)xxxxxxxx(_dot_)com>
Subject: AP File Export
Return-Path: systemadmin(_at_)xxxxxxx(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf