Subject: [Asrg] Re: Fixing the mailing lists

From: [email-masked]
Date: Sun, 09 Mar 2003 16:46:41 -0500

(Sorry, item I am replying to was before I subscribed, so threading borked)

On 9 Mar 2003 17:52:53 +0000, "Mark Delany" <[email-masked]> said:

> But the public algorithm is merely a variant of rand()

> The MUA can generate any sort of token it wants. All it has to do is
> send the token back to the mailing list as part of the confirmation
> email *and* keep a copy in some local database.

> To: [email-masked]
> From: [email-masked]
> Confirmation-Token: 20700621ba1d4f92de29ffce0dc98b0d

This *does* have the very unfortunate side effect of requiring a separate SMTP
DATA step for each of multiple recipients at a host.  Given that my Listserv
machine *routinely* (sometimes pseudo-hourly) sends 4K-20K recipient messages
to our main mail hub,  I'd *really* like to avoid having to fork 10K delivery
processes if one would have sufficed otherwise.  

I could probably tolerate it being passed as an ESMTP parm on the RCTP TO:, or
an implementation of RFC3229 (which specifies delta encoding for HTTP) - I
think there was an I-D on this for SMTP but I can't find it at the moment.

Now, assuming we get around the efficiency problem...

We can do better - for instance, have the MUA generate a rand() *once*,
and then the actually sent token is a keyed MD5 hash or similar of the
List: address.  This way, the token is tied to the list address, and even
if a spammer trawls the token out of an archive or whatever, he can't use
it to spam from any other address....

Major drawback?  There's a vendor of who I've heard said: "Oh, it's easy
to re-install $FOOBAR-OS, I've had to do it dozens of times on my boxes".
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech