>>>>> "THH" == The Hermit Hacker <email@example.com> writes:
THH> right now, it sends me a message that states that a 'user unknown' was
THH> detected ... any way of just getting it to unregister that user and
THH> save me a several hundred mail messages to wade through? :)
Not yet. The first phase is detection of actual bounces and parsing of
those that we can parse (relying on our VERP implementation for the rest).
I'm working on this steadily as I get bounces that the software doesn't
Next is statistics gathering. If you wanted to always remove a user the
first time you see a bounce from them, we can do that. But that's pretty
harsh, so we need to gather data so we can detect bounces.
Finally comes the decision making: when does an address get removed?
For statistics gathering, I'm just planning to store a list of bounced
message numbers and times in the subscriber database. If we keep info on
the past several bounces then when we can get a bounce we can say:
This is the only bounce from the user in the last N messages.
The user has bounced the past M consecutive messages.
The user has bounced M (X%) of the past N messages.
The user has bounced M messages in the past day (week, month).
You get odd effects from delayed bounces because the bounces don't happen
in step with the messages being sent but I don't envision it being a
You just have to decide when to remove stuff. There are lots of ways to do
this, but then I was thinking the other day that we already have a pretty
good method: access_rules. Just keep the same basic parser and hook it up
to a bounce_rules variable:
$days_since_subscribe < 2
$bounce_consecutive < 5
$bounce_percent > 60 || $bounce_consecutive >= 10
would remove any address that bounces at all within the first two days
after the user signed up, then keeps addresses which are bouncing which
haven't bounced five in a row, then bounces any address that has bounced
either 60% of the last N messages or the last ten messages in a row.
Not too difficult to implement, and all available straight from some simple
THH> Or ... how about for 'known bounces', create a daily summary and
THH> discarding the bounces?
That is another useful step. These should be logged, and we can use the
inform variable to designate whether the owner is notified for each
identified bounce, if they are notified in a periodic report or if they
aren't told at all.
Unfortunately, the report generation stuff has yet to be written. This
would be a great thing for someone not intimately affiliated with the
project to work on; we have a global master log and a number of message
logs per list; all are in text format and should be easy to parse. I even
have some prototype code. I've always been excited about writing this but
never had the time.