>
> > >
> > > "Accidental" removals from the lists are so common that I give up. I no
> > > longer even try to get back on them -- it's been happening for _years_ now,
> > > and I have made multiple complaints about it, and if it's not a problem for
> > > whoever runs the mailing lists, then I just don't care that much.
> >
> > only one comment. i remove people from the lists whenever
> > their email bounces. the threshhold is approximately 30 messages in a
> > 24 hour period. mail may bounce due to DNS problems, mail box full,
> > MTA misconfiguration. i also remove people that send vacation
> > messages to the list. oh, and spammers.
>
> Perhaps these threshholds could use some minor adjustments, or perhaps
> my interpretation of the above policy is not quite what really happens.
>
> a) I don't think message count should be considered at all, as the this
> is highly dependent on the list one is on, and the current rate of
> messages going to it. As Nate pointed out 30 messages could be as
> short as 5 minutes on -hackers. And in my hay day of being on all
> lists it would have defanitly been in the 5 minute range almost any
> time of the day.
i said "approximately" because i do take into account the
number of lists subscribe and the nature of the lists. an it gives me
some wiggle room.
>
> b) The 24 hour time period is a bit on the short time, unless the messages
> are bouncing for being in the queue for at least 48 hours. Many mail
> configuration screw ups happen on a friday night, and may not get
> noticed until monday morning. Thus a 72 hour window is more reasonable
> for that type of mail problem.
a message may remain in the queue for days....these are not
bounces...these are queued emails. i dont count queued emails, but if
i can reach your mail server and it give me back a series 500, thats a
bounce. YOU, or your isp, controls this. so if our config if
f*cked, go off the air (not a bounce..at least for several days) and
fix it. dont leave a f*cked up mail server on the net while that
server gives out series 500 responses. avoid 500 series unless you
mean ;) a 500 series means "go away, and dont come back!"
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did
not occur. The sender-SMTP is discouraged from repeating
the exact request (in the same sequence). Even some
"permanent" error conditions can be corrected, so the
human user may want to direct the sender-SMTP to
reinitiate the command sequence by direct action at some
point in the future (e.g., after the spelling has been
changed, or the user has altered the account status).
>
> >
> > i do NOT send the person mail to inform them that the are
> > being removed from the mailing lists, because their email is bouncing.
>
> :-). Though I understand your reasoning, it really depends on for what
> reason they are bouncing. If it is queue time outs sending a message
> may just get to them, if they happen to get it fixed before the notice
> gets timed out and bounced. Infact that would be a really good threshold
> for removal due to mail bouncing due to queue timeout. In the case of
> immediate bounce due to mis configuration your current policy is probably
> the best policy.
>
> --
> Rod Grimes - KD7CAX - (RWG25) [EMAIL PROTECTED]
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
