james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Thu, 17 May 2007 13:16:28 GMT
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

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

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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message