* 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.
That's definitely a bug, but I'm doing notionally the same thing with James 2.1.3 and James is using the return-path. Hmmm... I guess I'm not setting the Reply-to header, just the From, but I would hope that's not the problem.
Can you prepare some info (configuration, whatever else) and submit a bug to JIRA? Thanks.
http://nagoya.apache.org/jira/
-- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
