Spam/3rd Party Relay

Joseph S. D. Yao
Wed, 24 Jun 1998 14:11:18 -0400 (EDT)

> A fix is available for SMTP that shuts off the 3rd party relay function
> preventing spam operators from using your site as a relay dump.  Mail hubs using
> SMTP are commonly behind the firewall and the spam operator hits the fw mail 
> proxy first.  Some current and older commercial FW products don't disable 3PR and spamming is possible off those sites. Which firewalls do block spamming?   I tested a small number of FW and found they are not anti-span. Am I correct to assume that commercial  FW vendors are upgrading their products to disable 3PR ?  Are there some relatively straightforward mods to  to disable 3PR in older FWs?
> Regards Hal

A fellow DC-SAGEr.  Hey, Hal.

One serious problem with protecting against 3PR is defining what it is.
Sure, if you have one interface defined as "inside" and a second as
"outside", which is the most common case, you can say that outside ->
outside is verboten, and all else is permitted.  Oops, sendmail has no
idea from which interface it got its mail.  Smap has some ...

But what if you have N interfaces, one or more of which is some kind of
"outside", and the rest are different kinds of "inside"?  With multiple
firewalls between the outsides and insides?  With many different
domains in each?  It's possible.

Most attempts I've seen have used domains to decide who is "internal"
and who is not.  But a single domain can be on both sides of firewalls.
And there can be multiple domains inside an "intranet" or "extranet",
requiring mods at all firewalls whenever the internal configuration is
modified - a pain, believe me!  Especially when each firewall is
controlled by its own different company / agency / organization.

I've taken Hagan's, Eckhardt's, and Ellis's patches to TIS FWTK 'smap'
2.1, documented and cleaned them up, and put them at:
The result of applying this patch to TIS FWTK 2.1 "smap.c" can be
compiled and run with all versions of FWTK - except that a failure
running it in daemon mode has been reported.

I intend to further modify this to reduce some of the options in this
that are redundant, and to perhaps to enable rules to be defined in
terms of interfaces instead of domains.  This removes the need to
re-configure firewalls when adding new internal groups.


Joe Yao - Joseph S. D. Yao
COSPO Computer Support						EMT-A/B
This message is not an official statement of COSPO policies.