I'm spooling VERPed emails to a James server for remote delivery. I want to record in a database table the ultimate status of each delivery (after all retries).
What's the best way to do this? A blind approach is to extend the RemoteDelivery mailet to record successes and failures and replace all references to RemoteDelivery with my new mailet. Is there an easier way?
I'm using James 2.2.0a15 on Redhat Linux 8 & 9 with Sun's 1.4.2_01 java.
You don't need to touch RemoteDelivery. Modifying RemoteDelivery would only help you catch deliveries that failed fast, and not messages that get processed remotely and bounced back (two alternate ways a remote server could do the same thing).
Setup a matcher that looks for your address pattern, and then fire whatever mailet you want when that VERP address arrives.
There is a mime type that defines how/why a message bounces, and I was surprised that a large number (> 60%) of the bounces I get include this information. I don't know whether anyone has had time to, but there was talk of having RemoteDelivery create this mime type as part of bounces, and then code to help you read this. Unfortunately I forget the RFC off hand.
But for my purpose, I just records bounces as yes/no. It's not as intelligent as I would like, but it works for now.
I've already deployed a bounce handler mailet to catch messages sent to the Return-Path (whose value is different from the From: and Reply-To: headers). The assumption is that any messages sent to the address specified in the Return-Path is a bounce (see PS below). I hope that's an OK assumption. I also have a different mailet to handle the messages sent to Reply-To: (which is VERPed with a different prefix).
The problem is, my Management is stuck on the Lyris model (which micro-manages the delivery of messages down to the SMTP conversation level) and they
1. Want to know the exact time that an email was successfully
delivered (which is usually much different than when it was
spooled because of the volume of mail we handle)
2. Do NOT like the idea that the number of successfully delivered
messages is NUM_SPOOLED - NUM_BOUNCED and that they won't know
that exact count until after NUM_RETRIES * RETRY_INTERVAL (5 * 6
hours). They want a record in a table that says a message was
delivered (even though I warned them that such a message may be
bounced by an external server two days later).Management REALLY wants to know the fast successes and failures and I'm on the hook (pun intended) to implement it. So that comes back to my original request for advice on hooking or extending RemoteDelivery.
-- Bosco
PS: Don't know if this is a bug or not, but James seems to be sending some fast fail bounces to the address specified in my Reply-To: header instead of the Return-Path: header. I'll detail this in another message to keep the topics separate.
PPS: Regarding categorizing bounces, I'm not doing that right now (mainly due to lack of time). But I'm keeping my eyes peeled for RegEx that'll help categorize bounces into some main categories. There is enough fodder here for a huge lively discussion.
