This is reported against 0.9.8; please open a new ticket if still a problem
with current releases.
also not clear it was really an interop problem at all.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe:
Hello Lloyd,
On Monday, January 15, 2007 at 23:32:33 +0100, Lloyd Parkes via RT wrote:
The larger problem is that the smime command doesn't generate valid
S/MIME output.
Right: Outside of some very basic cases, like English Ascii text,
OpenSSL isn't enough MIME-aware to be usable alone.
[EMAIL PROTECTED] - Wed Jan 17 20:15:49 2007]:
Right: Outside of some very basic cases, like English Ascii text,
OpenSSL isn't enough MIME-aware to be usable alone. There is still a
need for pre- and post-processing around OpenSSL before a proper mail
can be fed to an MTA. The presence
I would like to propose an alternate solution to this problem because I think
this issue is part of a slightly larger problem.
The larger problem is that the smime command doesn't generate valid S/MIME
output. It has probably never generated valid S/MIME output, and it hasn't been
much of a
IMHO the best solution is to have a filter BIO which can handle the
necessary canonicalisation and/or conversion to local eol format.
That kind of thing will be needed if and when full streaming is
supported anyway.
__
OpenSSL
Hello Roumen,
On Sunday, October 22, 2006 at 14:20:49 +0200, Roumen Petrov via RT wrote:
Proposed patches:
a.) apps-smime.patch : proper eol for To,From and Subject headers in
case of -crlfeol command line option.
Very good, thank you. Only the smime.p7s base64 lines remain ending
in
Proposed patches:
a.) apps-smime.patch : proper eol for To,From and Subject headers in case of
-crlfeol command line option.
b.) crypto-pkcs7-pk7_mime.patch :
- add header in case of binary procesing
- add empty line (mandatory) if procesing type is not specified
(case without -text and
Hello Roumen,
On Tuesday, October 17, 2006 at 17:52:34 +0200, Roumen Petrov via RT wrote:
Please could you defail used software.
The simplest failing setup is:
-a) Sending Linux Debian Woody box:
- OpenSSL 0.9.8d (built from tarball)
- Exim 3.35-1woody2
- Qpopper 4.0.4-2.woody.1
Hello Bruno,
Please could you defail used software.
During the past weekend I have time to setup a test network:
linux box:
- sendmail 8.12.9
- popa3d 0.6.1
- Mozilla 1.7.13 email client
ms windows me (at last i found a PC with operating system that use CRLF as EOL):
- Mozilla 1.7.13 email
Hello Roumen,
On Monday, October 2, 2006 at 23:48:12 +0300, Roumen Petrov wrote:
Bruno Kozlowski via RT wrote:
The resulting mailfile has mixed EOLs: Most lines end in LF, but
3 lines end in CRLF
I think that this is correct - EOL for emails(headers, empty line,
body) is CRLF, but at
Hello,
On the Linux platform, OpenSSL generating an S/MIME clearsigned mail
introduces spurious CRs at the end of some lines of the output.
Depending on mail transport conditions, those CRs can break signature
verification in MSOE on MS-Windows.
Example: I want to clearsign some text.
Bruno Kozlowski via RT wrote:
[SNIP]
The resulting mailfile has mixed EOLs: Most lines end in LF, but
3 lines end in CRLF:
| $ cat -A mailfile | grep \^M
| Content-Type: text/plain^M$
| ^M$
| some text^M$
I think that this is correct - EOL for emails(headers, empty line, body) is
CRLF,
Roumen Petrov wrote:
Bruno Kozlowski via RT wrote:
[SNIP]
The resulting mailfile has mixed EOLs: Most lines end in LF, but
3 lines end in CRLF:
| $ cat -A mailfile | grep \^M
| Content-Type: text/plain^M$
| ^M$
| some text^M$
I think that this is correct - EOL for emails(headers,
13 matches
Mail list logo
