Relay thru sys in whitelist

Vernon Schryver vjs@calcite.rhyolite.com
Sat Jun 29 06:40:57 UTC 2002


> From: "Rose, Bobby" <brose@med.wayne.edu>

> DomainC is a subdomain of DomainB.  In my case, DomainC is med.wayne.edu
> and DomainB is wayne.edu.   ...

> Because of these, if the external system from domainA (spammer) sends
> the message to the campus address, DCC doesn't rejected it when
> wayne.edu forwards.

Why not?  If all of your externally visible systems filter, then
doesn't the problem go away?  (I assume the familiar big organization
reasons apply, so that's a rhetorical question.)


>                      DCC seems to only look at the host that connected
> to hand off the message.  I would think that you'd want to look at the
> originating system when checking to see if it's in the whitelist. 

Since the DCC involves computing fuzzy checksums of SMTP message bodies
and exact checksums of selected SMTP envelope and header values and
then asking first a local white/blacklist followed by a distributed
database about those checksums, what would it mean for a DCC client
to "look at the originating system"?   Which header line consists of
(as opposed to sometimes contains) the originating system?

It is impossible in general to look at the originating system, because
the only evidence of the originating system is among the SMTP headers
added by the SMTP client, and any and all of those SMTP headers could
have been forged by the SMTP client.  You may be confident that no
one inside wayne.edu would forge any Received headers (although given
the history of universities that sounds like a strong stateent), but
that doesn't do much for a general purpose tool.

There are other, smaller problems with determining the origin of an
SMTP message, such as the lack in the real world of a standard for
Received headers.  Maybe all of the wayne.edu SMTP servers follow
RFC 822 to the letter about Received headers, but that's also not much
help for a general tool that doesn't do regular expressions.


> I understand that it's all about the message body, but whitelists are
> primarily ip addresses not the message hash and Froms and Tos are easily
> forged 

I think that in practice, spammers today only rarely forge envelope
and header From values, and when they do, they usually use entirely
bogus values.  I theorize that is because in many jurisdictions it
is now a crime to play such games.

Using IP addresses for white lists has serious problems, not least
because the relevant IP addresses are often not available.  Forwarding
of any sort causes havoc for white-listing by IP address.  The problem
you noted can be seen as a problem with using IP addresses for white
listing.  I don't mean to say that you should never white-list IP
addresses, but that doing so invites the problems you've noted.

To solve your problem, would it work to white-list *.wayne.edu only
in your sendmail access database and then use `misc/hackmc -O` or
equivalent to tell dccm to honor the sendmail white-listing?


>        (Webshots is a prime example of that where they send their bulk
> mail out using the TO address as the FROM address.)
> ...

I don't see any examples of that sort of forgery in samples of
http://groups.google.com/groups?as_q=Webshots&as_ugroup=news.admin.net-abuse.sightings
but I take your word that they do that.

I blacklist many free providers, and so filter all of that stock
dump-and-dump spam, but I also understand that such filters are not
usable at outfits bigger than vanity domains.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.