Ahmed,
thanks for your reply. The canonicalisation I refer to is defined in RFC45
section 6.6 page 19 and more specifically again in RFC2049 section 4 subsection
2 second paragraph page 10. It states:
"For example in the case of text/plain data, the text must be converted to a
supported character set and lines must be delimited with CRLF delimiters in
accordance with RFC 822..."
It is my interpretation that ALL embedded objects must have valid <CRLF> line
ends on their MIME headers. ALL body parts, except binary, must also have valid
<CRLF> line ends. Just as the outer MIME message has.
Your comments will be very much appreciated.
Regards,
Bartley.
-----Original Message-----
From: zahid.ahmed [SMTP:zahid(_dot_)ahmed(_at_)commerceone(_dot_)com]
Sent: Saturday, July 08, 2000 1:45 AM
To: bartley.omalley
Cc: zahid.ahmed
Subject: RE: Canonicalisation of embedded MIME objects
can you define what you mean by Canonicalisation of multipart mime?
What specific requirements and assumption you have?
thanks,
Zahid Ahmed
-----Original Message-----
From: bartley(_dot_)omalley(_at_)citicorp(_dot_)com
[mailto:bartley(_dot_)omalley(_at_)citicorp(_dot_)com]
Sent: Friday, July 07, 2000 2:57 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: FW: Canonicalisation of embedded MIME objects
I posted this earlier but got only one response and no help.
Can anyone help or point me in the right direction where I may find
clarification.
I am aware that the standards say "be modest in what you send
and generous in
what you accept" but It seems that a significant number of
people/implementers
are not following the standard as defined.
Bartley.
-----Original Message-----
From: O'Malley, Bartley
Sent: Friday, June 23, 2000 1:03 PM
To: 'ietf-smime'
Subject: Canonicalisation of embedded MIME objects
I have noticed that a number of files as produced by
different mail programs do
not seem to be performing canonicalisation of inner objects correctly.
The inner objects use LF for line termination not CRLF pairs.
It is my
understanding that breaks MIME rules for canonicalising
embedded objects.
To illustrate the problem I enclose a signed-then-encrypted
message I have
received:(I have removed the routing information)
The outer message appears as follows(All lines are terminated
with <CRLF>
pairs.).
-----------------------------------------------------------
Content-Type: application/pkcs7-mime;
smime-type=encrypted-data;
name="xxx.p7m"
Content-Disposition: attachment; filename=xxx.p7m
Content-Transfer-Encoding: base64
Message-ID: 19991015:080159:REF12345
MIIbrgYJKoZIhvcNAQcDoIIbnzCCG5sCAQAxggHEMIHfAgEAMEgwQDELMAkGA1
UEBhMCVVMx
ETAPBgNVBAoTCENpdGljb3JwMR4wHAYDVQQLExVFbnRydXN0IERldmVsb3BtZW
50IDICBDUa
:
:
VgIT6ci+93vJE1yRs4la/s3WjmovuOg/PSWUwXiw11EbAmBoB6CitHYFM/Q5sC
4RdXrwyH2l
1y59mZTTTtLwr7AbuOlojs/KrIe51CYQMeu14XN/K1tKZXpmB0qgcyDmXq69WY
Eo+aKglqhJ
--------------------------------------------------------------
------------------
----
The embedded message looks as follows(All lines are
terminated with <LF>).
--------------------------------------------------------------
--------------
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="xxx.p7m"
Content-Disposition: attachment; filename=xxx.p7m
Content-Transfer-Encoding: base64
Message-ID: 19990225:131734:20499
MIIggQYJKoZIhvcNAQcCoIIgcjCCIG4CAQExCzAJBgUrDgMCGgUAMIISiwYJKo
ZIhvcNAQcB
:
:
mXw0F0zhCL+ZZdic+fmLh1BQ+rIkVu45zKfJVSI1/F9oyZdaVFMkt0NZaGdjSl
vuG6deAhgZ
XJ0KskSW4qT5
--------------------------------------------------------------
---------------
The inner application file looks as follows: With Content
lines terminated with
<LF> and the data segment with no line ends.
--------------------------------------------------------------
--------------
Content-Type: application/EDIFACT;
name="xxx.edi"
Content-Transfer-Encoding: binary
UNA:+.? 'UNB+UNOA:1+
--------------------------------------------------------------
---------------
It is my interpretation that the use of <LF> to terminate the
Content headers
in the latter two messages above is not valid.
Can someone provide me with a definitive answer.
Thanks,
Bartley.