Maxime,
> i) I need my app to "listen" for emails arriving via smtp, and
> store them in a database table
James SMTP handler will do this correctly unless you require a different db schema
than James spool/mail repository tables.
> v) I need the guarantee that no mail loss can occur, and neither can
> duplicates
> (every email arriving from sendmail will get processed once and
> only once,
> no matter how often my James process gets restarted).
>
> It seems from your answer that I have to add this fault tolerance, for
> James does not
> have it build in.
Actually James is tolerant of failures, and *should* not experience losses.
However the price is that it can't avoid duplication of some tasks.
The processing is not atomic, therefore an oportunity for processing to terminate
abruptly with mail "between" states will *always* be present. James deals with this by
re-starting processing from the last recorded state, allowing the possibility for some
mail to pass through some processing twice.
> 1) Configure my sendmail 'source' to "retry upon failure". Lets say,
> upon failure,
> retry every 5 minutes up to 10 times.
Sendmail should do this as shipped, though not as rapidly as you may want.
> 2) Detect and ignore duplicates :
>
> myRobustMailet.service(Mail m) {
> if(isDuplicate(mail))
> return;
>
> put mail in DB;
> }
Yes.
> In my case, my mail source is a sendmail instance, and the typical
> journey for emails today is typically
> a serie of "store and forward" along a chain of relaying processes
> through SMTP, not all of them James instances (yet ;) ) !
I understand this, but was simply questing why you think you need single sendmail
instance as the sole source for messages into James.
I accept that there *are* legitimate reasons for it, but wanted to make sure you're
not going to unecessary additional effort to achieve your goal.
d.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
