Danny Angus ha scritto: > I think I liked the idea that we could create the stream by taking > streams to each part and sucessively attaching them to the output > stream. I don't see any benefit from keeping the raw input once we've > managed to get it into the repository. > > I can see no case where having the raw stream or the raw bytes gives > us a tangible benefit, apart from one where we choose not to use any > of JAMES's functionality beyond SMTP in and remote delivery. How > likely is this? > > d.
My JAMES Server deployment with bigger throughput does never parse mimemessages. I don't use any mailet using properties from the MimeMessage object, and SMTP+POP3+RemoteDelivery simply works without parsing. Maybe I could not deliver 1 million mails per day if I had mime parsing somewhere... Apart my specific usecase (that I think is not so uncommon) I think we should at least support smtp relaying in an RFC compliant way. I linked a lot of paragraphs with "MUST NOT" about parsing the content in a previous message... Once you decide to alter the message using a mailet it is perfectly ok to save a structured version, as the message will not be like the original anymore and it does not make sense to keep the "original". As I suggested in another email I think the best solution is to have support of both type of objects in the repository and leave to the application the duty to convert from raw to parsed and back if needed. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
