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 ----- Original Message ----- From: "Serge Knystautas" <[EMAIL PROTECTED]> To: "James Users List" <[EMAIL PROTECTED]> Sent: Tuesday, January 21, 2003 3:24 PM Subject: Re: Reply-To and out-of-office messages > Serge Sozonoff wrote: > > Hi, > > > > > >>Anyway, if you want to be tracking bounces, you really should look into > >>VERP. James doesn't have an out-of-the-box ability to do this for you, > >>but you can write a mailet to track VERP bounces. > > > > > > Which is something I have been looking into, but I am dreading the thought > > of having to parse all of the different flavors of bounce messages that > > exist. > > Using VERP you can easily identify who you sent the original message to > > which bounced, but it does not tell you why it bounced and it does not tell > > you if the bounce is temporary, permanent, auto-reply, etc.... > > > > I have been looking around to see if someone has already done the bounce > > parser. So far I have not had much luck. > > This http://www.boogietools.com/products/productBoogieBounce.asp could have > > been nice but its a win32 dll and costs :-( > > Well, you could save yourself by effort by basing some of this just by > who sent the bounce. If your mail server could not deliver, that's > probably temporary. If the bounce comes from the postmaster (meaning it > is a <> sender), then it is probably permanent. If the bounce comes > from the recipient's email address (or actually anything else), it's > probably a vacation notice. No sense trying to (natural-language) parse > the message if you can make significant progress. > > Anyway, this is great discussion to help sort out how a built-in VERP > component within James could work. I think tracking responses from the > bulk-mailings could be one of the best features of James as its a nice > stepping stone to mail-based applications. > > -- > Serge Knystautas > Loki Technologies > http://www.lokitech.com > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
