After sending 133,000 messages over the course of last 2 weeks where we VERP our Return-Path: and Reply-To: while keeping our From: static, this is what I'm noticing:
* Some external mail servers successfully take our messages and some time later (up to 5 days), sends an email to the Return-Path: address saying that the messages bounced for some reason. We have a matcher that catches that VERP address and sends it to our "bounce handler" mailet. The VERP prefix for our Return-Path: address is different that that of the Reply-To: so bounces are differentiated from replies. * Some external mail servers immediately tells James' RemoteDelivery mailet that the message is not deliverable (lets call it "FAST FAIL" for this discussion). James then sends a message to our Reply-To: address notifying us of that. I think this is a bug, because James should really send that notification to our Return-Path: address. Because the VERP prefix for Reply-To: is different than Return-Path:, we catch this with a different "reply handler" mailet. In our initial (naive) implementation, some of our mailing are configured with an auto-responder when a reply is encountered, and this James behavior got us into REALLY BAD loops. We auto-replied to James' bounce notification with the original intended recipient, which caused the external server to FAST FAIL, which caused James to send bounce message to the Reply-To: address, which caused us to auto-reply to the intended recipient, and so on. Yuck. I fixed this by checking the sender of the the Mail object for null - it turns out that if James had sent the reply, then the sender is null. If an external entity had sent the reply, then the sender is some valid address. Once I detect a null, I handle that mail with the bounce handler. * External vacation repliers and auto-responders send their reponses to either the Return-Path: (bounce) address or the Reply-To: (reply) address. It seems like there's no convention that anyone adheres to. * We're getting a smidgen (around 10) of replies from challenge-response systems. They all seem to be going to the Reply-To: address. That's a bummer since I was hoping that keeping the From: header constant from mailing to mailing will let us respond once to such systems and that'll let us through for the future.
Hope this helps. We're running James-2.2.0a15 on Redhat Linux 8 with Sun's 1.4.2_01-b06 configured with 128MB for the JVM; the machine is a dual-CPU P3 at 1GHz.
Quick note on performance:
* We can queue to James at about 37,000 messages per hour (622/min). This is with full token expansion of content customized for each recipient (using Velocity), URL tracking, etc. * With normal email addresses going to diverse domains and hopping all over the net, James delivers them at around 8000 per hour (133/min). These messages average 13.4 KB in size. The rate was 7000 per hour until I configured the inbound spool queue to use local file instead of DB.
* With test emails - all of which are valid, belonging to one domain, and hopping across the net - James delivers them at about 15,000 per hour (250/min). I suspect that most of the performance difference is from not having to repeatedly resolve domains.
-- Bosco
Is it possible to differentiate between bounces and replies for a mail
using matchers or mailets? I noticed that bounces are sent to the from
address instead of the reply-to address, but not really knowing this is
just a coincidence or according the specs. I read that inside a mail, there is yet another address, the envelope
address, and that address is used to send the bounce to... Now, what if
I just specify another from and reply-to address for mails send with
James? Do the bounces go to the from or reply-to, or will they go to
the envelope addres I can't see? What happens with read-notification
mails, because I also need to be able to trigger those using a mailet...
This is fairly important for me since I am integrating with James to
provide robust reporting for an electronic mailing system. And my
customer rather wants to see his email address in the from and reply,
instead of some fishy address referring to the mail server of the
mailing system.
