Relay thru sys in whitelist

Rose, Bobby brose@med.wayne.edu
Sat Jun 29 23:12:13 UTC 2002


Campus doesn't do much at all when it comes to filtering, they also can
enforce quotas which is something we can't do to the differences in
nature of our user-bases.  They only recently started scanning for
viruses at their smtp gateway.

Yeh I suppose the received headers could be forged but it would have to
be forged by the SMTP system accepting the message wouldn't it?  If so,
it would be easy to pick out after awhile and such a system could be
blacklisted altogether.  Such a system more than likely wouldn't end up
in a whitelist since you would only whitelist internal systems.
Sendmail must be looking at something because I have some Rejects in my
access map and I've seen rejections in the logs from such systems even
though the message bounced off campus.  Now I didn't know about the dccm
being able to hash out the sendmail access list but I'm not certain that
will do much.  If *.wayne.edu is whitelisted in the dccm list, what
would be the change if it was whitelisted in the access map instead?

-----Original Message-----
From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] 
Sent: Saturday, June 29, 2002 2:41 AM
To: dcc@calcite.rhyolite.com
Subject: RE: Relay thru sys in whitelist


> 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-a
buse.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
_______________________________________________
DCC mailing list
DCC@rhyolite.com
http://www.rhyolite.com/mailman/listinfo/dcc




More information about the DCC mailing list

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