Yup, I missed that too. Good thing you reminded me. I really don't want to replicate code and/or write a delivery agent - it's sufficient for me to catch bounces. But your mention of thread-spawning leads to issues regarding long-running mailets which I'll bring up under a new subject.You're right, I missed the "james-is-your-agent" model; instead, I was
thinking of the JavaMail model where I get a status code upon each send.
You may have also missed the fact that messages inserted into the spool go through the pipeline, and can still be processed by other mailets.
If your mailet needs to be a delivery agent, you can always replicate everything done for you by RemoteDelivery. You'd spawn your own threads so that you're not consuming those available for spool processing, do your own retry queue, etc.
For each recipient. I am writing a CRM-like list mailer that needs to track what happens to each email sent to a member (in addition to click-thrus of URLs in the message body, explicit administrator initiated retries, etc). With the JavaMail model, I can get the status and immediately note it in the database. With the spooling model, I'll VERP each piece of outbound mail, check for bounces, and assume "no news is good news" for the rest.I was hoping for some sort of direct notification mechanism
(Observer pattern?) where my code can know the status of each
outbound piece of email.
For each SMTP transaction? For each recipient?
-- Bosco
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
