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?
_________________________________________________
tmda-workers mailing list ([email protected])
http://tmda.net/lists/listinfo/tmda-workers
