Re: Extended Expiration?

Mark Horn <[email protected]> writes:

> I'm considering making some modifications to the
> ACTION_EXPIRED_DATED.  I've been getting innundated with SPAMS using
> dated addresses that expired over two years ago.  I'm assuming that
> they've been culled from USENET.  My thought was that I would create
> two tiers of expiration: EXPIRED and ANCIENT, so that you might have:
>
> ACTION_EXPIRED_DATED = "confirm"
> ANCIENT_LIFETIME = 30d
> ACTION_ANCIENT_DATED = "bounce"
>
> What would happen is this:
>
> After a dated address expired, but before ANCIENT_LIFETIME,
> ACTION_EXPIRED_DATED would occur.  After ANCIENT_LIFETIME,
> ACTION_ANCIENT_DATED would occur.
>
> Before I do the work on this, I was wondering if anyone (other than
> me) thought that this would be a useful feature and if so, what the
> probabilities would be of getting it incorporated into the codebase.

Sounds fine to me.  Except that I'd rather see ACTION_EXPIRED_DATED
extended to support handling multiple ages of dated messages rather
than new config variables being added.  For example,

The default behavior would remain the same --

# all 'dated' messages get 'confirm' applied to it
ACTION_EXPIRED_DATED = 'confirm'

But optionally one could define multiple (age, action) pairings --

ACTION_EXPIRED_DATED = [
             ('default', 'confirm'), # default action if no others apply
	     ('1w',  'hold'), # 'hold' after one week
	     ('30d', 'bounce'), # bounce after 30 days
	     ]

Seems more clear and more flexible this way to me.  Whatcha think?