On Sun, 02 Nov 1997 23:13:22 -0600 gkerley@execpc.com wrote:
>
> >From the subscriber's standpoint, non-expiring confirmation messages (or
> messages expiring in 30 days) would be easier to deal with. From the
> mail bomb victim's standpoint, it shouldn't make any difference, since
> s/he wouldn't get any mail until/unless s/he confirmed. Does it make a
> difference from the list manager's perspective?
My list confirmation for SmartList saves a "cookie" for each
subscription request. The number of cookies (unused cookies) saved
onsite is configurable. They expire so that the disk spaced used
doesn't grow without bounds. I generally set my limits so that about
2 weeks are allowed. This is generally a configurable option for all
list software that I know of (for those that save cookies onsite).
> BTW, and forgive my ignorance, given that confirmation commands follow
> pretty standard formats (and can be obtained by anyone just be
> requesting to be subscribed), couldn't the creep who is subscribing a
> victim to unwanted lists just send confirm commands to the list-managers
> in the victim's name 24 hours after requesting the subscriptions?
Because the confirmation request includes a unique code. The creep
would have to guess the right code. I use a combination of date (to
the second) and process ID.
> If
> not (meaning that the confirm command can come only from the new
> subscriber's address), why can't a list manager only accept subscription
> requests that originate from the same address that the subscription is
> to be sent to?
Because the message headers can and are easily forged.
--
Michelle Dick artemis@rahul.net East Palo Alto, CA
References:
|
|
