>>>>> "AM" == Andrew McNamara <andrewm@connect.com.au> writes:
AM> The scenario I'm thinking of is a badguy repeatedly forging subscribes
AM> from the victim, knowing the victim will be bombed by the third-party
AM> majordomo.
Well, this is the kind of thing that time-based limiting is supposed to
take care of. Unfortunately we still haven't found a workable scheme for
doing this. If anyone has any ideas on how to code up a way to limit the
frequency of actions that an address can carry out within a certain period
of time that doesn't keep too much state, I'm happy to hear/read them.
AM> I envisaged the victim sending back a "refuse-all" message, including
AM> the token (which avoids the D.O.S that Brock Rozen mentioned).
I hadn't thought of that. Yes, if you can return even a single token then
you've authenticated yourself as being at that address and thus are
authorized to shut off tokens for a while.
AM> The problem with this idea is that it needs the global database that
AM> appears so hard to implement
It's not really too hard; look at TODO in the latest snapshot or CVS. In
the end it doesn't look terribly difficult, although we'll go through a
period of instability and everyone will have to dump their lists. I'm
going to get the RBL stuff, lockfile expiration and some minor changes in,
cut another snapshot, and then dive into that the master database.
AM> BTW, if they just ignore the token, they'll get reminder e-mail...
That and nobody will ever know. If they reject it then they, the list
owner and the site owner get the full headers of the offending, forged
request; otherwise that data is saved for another week (configurable, of
course) until it expires.
- J<
Follow-Ups:
References:
|
|
