On 10/28/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote: > On 10/24/06, Danny Angus <[EMAIL PROTECTED]> wrote: >> On 10/22/06, robert burrell donkin <[EMAIL PROTECTED]> 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. > > - robertIn 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
