Q. Can TCPware be configured to disable unauthorized mail relaying and SPAM, and how can I tell if my system allows unauthorized mail relaying?

A. Yes. You can configure the TCPWARE:SMTP_SERVER_REJECT. file to accomplish this. The following is an example SMTP_SERVER_REJECT. file that can be used as a starting point to create your own reject file. In the example, only mail that is from the 10.0.0, the 10.115.140, or the 10.115.141 subnets with a from address ending in flowers.com will be relayed. You can test to see if your system allows relaying of unauthorized messages by telneting to MAIL-ABUSE.ORG from the machine you are testing.


!
! This is a sample reject file for the company FLOWERS.COM.
!
! This file is processed sequentially. In other words, processing ends
! on the first rule that the message applies to. So if you have a
! wildcard accept at the top of this file, then no other rules will be
! processed.
!
! Entries can have one of the following formats:
!
!       from_user [from_ip to_user action action-data]
!
!       :rfc822 header
!
! Wildcards can be used in FROM_USER, FROM_IP, and TO_USER. ACTION is
! the reject action, which is one of:
!
!       n       Don't reject, but rewrite TO address to be ACTION-DATA.
!               If ACTION-DATA is blank then we simply deliver to
!		TO_USER.
!
!       y       Reject and use optional ACTION-FIELD as a rejection
!		message format that can contain up to three %s
!		formatting designators for mail from, mail to, and
!		local domainname.
!
!       q       Reject quietly -- don't inform Sending SMTP Client that
!               message will be discarded. If only FROM_USER is specified 
!		other fields default to FROM_IP=*, TO_USER=*, and ACTION=n.
!
! Don't rewrite or reject any mail to "postmaster*"
!
*       *       postmaster*     n
!
!
! Accept all messages with MAIL FROM:<> (bounce messages)
! This rule is commented out because you probably don't want it,
! although we're _supposed_ to always accept it.  This is the main
! method relay attacks use, by always saying they are from <> to take
! advantage of that RFC hole.
!
! <>          *            *         n
!
! Reject anything with a Message-ID that appears to have originated from
! cyberpromo.com or nowhere.com
!
:Message-ID: <*@cyberpromo.com>
:Message-ID: <*@nowhere.com>
!
! Reject mail from well-known SPAM sites with sample non-standard error
! messages.
!
<*answerme.com>    *  *  y  "Spam from <%s> rejected"
<*cyberpromo.com>  *  *  y  "Spam from <%s> to <%s> rejected"
<*pleaseread.com>  *  *  y  "Spam rejected;%.0s%.0s Contact postmaster@%s"
!
!  Disallow percent-hacks (e.g, joe%somewhere.com@flowers.com)
!
*       *       *@*@*flowers.com        y       "No forwarding-path relaying allowed"
!
!  Disallow "!" UUCP hacks (e.g. somewhere.com!joe@flowers.com)
!
*       *       *!*                     y       "No UUCP relaying allowed"
!
!  Rewrite all mail to webmaster to the postmaster.
!
*       *       webmaster@*flowers.com  n       postmaster@flowers.com
!
!
! Disallow relaying through our mailer, and only allow users on our
! networks to claim to be from our company (flowers.com)
!
*               *       *@flowers.com   n
*               *       *@daisy.flowers.com     n
*               *       *@[10.0.0.1]    n
!
<*flowers.com>  10.0.0.*        *       n
<*flowers.com>  10.115.140.*    *       n
<*flowers.com>  10.115.141.*    *       n
!
! Allow our internal systems to bounce mail out.
!