Re: MIME canonicalisation

[robert burrell donkin <ro...@gmail.com>]

On 10/28/06, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin wrote:
> > On 10/24/06, Danny Angus <da...@gmail.com> wrote:
> >> On 10/22/06, robert burrell donkin <ro...@gmail.com> wrote:
> >> > hi
> >> >
> >> > (as some will know) i've been working on an OpenPGP/MIME (RFC3156)
> >> > signing mailet. my reading of the specification leads me to believe
> >> > that i should canonicalise the content to be signed.
> >>
> >> Oh 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"
> >> (http://java.sun.com/products/javamail/javadocs/javax/mail/internet/MimeBodyPart.html#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 OpenPGP/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@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: MIME canonicalisation

[Danny Angus <da...@gmail.com>]

On 11/5/06, robert burrell donkin <ro...@gmail.com> wrote:

> 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. One 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@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org