On 11/30/01 10:08 PM, "Dale Newfield" <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Nov 2001, Barry A. Warsaw wrote: >> - For simplicity, let's treat non-fatal bounces (some temporary >> outage) the same as fatal bounces (user goes away) > > Your scheme makes sense What you might consider is this: If the bounce is RFC compliant, it's fairly simple to determine "hard" and "soft" bounces, and since they are following the standards, it's not a huge amount of work. Treat a "soft" bounce as half a bounce. That gives the soft bounce twice as long to actually come into effect. If the bounce is one of the many non-RFC compliant mail systems, treat everything as hard bounces. You don't spend the work trying to read their non-compliant tea leaves, and they have some quiet encouragement to get their act together and become RFC compliant. > I like the idea that subscribers can wind up "on > probation" (assuming the list admin configures the list that way). I > understand that this simplifying assumption makes the design much easier > to think through. It'd be really nice if bounce-nomail and user-nomail are separate modes, so we can tell the difference. Beyond that, what would be optimum for me is if bounces went to nomail mode, and then if they're still nomail 30 days later, deleted from the system. That gives a user a chance to "come back" without losing their subscription state, but not hang around forever.... At some point, it'd be nice to be able to validate those other nomail addresses, similar to the monthly password reminder (or part of it). Something that says "you have this account sent to this mode. If you want this, click 'here'. If you don't, do nothing and we'll delete it. Where 'click here' takes you to a link that sets the "I'm okay" counter on that nomail status for another 90 days or something... _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
