Some comments on VERP and bounce handling... My comments mainly reflect our experiences with MLMs
The "return-path" field is not always honoured by mail servers. The worst case is vaction handlers run on a mail client (outlook etc) as these *appear* to the mail server to be from the user the mail was sent to! Therefore these clients DO NOT reply to the "return-path" field but to the "reply-to" (or "from") field instead, but your mileage may vary ;) Some other things to note: Vacaction handlers SHOULD only respond to mails that are sent to the TO and CC addresses (MLM's don't do this) and only respond once to each email address per vacation session, and ignore PRECENDCE BULK. It's a world of pain. We use some upstream code (not in James) to detect reflections of mails in order to stop mail loops of this kind. For users we form VERP addresses like this: return-msgid-hash-user=host.com@maildomain The combination of the msgid and the hash makes sure we can catch the correct msgid (this is important for MLMs). For example: [EMAIL PROTECTED] Hope this helps. Other than that I think you're doing things the right way! -- Jason > -----Original Message----- > From: Serge Sozonoff [mailto:[EMAIL PROTECTED]] > Sent: 22 January 2003 18:23 > To: James Developers List > Subject: Re: Reply-To and out-of-office messages > > > Hi Serge, > > I am moving this discussion to the developer list. > > I have started writing some code for making a BounceHandler > mailet. (slightly more complex than what you described below) > > I am trying to make a mini framework thats easily extensible > and funnily its starting to look a lot like the > matcher/mailet architecture. > > The idea goes as follows: > > Matcher wise, it would be nice to use VERP here so maybe we > have a regexp matcher which matches mail to > bounce=(.*?)@domain.com and forwards this on to the mailet > through the mailet context. > > Mailet wise, there is a general BounceHandler mailet which > "runs" through a lifecycle (match -> parse -> process). > > BounceHandler calls an instance of a BounceFormatHandler > (BFH) whos job it is to match and parse a bounce message > against a specific bounce format for example an rfc1891 DSN > or a Qmail generated bounce or some other format. A > BounceFormatHandler has a match() and parse() method called > by the BounceHandler. > > match() is responsible for trying to decide if the bounce can > be parsed by this BFH and parse() is responsible for > extracing bits of information out of the bounce message like > original recipient, bounce type and creating an instace of a > Bounce object to store this information. A config block would > be used to manage the pipeline of BounceFormatHandler's and > they are run in the order listed. To add another BFH you > simply implement the interface and add the new implementation > to the pipeline. > > Upon a succesful parse, BounceHandler calls the process() > method of an instance of a BounceProcessor passing it an > instance of the Bounce class (Bounce can contain info like > BounceType, Original Recipient etc ....). A BounceProcessor > does whatever needs to be done with this bounce information, > this could be updating a database or anything else. > > Using this approach it would be possible over time to build > up a bunch of BFH's for all the email servers which bounce > non DSN formats and it should be relatively easy for others > to contribute these. > > I know that there are a lot of similarities with the > matcher/mailet architecture but I don't see myself > implementing this as a bunch or matchers and mailets. Maybe I > am wrong here, I would love some feedback, ideas, other > aproaches. Am I on the right track here ? > > Thanks, > Sergei > <snip'd> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
