How to whitelist well-managed mailing lists

Vernon Schryver
Tue May 28 22:03:52 UTC 2002

> From: Gary Mills <mills@cc.UManitoba.CA>

> > However, those problems don't matter.  You don't need an unforgeable
> > mark, because forgery is so widely viewed as unacceptable and often
> > a crime.  Forgery would bypass almost all current or conceivable spam
> > defenses, but essentially no spammers are doing it.
> I assume that you mean that spammers have not been forging complete
> messages so that they appear to have come from well-known mailing
> lists.  I certainly haven't seen this.  Spammers do forge return
> addresses, of course. 

They very rarely forge valid return addresses on spam.

>                        Klez sometimes even uses mailing list addresses
> as the forged return address.

Klez is not a spammer.  The only fix for such as Klez involves ending
Mr. Gates's virus replication and distribution system.  However, I've
no hope of that happening any time soon.

> ...
> This, also, is encouraging.  In the anti-spam world, there are very
> few solutions that are both effective and discriminate well between
> spam and legitimate e-mail.  Open relay blocking is one of these,...

Some people like John Gilmore seem to disagree with you and me about
that...well, I don't use an open relay blocking list, and don't miss
it.  It is impossible to honestly see unsolicited open relay testing
such as done by ORBS and ORDB (but not the RSS) as anything but a
particularly abusive variety of unsolicited bulk mail.  Relay tests
are all substantially identical.  When they have not been solicited,
they are therefore unavoidably "spam."  Done competently, relay testing
involves at least a dozen messages, several of which will land in
postmaster mailboxes on many systems where they should be read by people.

> ...
> I'm not proposing to do this all myself.

Someone will have to accept primary responsibility for getting it
started and working.  Things assigned to "The Community,"
"The Committee," or even "us" never get done.

>                                           I'm thinking of a shared
> distributed database, modeled on the DCC checksum database, or the
> DNS-based mail relay blacklists.

I trust that's not making the common mistake of confounding distributed
network protocols with cooperative efforts.  I see no room for an
automated system like the DCC in a cooperative white list.  Every
entry in any useful white or blacklist of mail sources must be associated
with a responsible person.  To have responsible people for entries,
you cannot have more than a few people involved.  By the time you have
more than several dozen people with the authority to change such a
list, you have something like an automobile driver's license, Microsoft
system administration or programming certificates, and those Cisco
certificates of network expertise.  None of those offer any guarantee
of competence or even good intentions that anyone sane cares about.

Besides, every entry such a list must have sufficient supporting
documentation so that any user of the list can determine whether to
override any given entry, and that sort of thing doesn't fit well with
automated things like the DCC that want to deal with 1,000,000s 
or at least 100,000s of new entries per day.

A model like that used by MAPS or SPEWS is needed, where the list is
distributed by the computers from an authoritative source.  The
supporting documentation for a bulk mail whitelist might be distributed
with the list itself, because the list might be smaller than SPEWS or
the RSS.

>                                   The fact that it would be a whitelist,
> rather than a blacklist, would appeal to many people.  DCC comes with
> a sample whitelist, which is really just a sample.  Maintaining this
> is a major problem.

If you ask me, it is not maintained.

>                      It would be so much nicer if DCC could use a
> shared whitelist of major mailing lists.  There are many issues to
> be considered, and obstacles to overcome, of course.  What I'm looking
> for now are just suggestions on how to make this whole thing work,
> work with the efficiency that is needed for real-time spam blocking.

A first effort could be done with DNS and rules that differ
only slightly from the current DNS blacklist rules.  Dccm honors
sendmail white as well as blacklisting, so no new code is needed at
least at first.

Note that I don't see a need for real time distribution of such a list.
Legitimate bulk mail sources change, but not so freuquently that you
must issue a white list with hourly updates.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.