How do I set up a filter to stop relayed mail?

Question

How do I set up a filter to stop relayed mail?
Unsolicited Bulk E-mail (UBE) is electronic mail sent to large numbers
of recipients without their knowledge or consent, usually advertising commercial
products or services. It is the electronic equivalent of paper "junk
mail", and is commonly referred to as Spam.
<P>UBE is usually just a nuisance, but the volume of UBE received at a
certain site can at times become so onerous that business-critical functions
are affected. This is especially true when UBE is used maliciously
to produce a denial of service attack, where a mail server is inundated
with UBE and crashes because of the load. Another common UBE problem
is when a mail server is used as a relay for UBE, so that a particular
server spends all its time routing e-mail that isn't destined for its
users. Some ISPs have reported that their mail servers have been
hard coded into certain spam programs, so that they are constantly being
used as a relay. Not only does this slow down their mail service
locally, but sometimes other ISP's will identify the afflicted ISP as a
source of spam and begin to block messages, legitimate and spam alike,
coming from that ISP. ISP's often name UBE as their number one problem,
preventing them from providing fast, reliable service.
<P>For a full definition of UBE see http://www.imc.org/uce-def.html
(Unsolicited Bulk Email: Definitions and Problems).
<P>Messaging Server 3.5 Hosting Edition supports powerful filtering capabilities
on messages as they are received by the server. Various criteria
can be applied to incoming messages, including testing on number of recipients,
sender domain or IP address, messages being relayed, and more. Messages
can then be bounced, dropped, or reviewed by an administrator before being
delivered. Providers can filter out unwanted mail at the source or block
a third party from using their messaging server for relaying email.
<P><B>UBE Filters Functionality Overview</B>
<P>The UBE filter is a plugin for Netscape Messaging Server 3.5. It works
by examining all incoming mail before it is routed throughout the system
(to users mailboxes or to other email servers). The UBE filter uses a set
of rules (also known as filters) to decide what to do with each piece of
mail. The filters are used to trap specified types of mail.
Mail that is trapped can be rejected, forwarded to a specific mailbox (e.g.,
the postmaster), deleted, or altered in some way. Mail that "passes"
all the filters continues on its normal course.
<P>Filters can be set up two ways, either using the straight forward Graphical
User Interface (GUI) or by setting up the filters directly in the filter.cfg
file. Generally, one would use the GUI interface for simple, one
line filters. To set up more complicated, multi-part filters, editing
the <I>filter.cfg</I> file directly would be faster. Both methods
are accessed via the Messaging Server Admin tool, under Plug-ins.
The following discussion gives some high level examples of how to set up
simple filters using the GUI and via the <I>filter.cfg</I> file.
For detailed information on how to set up and configure the UBE Filter
plug-in, see chapter 5 of the online help, or http://home.netscape.com/eng/Messaging/guide35/ch5.htm#Controlling
unsolicited bulk email (UBE).
<P><B>Setting Up UBE Filters with the GUI</B>
<P>The following screen shot shows a simple UBE filter being set up using
the UBE GUI. What is being set up is a filter to check all incoming
messages to see if they come from a domain that has been a regular source
of UBE. In this case, the name of the offending domain is "spammer.com".
So, each message that comes in has its "From" field checked to see if
it is from "spammer.com". If it is, the action is REJECT, meaning
the message is bounced back to the sender, with the appended message "I
don't accept mail from spammer.com".
<P>
<BR>
<P>Any field in the message can be examined, with some of the most popular
including the Subject, To, and Cc fields. Any regular expression
can be placed into the Value field, thus allowing the filter to check for
various conditions, including containment of a particular phrase (e.g.
Subject includes "make money"), or number of recipients (e.g., if greater
than 100, REJECT). For more information on how to write regular expressions,
see http://home.netscape.com/eng/Messaging/guide35/ch5.htm#Controlling
unsolicited bulk email (UBE)
<P>There are a number of actions that can be taken on a trapped message.
The most common are forwarding to a "watchdog" account such as the postmaster,
rejection, and deletion. But, in addition, programs such as virus
checking can be run on a message to trap infected messages.
<P><B>Setting Up UBE Filters by editing the <I>filter.cfg</I> file</B>
<P>In the above example, the filter that was set up was converted to a
short filter script that looked as follows:
<P>Channel-From ".*@spammer.com" REJECT
"I don't accept mail from spammer.com"
<P>This can also be directly entered into the <I>filter.cfg</I> file by
choosing the option "Edit Config File" from the UBE Page. This becomes
interesting for more complicated filters that require more than one filter
line. The following example shows a set of filters that were set
up to check for various conditions. For example, the fifth
and sixth line down is a filter that checks messages for viruses.
<P>
<BR>
<P><B>Using the UBE Filter for Anti-Relay</B>
<BR>
<P>One of the most requested needs of the new UBE filters supported in
Messaging Server 3.5 is to provide "anti-relay", i.e., to stop UBE which
is from an outside domain and destined for another outside domain.
In these cases, the mail is usually UBE and is relaying to hide the source
of the original spammer.
<P>There are two possible scenarios for anti-relay. One is where
there is a separate machine outside the firewall that checks for e-mail
for its domain. The other scenario is when there is only one machine
handling both internal and external traffic.
<P><I>Scenario One: Separate machines used for internal and external
mail</I>
<P>Outside of the firewall are mail servers that handle all incoming mail
from the internet. Internal users connect to mail servers inside
of the fire wall. The scenario looks like this:
<BR>
<P>What we want to allow is users 1 and 2 (U1 and U2) to send mail anywhere
but X1 and X2 should only be allowed to send mail to our servers.
<P>Solution:
<P>On the External Mail Server create a filter script that checks the Channel-to
header for domains that are internal to us. Allow these through and
reject all other mail. E.g., the filters would look as follows:
<BR>
<UL># if the mail is bound for domain1 or domain2 then exit the script
(and allow the mail to continue)
<BR>Channel-To "domain1.com" EXIT
<BR>Channel-To "domain2.com" EXIT
<BR># otherwise reject it outright ($ANY means any header and .* means
it has any text)
<BR>$ANY ".*"
REJECT "This machine only accepts mail bound for domain1.com or domain2.com"</UL>
We don't need to do anything on the internal server since only our users
can get to it (because of the firewall) and we want to allow them to send
and receive any and all mail.
<BR>
<P><I>Scenario 2: Single machine used for internal and external mail</I>
<P>In this scenario the same machine is used for both internal and external
connections. The problem we face here is that we need to allow the
local users to send mail outside our domains but not allow external users
to do the same. Note: This set up is not generally recommended, since it
makes the Messaging Server open to external attacks.
<BR>
<P>Here, we want to allow U1, U2 and U3 to send anywhere and X1 and X2
to send to domain1 or domain2 only.
<P>Solution:
<P>The solution in this case is to put the same script as scenario 1 on
the server but pre-pend it with lines that check for a connection from
the internal domains. If the connection is from our users it must
be from certain IP addresses, say 128.128.128.* or 128.128.129.*, so we
look for that. If it's not from one of these two IP addresses, then
it must be from outside and we apply the same logic as in scenario 1.
<BR>
<UL>#if the connection is from our internal domains then exit the script
(and allow the mail to continue)
<BR>Host-From "128\.128\.128\." EXIT
<BR>Host-From "128\.128\.129\." EXIT
<BR># if the mail is bound for domain1 or domain2 then exit the script
(and allow the mail to continue)
<BR>Channel-To "domain1.com" EXIT
<BR>Channel-To "domain2.com" EXIT
<BR># otherwise reject it outright ($ANY means any header and .* means
has any text)
<BR>$ANY ".*" REJECT "This machine only accepts mail bound for domain1.com
or domain2.com"</UL>

Answer 1

I agree anti-relay can be using UBE feature. However, there is serious problem in reject the spam mail. My nms is using UBE feature to stop spam mail. According to the work flow of the UBE, the mail is received by nms completely and UBE is going to invesgate the mail address. Although UBE can stop the spam mail, the spam mail have a trouble in returning the mail to the sender. The reason is the sender address is usually not existed in the world. That will cause a lot of mail waiting in the mail queue.
In my experience, do not use UBE for anti-relay.