hi
(as some will know) i've been working on an PGP/MIME (RFC3156)
signing mailet. my reading of the specification leads me to believe
that i should canonicalise the content to be signed. this involves
stuff like altering whitespace and forcing 7 bit-safe content transfer
encoding.
i'm having difficult determining the right (or best, if there is no
right) way to do this via the javamail API. suggestions?
- robert
To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

IIRC javamail already is very strict in reading emails. So if you do
things via javamail it should canonicalise it automatically.
The problem you could encounter is that sometimes javamail will throw
parsing exception instead of trying to fix the read email.

Stefano

robert burrell donkin wrote:
hi

(as some will know) i've been working on an PGP/MIME (RFC3156)
signing mailet. my reading of the specification leads me to believe
that i should canonicalise the content to be signed. this involves
stuff like altering whitespace and forcing 7 bit-safe content transfer
encoding.

i'm having difficult determining the right (or best, if there is no
right) way to do this via the javamail API. suggestions?
- robert

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/22/06, robert burrell donkin <robertburrelldonkin (AT) gmail (DOT) comwrote:
hi

(as some will know) i've been working on an PGP/MIME (RFC3156)
signing mailet. my reading of the specification leads me to believe
that i should canonicalise the content to be signed.

what a PITA!
You can create a MimeMessage and get its bytes out in a stream, if
thats what you need to do. You can do it for a "Part"
(#getContentStream())

Perhaps that isn't what you're after?

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/24/06, Danny Angus <danny.angus (AT) gmail (DOT) comwrote:
10/22/06, robert burrell donkin <robertburrelldonkin (AT) gmail (DOT) comwrote:
hi

(as some will know) i've been working on an PGP/MIME (RFC3156)
signing mailet. my reading of the specification leads me to believe
that i should canonicalise the content to be signed.

what a PITA!
You can create a MimeMessage and get its bytes out in a stream, if
thats what you need to do. You can do it for a "Part"
(#getContentStream())

Perhaps that isn't what you're after?

i start with a part. i could canonicalize just the signing stream
without canonicalizing the actual content part. this would produce a
signature that most PGP/MIME readers would verify ok but the
specification implies that the part content itself should be
canonicalised as well. i'd much prefer to be specification compliant.

i suppose that the canonicalized stream could be used to create a new
part containing the canonicalized content. what i don't really
understand is how i can ensure that the content-transport-encoding
used to send the message is correct (the spec says Quoted-Printable or
Base64 MIME only) or indeed if i can using javamail.
- robert

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

robert burrell donkin wrote:
10/24/06, Danny Angus <danny.angus (AT) gmail (DOT) comwrote:
>10/22/06, robert burrell donkin <robertburrelldonkin (AT) gmail (DOT) comwrote:
>hi
>>
>(as some will know) i've been working on an PGP/MIME (RFC3156)
>signing mailet. my reading of the specification leads me to believe
>that i should canonicalise the content to be signed.
>>
>what a PITA!
>You can create a MimeMessage and get its bytes out in a stream, if
>thats what you need to do. You can do it for a "Part"
>(#getContentStream())
>>
>>
>Perhaps that isn't what you're after?

i start with a part. i could canonicalize just the signing stream
without canonicalizing the actual content part. this would produce a
signature that most PGP/MIME readers would verify ok but the
specification implies that the part content itself should be
canonicalised as well. i'd much prefer to be specification compliant.

i suppose that the canonicalized stream could be used to create a new
part containing the canonicalized content. what i don't really
understand is how i can ensure that the content-transport-encoding
used to send the message is correct (the spec says Quoted-Printable or
Base64 MIME only) or indeed if i can using javamail.
- robert

In Javamail if you change the content-transport-encoding for a part,
call saveChanges and then you try to write that part to an outputstream
it will be streamed with the correct encoding.

part.setHeader("Content-Transfer-Encoding", "quoted-printable");

you may want, for example, to read the content in 8bit first, to
understand how much non 7bit chars are present: if less than 10-20% is
binary use quoted-printable otherwise base64.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

10/28/06, Stefano Bagnara <apache (AT) bago (DOT) orgwrote:
robert burrell donkin wrote:
10/24/06, Danny Angus <danny.angus (AT) gmail (DOT) comwrote:
>10/22/06, robert burrell donkin <robertburrelldonkin (AT) gmail (DOT) comwrote:
>hi
>>
>(as some will know) i've been working on an PGP/MIME (RFC3156)
>signing mailet. my reading of the specification leads me to believe
>that i should canonicalise the content to be signed.
>>
>what a PITA!
>You can create a MimeMessage and get its bytes out in a stream, if
>thats what you need to do. You can do it for a "Part"
>(#getContentStream())
>>
>>
>Perhaps that isn't what you're after?
>
i start with a part. i could canonicalize just the signing stream
without canonicalizing the actual content part. this would produce a
signature that most PGP/MIME readers would verify ok but the
specification implies that the part content itself should be
canonicalised as well. i'd much prefer to be specification compliant.

i suppose that the canonicalized stream could be used to create a new
part containing the canonicalized content. what i don't really
understand is how i can ensure that the content-transport-encoding
used to send the message is correct (the spec says Quoted-Printable or
Base64 MIME only) or indeed if i can using javamail.

- robert
--
In Javamail if you change the content-transport-encoding for a part,
call saveChanges and then you try to write that part to an outputstream
it will be streamed with the correct encoding.

part.setHeader("Content-Transfer-Encoding", "quoted-printable");

you may want, for example, to read the content in 8bit first, to
understand how much non 7bit chars are present: if less than 10-20% is
binary use quoted-printable otherwise base64.

thanks to everyone for the help. that seems to be under control.

canonicalisation involves converting line endings to a standard
format. what worries me a little is that javamail uses inputstream's
and outputstream's which means encoding may be an issue. it would be
ok to use byte-wise comparisons for latin encodings but this may well
break when faced with multibyte encoding schemes (for example
shift-JIS).

have i missed anything?

but to use a reader, an charset encoding is required.

there doesn't seem to be any way to get this directly from the
javamail. have i missed anything?

if not then if the content-type contains a charset then i suppose that
this could be used. would this work?

in the absence of a charset in the content-type, what's the best approach?
- robert

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

11/5/06, robert burrell donkin <robertburrelldonkin (AT) gmail (DOT) comwrote:

canonicalisation involves converting line endings to a standard
format. what worries me a little is that javamail uses inputstream's
and outputstream's which means encoding may be an issue. it would be
ok to use byte-wise comparisons for latin encodings but this may well
break when faced with multibyte encoding schemes (for example
shift-JIS).

Robert,
How's tricks?
just my 2c here, I've always fought shy of this problem(!)

Welcome to our world. of the problems we face is that Java (in
general) handles encodings and charsets and all that unecessary
confusion "under the hood", byte[]->String conversions aren't the most
convenient things to have to deal with. But because MIME has a pretty
complete answer to sending non-ascii encodings and character sets
using only ascii it is probaly easier to keep it all in perspective
using byte[]'s

What might make sense is to assume that JavaMail follows the rules,
and check the MIME RFC for details of how to handle encodings. Knowing
email like I do I would expect that the rule is that whatever would
have been used without announcement in the "olden days" is assumed to
be in use where no announcement is present. i.e. plain old ASCII. So
if you read the headers and find no encoding you could bet that your
assumptions for Latin encodings will apply.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org