Re: Reply-To and out-of-office messages

[Serge Sozonoff <se...@globalbeach.com>]

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" <se...@lokitech.com>
To: "James Users List" <ja...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Reply-To and out-of-office messages

[Jason Webb <jw...@inovem.com>]

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:
return-12311-dg4523234-serge=globalbeach.com@maildomain.com

Hope this helps.

Other than that I think you're doing things the right way!


-- Jason



> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com] 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>