not to be pessimistic (i can't help myself :o), but the other problem i think you are going to run into is multiple [James] MXs servicing a single site. unless they all share a common database the 'state' information may not be available upon receipt of a bounce.

the problem with a common database is that it introduces a single point of failure and that is what multi-MX installations are often trying to avoid. 'failover' is an option, but that is an even more difficult nut to crack.

the other option that i can think of is distributed state management (local DBs, remote synchronization): very cool but it has a whole set of problems unto itself.

b

My basic problem is that we assumed anything that is sent back to the From:
address is a bounce. This assumption has been proven incorrect, at least by
some of the out-of-office messages that I get back on my mail server. Right
now I'm trying to work around this by writing a matcher that performs
matches on the content of the mail, using a set of regular expressions. This
could be quite expensive in terms of processing time, so all suggestions for
a simple mechanism to identify out-of-office messages are welcome.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to