(Sorry, item I am replying to was before I subscribed, so threading borked)
On 9 Mar 2003 17:52:53 +0000, "Mark Delany"
<tcrcn-6ugsc(_at_)qmda(_dot_)emu(_dot_)st> 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: list-confirm(_at_)ietf(_dot_)org
From: joe(_at_)example(_dot_)com
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
pgp7Atzm9LdCL.pgp
Description: PGP signature