>>>>> "DL" == Dan Liston <dliston@netscape.com> writes:
DL> The hardest part of parsing the information is trying to determine the
DL> differences between fatal and non-fatal bounces.
I agree, but this is a job that we know is basically impossible so all we
can do is try. This is, essentially, the reason we keep statistics and why
we have a sequence number in every envelope. Only in rare cases
(infrequently used announcement lists, probably) would you want to nuke a
user on the first bounce. And if you get more than one bounce for a single
message, you don't treat them as multiples so repeated warnings don't
overly skew your statistics.
DL> I see that in mj2, you have a vacation style hold delivery option that
DL> mj1 does not support.
Yes. You can switch to nomail status and set an expiration time after
which you will revert to your old status. But this is the delivery class
and is unrelated to bounce processing.
DL> Even temporary bounces could automatically be put on hold, where
DL> permanent (fatal) bounces are moved to the bounces list.
I don't really agree. The more data we collect the better, and we need to
keep delivering messages in case the bounce was transient (so the user
doesn't needlessly miss messages) and so we don't have to implement an
entirely separate vetting mechanism.
Note that we don't rely entirely on bounce parsing; we also have in place a
system where some configurable percentage of the list is sent a VERP each
message. Once an address bounces, it is VERPed until it has stopped
bouncing. (We still parse the bounces to get diagnostics and to discern
the status.)
DL> Is there a way to clean out the subscribers that have put themselves on
DL> indefinate hold?
Not simply. You can do lots of things with the shell interface,
who-enhanced and grep.
DL> Or is that also the method for post but don't receive mechanisms?
It is one of them. A domain owner may choose to implement some other
mechanism (a single posting list, for example).
- J<
References:
|
|
