Everything on this page is based on information supplied to ORBS by server admins and MTA authors. Opinions are just that - opinions. If something is outdated, please let us know what the corrections should be. If you find fix information for software which is not listed here and which outdates information at the MAPS TSI pages, please let us know.

Other sites include Sam Spade or the MAPS project's Transport Security Initiative or UXN's spam combat page. or Consumer.net's Network-Tools page.

Please note: These testers may show a host as OK while ORBS says otherwise. This is because ORBS tests for multiple classes of vulnerabilities, while most of the online testers only check for one basic flaw - vulnerability to forged sender envelopes. The MAPS tester has been recently updated to include more checks, but still doesn't cover the full set of ORBS tests and suffers from the same fault as the abuse.net tester. Sam Spade's admin is rather hypocritical about relay tests and will complain loudly if any of the systems his site tests decide to run comprehensive relay checks on his hosts in return.

Online relay checkers can be dangerous in the hands of the ignorant, as people frequently take incorrect statements regarding a site's vulnerability to relaying made by the tools as being canonical. ORBS assumes no liability for incorrect vulnerability statements made by other organisations - it is their responsibility to rectify this problem.

Click here for sp4

One admin has asked that we emphasis this paragraph from the relay.asp article above:

"What the Microsoft article and online Help don't spell out is that when
you select a routing restriction, you can choose not to enter any IP
information. 

The trick is that you can select the Hosts and clients with these IP
addresses check box but not specify any IP addresses. Unless you have a
specific need to have your Exchange server relay, don't enter any IP
addresses on this page. 

This selection changes the rules that the IMS uses when evaluating the
SMTP protocol. Instead of letting the IMS accept the RCPT TO specification
blindly, this selection causes the IMS to check for local delivery before
letting it upload a message. If the recipient isn't local, the IMS will
return 550 Relaying not permitted."

The pointers at MAPS TSI which suggest registry modifications are outdated and cause excessive error messages - use these Microsoft Knowledge Base articles: q193922 (Doesn't mention that Exchange 5.5 SP1 provides a GUI for this until the end.), q195969 and q196626.

Bob Poortinga has put together several pages detailing how to properly configure NMS to prevent relaying at http://www.tsc.com/~bobp/nms-no-relay.html.

# operators that cannot be in local usernames (i.e., network indicators)
CO @ % !

Sendmail Inc describe version 8.6 and earlier as "Not supported, not secure and should NOT be run on a network-connected computer.".

Sendmail 8.7 is full of buffer overruns and multiple cookbook root shell exploits are widely circulated. If you are running this software disable it!

Sendmail now state in their FAQ that all versions prior to 8.9.3 are no longer supported

Additionally all versions of sendmail prior to 8.8.9 are susceptable to a HELO buffer overflow attack. 8.8.4 and earlier suffer from vulnerabilities which allow attackers to gain root shells.

During July-August 1999, several thousand sendmail 8.8 installations were exploited by a spammer using RCPT TO:<"victim@target"> - with the "" in the envelope. If you have an ORBS notice with "X-Envelope-Recipient: <"someone@example.org"> " in the last few lines, then this is the test your sendmail installation failed.

Claus Assmann's check_rcpt Sendmail 8.8 antirelay hacks were updated to fix the "", %, ! and : vulnerabilties on 24 August 1998 and his work can be viewed at http://www.sendmail.org/~ca/email/check.html.

These fixes are also applicable to MetaInfo Sendmail 8.8, which is a third party Microsoft NT port of Unix Sendmail. MetaInfo do not produce a port of Sendmail 8.9 or 8.10 and because of this, we strongly discourage use of MetaInfo software - see the comment below about Sendmail 8.8 support. If you wish to run Sendmail under Microsoft NT, Sendmail now produce this directly and like MetaInfo's previous ports, this is full commercial software - not freeware. See www.sendmail.com.

Vintra Mailserver Professional 2.02 appears to be another sendmail 8.8 port - with the same "" bug.

Fujitsu Teamware: Older versions normally use the MetaInfo Sendmail 8.8 package, but Sendmail 8.9.3 has been shipped since 22 February 2000.

More useful information is available at http://hexadecimal.uoregon.edu/antirelay/

Sendmail 8.8 is unsupported by Sendmail Inc. and there are probably more relaying and security holes lurking in it. Update to 8.9.3 or later!

8.10.2 is a bugfix release of 8.10.1 which addresses some dangerous Linux behaviour.

8.10.1 was a bugfix release which addresses some dangerous AIX linker behaviour. It has selection of multiple DNS blacklists built in, excellent SMTP level spam filtering facilities and the ability to switch off spam filtering/backlisting on a per-user basis for those users who insist on getting every last piece of spam they want.

Update to the latest stable version of Sendmail if you can, these versions contain the features need to support secure authenticated support for roaming remote users and will incorporate security fixes as the come along. Always check Sendmail's website to see what the latest current version is and view the changelogs.

Linuxconf users beware! - Linuxconf was found to be generating faulty (old) check_rcpt tables as recently as 20 July 1999. Make sure your version is newer than this before using it to generate sendmail.cf files. All versions of Redhat Linux prior to 6.1 were shipped with the faulty Linuxconf. Update!

Sun Admins: Try http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access for updates to sendmail 8.9.x. Make sure you install the antirelay.cf. Sun's standard sendmail.cf is a wide open relay...

Who: Pauline van Winsen 
What: Caught Bug where smtpd would treat dn_expand failure in expanding
an NS or MX record too seriously - as a syscall failure allowing message.


See http://www.postfix.cs.uu.nl/faq.html#open_relay
and 
http://www.postfix.cs.uu.nl/uce.html

(old data)An anti-relay patch to TIS smap lives at http://www.cih.com/~hagan/smap-hacks/ Mind the accept() call...

2.* cannot be secured. Update to 3.03E - this is a free upgrade.

3.* versions prior to 3.03E cannot be secured. Upgrade to 3.03E

4.* is secure by default. Make sure you do not accidentally reconfigure it as an open relay.

5.* is secure by default and supports SMTP authentication

"Strict SMTP Adherance" under the "Options Tab" must be checked, or the host will relay for RCPT TO:<user%host@relay> envelopes.

An SLmail admin has offered this tip regarding restarting the services:

SLMail runs as separate NT services for POP and SMTP.  Under the remote web
administration client (required in version 4.0), any modifications to the Relay
Filtering tab require both services to be restarted.  The web client Control
tab provides for remote restarting of the POP service, but not the SMTP
service.  Thus an administrator may mistakenly believe that new settings have
become active, when they have not.  The SMTP service must be manually restarted
to enable new settings in the Relay Filtering tab.

If not properly setup, or if the user database is corrupted, ORBS notices to postmaster@[literal.IP.address] cause the server to mailbomb itself into the ground. This is not ORBS' fault and is just another result of its very poorly designed message handling. Most MTAs drop messages after 17 loops specifically to prevent this kind of problem.

cc:Mail cannot be secured and must only be operated behind a firewall with a secure intermediate server handling in- and out-bound mail.

Update to Lotus Notes version 4.6.4 or later

In NOTES.INI, set:

SMTPMTA_REJECT_RELAYS=1
SMTP_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 - (NOT "SMTPMTA_OCH_..")
SMTPMTA_RELAY_FORWARDS=1

If SMTPMTA_OCH_REJECT_SMTP_ORIGINATED_MESSAGES=1 is used, the host will still relay. Check your spelling!

Using this line disables the ability to forward messages offsite. Not using it leaves the host vulnerable to "" enclosed envelopes.

The configuration document in the Domino Directory has a section for SMTP Inbound Controls.

Enter a * in both of the following fields:

"Deny messages from external internet domains to be sent to the following internet domains:"

"Deny messages from the following external internet hosts to be sent to external internet domains:"

Note: These fixes restrict smtp relay access to authorised IP ranges. If no ranges are explicitly defined, then the IP range of the server itself is assumed.

We can only surmise that Novell are deliberately lieing about this, because they have been repeatedly advised by ORBS and Novell customers that the article is wrong. The motivation seems to be to deny the fault and hope that customers with unfixable software will assume that the ORBS tester is making errors, instead of demanding their money back from Novell.

GW5.5 GWIA appears to be OK if fully patched. - This set of instructions comes from one admin who has managed to lock his server down.

"...In Netware Admin, open the SMTP gateway, scroll down to the panel
'Access Control', click on the SMTP Relay button (which does not appear on
early versions of the gateway, apparently - needs v5.x or later, I
gather...) and in the ensuing SMTP Relay Access panel that appears,
prevent message relaying - we worked our way through making one or two
exceptions to allow for mail to come from a few dial-up users.

This aspect is pretty straight-forward, but the all important part is
to restart all NLMs associated with the gateway. We found that a complete
restart of the server was the best option, but I understand that if one
can track down and release and restart all NLMs that operate either the
gateway or GroupWise then this would work too. We took the safer option
and restarted the lot, checking that our startup config files did not
override what we had changed prior to restart.

Another admin reported these instructions don't work for him.

...
So yesterday I got in a mail software package, NLM based, for Novell servers
called Mail v.3.0 from Unoverica (www.unoverica.com).  Besides securing the
mail relay, it is going to let me do some other neat things such as splitting
mail between multiple mail systems while receiving for only one domain.

I finished installing the Unoverica stuff at about 17:00 CDT, and cleared the
data base in ORBS shortly after that - so far so good I haven't received any
email from your system ...

This Unoverica package is neat, very small footprint, very little drain on the
server and is a full featured mail host, user data base, aliases, synonyms, or
can simply pass off to other systems.  The cost is under $ 500.00 (US) and the
documentation and support is excellant.

I guess what I'm trying to say, is that for Groupwise mail systems, the
Unoverica software sitting out "in front" for the "GWIA", or MTA as you call
it, is, in my opinion, a better solution than trying to secure the Groupwise
system alone.
...

   I have a customer with a GWIA behind a firewall that also received a
   similar message from ORBS. I found the Novell TID (can't remember the
   #) about turning off SMTP relaying and turned it off appropriately via
   NWAdmin. The GWIA continued to be used for spamming, and
   we received a 2nd message from ORBS. Upon further investigation I
   found that the TID said that making the NWAdmin change to turn off
   SMTP relaying was supposed to add the "/norouting" switch to the
   GWIA.CFG file (and there were warnings in the TID that said not to
   edit the file manually). When I checked GWIA.CFG after making the
   NWAdmin change, I found that the "/norouting" switch was NOT being
   added, and was not there. So I manually edited the file to add the
   switch, anyway. I then restarted the GWIA, and it worked.

The document 2946887 (3 Nov 1999) Blocking Mail Relay or Spamming (security) at http://support.novell.com says it all:

"Unlike other sophisticated sendmail processes, such as those found
in the UNIX environment, the GWIA daemon is a very basic sendmail
process..."  

GWIA should be regarded as suitable for Intranet applications only. It is not flexible or robust enough to handle remote users without opening serious security issues. All current antirelay setups will result in local users with pop3/smtp clients being unable to mail external domains, so are kludges at best. If the server is opened up enough to allow local pop3 clients, the server will relay for anyone spoofing the server's domain name from anywhere on the Internet. Don't do this. Spammers routinely forge domains in order to relay. Attempting to rely on legal deterrents is ineffective - international legal action is difficult-to-impossible in most cases and in some jurisdictions a Novell admin may find himself the subject of legal action or supplier AUP enforcement for leaving insecure machines connected to the Internet.

PMDF Relay blocking information is available here.

Failure to correctly follow upgrade instructions may result in your machine still relaying, or (worse) has been known to result in messages going into infinite loops and mailbombing the admin of the Mercury server's smarthost.

SMTDREV performs reverse DNS on incoming mail.  Many spammers use fake
information and WG will reject it if this option is set to YES. 

SMTDHOST allows relay of mail to your server.  If you set it to YES and
then set SMTDLOCR to YES, it will only allow the relay of mail that is TO
or FROM someone on your system. 

SMTDBLOK is the file containing the list of IP addresses that will not be
allowed to deliver mail to your server

The software has a very nice spamtrap feature - if you create defined bogus addresses on the server and a spammer attempts to deliver to them as part of a multiple RCPT TO: run, the server will reject the delivery entirely. The bogus addresses can be seeded out on Usenet or Websites, or an admin can insert addresses known to exist on spamware CDs. See the Stalker website for more details.

From a mail essentials admin:

Their information regarding open relays is not very clear. 

However after some trial and error we found that in the configuration
interface in:

server settings, 
SMTP options, 
advanced SMTP options, 

you need to add your local domain with internal IP address in the allow
relay from list. This then prevents (hopefully) relaying from any other
location and generates the 550 message to the RCPT TO:. 

http://spam.abuse.net/tools/smPbS.html

http://www.cynic.net/~cjs/computer/sendmail/poprelay.html

http://www.qmail.org/open-smtp3.tar.gz

http://www.davideous.com/smtp-poplock/

http://bsd.reedmedia.net/Software/Servers/SMTP_Mail/POP3_Authenticated_Relaying/

http://www.imc.org/rfc2554 - the SMTP-AUTH specification.

http://www.sendmail.org/~ca/email/mel/ - Alexey Melnikov's sendmail pages on SASL, hosted at Clauss Assmann's sendmail site.

http://www.sendmail.org/~ca/email/auth.html - Claus Assmann's SMTP AUTH help pages (sendmail 8.10 and later)

http://www.sendmail.org/~ca/email/starttls.html - Claus Assmann's SMTP STARTTLS help pages.

http://www.faqs.org/rfcs/ rfc2476.html - SMTP Message submission. Discusses alternate ports, procedures, etc.

The MAPS RBL is highly effective at convincing networks to stop supporting spammers because the number of admins using it means that a host entered into MAPS loses a lot of connectivity. MAPS is almost completely useless for general spam stopping because it is far too slow to catch spammers on a day-to-day basis.

RSS serves a valuable purpose, however there is a strong feeling of "closing the barn door after the horses have bolted"

Additionally, RSS lists a lot of hosts which have been secured. On 5th June 2000, out of 31,193 hosts in RSS, 12,425 were not in ORBS - subsequent checks by a third party revealed that only 828 of those hosts were open relays. The wisdom of using MAPS RSS data for spam filtering purposes is called into serious doubt while it has a 40% false positive rate.

RSS admins have been queried about this. the reaction has been uniformly hostile and basically boils down to "we know better than you".

In order to track this continuing inaccuracy, ORBS makes the following data files available. These are compiled using freely available MAPS RSS data and comparing it with ORBS data.

Anyone was able to produce these lists themselves with a simple one line Unix shell script:

dig @relays.mail-abuse.org relays.mail-abuse.org axfr | grep nph | cut -f2 -d\? | cut -f1 -d\> | sort

the following perl script will still work to obtain zonefile listings.

#!/usr/local/bin/perl
#
open(DIG,"dig \@ns-ext.vix.com relays.mail-abuse.org axfr|");
while() {
        if(/^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)/) {
           ($d,$c,$b,$a) = ($1,$2,$3,$4);
           print "${a}.${b}.${c}.${d}\n";
        }
}
close(DIG);

"ns-ext.vix.com" is the master server, however any of these other listed relays.mail-abuse.org nameservers may be used instead: ns1.fsckit.net, amethyst.nstc.com, topaz.nstc.com, freesbee.wheel.dk, hirohito.acc.umu.se, ns2.sackheads.org or sdn.iecc.com

rsslist.txt [not available] - The complete RSS listing.

rss-vs-orbs.txt [not available] - Hosts in RSS not in ORBS.

rss-vs-orbs-ok.txt [not available] - Hosts in RSS which ORBS has tested as OK.

Teergrubing should only be attempted by those who have too much spare time and know exactly what they're doing. If you don't know what Teergrubing is, you shouldn't even consider it.

Late note: Using Teergrube techniques on open relays, spam sources and unauthorised remote dialups, then finally telling them to go away without accepting the mail would be devastatingly effective at slowing down spam if a few hundred of the most heavily used mailservers worldwide adopted this idea. Adding this kind of functionality to any MTA is not a task for the faint-hearted, but should be possible with Sendmail, at least.