On Thu, 18 Nov 1999, Ronald F. Guilmette wrote:
> As one possible solution to this problem, the idea of building and main-
> taining a registry of ``legitimate opt-in'' mailing lists does in fact
> have some merit, but as noted above, it also has some problems.
> I think that the scaling problems could in fact be solved, but that would
> take some serious work. As regards to the building and maintaining of the
> registry, I myself would be happy to build and maintain exactly such a
> registry, and to make it available (as a service) to all Internet sites,
> but the main reason why neither I nor anyone else has ever tried to create
> such a registry is because of the likelihood that list owners simply would
> not cooperate in sufficient numbers to make the whole thing work.
The 'meta-list' group that got mentioned on here some while back has
created such a registry; take a look at www.meta-list.com. Admittedly,
it's geared more towards end-users finding a list, but my point is that
there are other methods of discovering mailing list information... I don't
happen to -agree- with the mass harvesting they did, but all they did was
probe at specific addresses (majordomo@<site>, listserv@<site>,
listar@<site>), sending the appropriate command for the listserver type
they were probing to get a list of lists on that site, which was then
As for a registry of mailing lists of the type you describe, I think that
some very serious thought would need to be made on HOW it would be
implemented. I keep thinking that the -best- method would never be
accepted, because it would require cooperation between listserver authors
such as myself, the registry authors/maintainers, and the MTA authors...
but this method would be that each list would be assigned a unique
identifier, almost like a PGP fingerprint.
The posts from the list would be required to contain this fingerprint on
something like X-MLReg-Auth: in the RFC822 headers, as well as the
X-List-Id: header described in the proposed changes to RFC2369.
Then an MTA such as AOL could query the listserver registry (using the
X-List-Id) and see if the auth code matched. Now, I know that the problem
is that spammers would become creative and do a query to get the auth
code, so it would have to be one-way encryption of some kind; perhaps the
'Auth' string is a PGP-encoded passphrase and the mailing list registry
has the public key and the decoded phrase? At any rate, once the MTA had
verified it, it would be required to remove the authentication header from
the RFC822 headers (to obscure it from the end-user, and thus prevent
spammers from just grabbing the information).
Then, of course, the receiving MTA would want to cache all its query
results to avoid having to do massive numbers of lookups...
Also, some of this - like the auth code - might be better implemented
somewhere other than the RFC822 headers. But as a listserver author, I
tend to think in terms of not having control over anything at a higher
level than those, since even if a server I send to has a capability (like
DSN), a server it relays to might not. The only way to ensure information
remains intact from start to finish is in the headers...
But, as I said, the concept of trying to get listserver authors and MTA
authors BOTH to implement this strikes me as something that isn't going to
happen. Few enough MUA and listserver authors have bothered to implement
RFC2369, which is trivial. I suspect something of this complexity would
be completely ignored.
Jeremy Blackman - email@example.com / firstname.lastname@example.org / email@example.com
Lithtech Team, Monolith Productions -- http://www.lith.com
Listar Developer -- http://www.listar.org