- -

Other resources

A warning for those who wish to leave an open relay in place. [was a hyperlink to a file I don't have]

Securing and testing servers

  • There is lots of useful information at the MAPS TSI fixes page, however large portions of it are significantly out of date, so check the rest of this page first. If/when MAPS TSI pages are updated, duplicate information on these pages may be removed without notice.

    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.

  • http://samspade.org/d/nanaefaq.html#4.3 is also worth looking at.
  • Try Abuse.Net's new relay tester (requires registration). This is the only web-based tester which carries out the same set of tests which ORBS does. (In fact, it covers a slightly wider set, as ORBS only tests for vulnerabilities being used by spammers..). This tester may give false negative results for servers which accept mail, then decide what to do with it later, because it stops the test sequence as soon as one message is accepted. ORBS relies on delivery to final destination in order to decide if a host is open. Not all hosts which accept test messages are open relays - this includes correctly set up MS Exchange, Lotus Notes and Novell GroupWise servers.

    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.

  • Offline checkers: The Unicom tester allows setting of arbitrary envelopes via command line flags. This is regarded the swiss army knife of relay test programs and has been around almost forever with only minor changes. (Requires perl 5.004 or later.)
  • Russell Foster's relay checker runs a "full" test of tests on a specified host and is configurable to add more tests as vulnerabilities show up. (requires perl)
  • The set of tests ORBS makes is described here. As you will see, most online testers miss most configuration faults.

  • IP access lists: Whenever possible, define lists of hosts allowed to use your server to relay by IP number only, as in a lot of cases defining domain names will leave you vulnerable to sender envelope or DNS forgeries.
  • Specific software items

  • If you have a HP3000 computer and use 3k Associates software, refer to the manual and 3k's online newsletters for details on enabling spam-checking facilities.
  • MS Exchange admins: Update to MS Exchange 5.5 service pack 2 postfix 2 or later and read http://www.microsoft.com/technet/exchange/relay.asp
  • Even when correctly set up, MS Exchange servers cannot be tested by abuse.net. Just file your server closed once you believe you have applied the routing fixes correctly.

    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
    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."
    If you are providing SMTP service to a local network, you need to define the local network's IP addresses as "allowed to relay", or local users won't be able to send mail offsite...

    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.

  • (Jan 10 2000): Installing Windows NT service pack 6a breaks antirelay settings. Make sure you reapply them after installing this service pack.
  • (August 7 1999) Microsoft have discovered a new vulnerability not yet being exploited by spammers. Details in q237927. Update to SP3. If you cannot upgrade for some reason, there is a fully supported patch available - update now! - ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/Exchg5.5/PostSP2/imc-fix
    Click here for sp4
  • MS Exchange 5.0 can only be secured against unauthorised relaying by disabling all internal POP3/SMTP access. That is, all internal clients must be running Microsoft message exchange software and email clients such as Pegasus, Eudora, Netscape, etc cannot be used after the server has been secured in this way. This should be regarded as a temporary fix, because eventually someone will probably re-enable POP3/SMTP. Please update to MS Exchange 5.5sp2 or later as soon as possible.
  • Owners of MS NT Small Business Server (SBS) 4.0 are able to upgrade to 4.5 for free or a nominal fee. This includes an update to MS Exchange 5.5.
  • To quickly verify a machine: Any MS Exchange mailserver which shows a version number below 5.5.2448 on its SMTP port is unlikely to be fully secure. 5.5.2448 is only secure by explicit configuration as MS Exchange defaults to no relaying control
  • MS IIS SMTP Service: See q230235 in the MS Knowledge Base.
  • Netscape Messaging Server 2.*: This cannot be secured. Update.
  • Netscape Messaging Server 3.*: Netscape's documentation is poor and the antirelay examples they provide are easily defeated. Among other holes, a spammer may set as many non-local RCPT TO:<> lines as he likes, as long as he sets at least one local RCPT TO:<> as the first recipient.

    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.

  • Even when correctly set up, Netscape 3.* servers cannot be tested by abuse.net. Just file your server closed once you believe you have applied Bob's fixes correctly and have restarted the server.
  • Netscape Messaging Server 4.*: According to admin reports, the built in antirelay features in 4.15 work - and quite well too. This version also fully supports Authenticated SMTP, so 3.* admins should consider updateing to take advantage of that feature - it allows offsite authenticated relaying without exposing the server to spammers.
  • Sendmail admins: http://www.sendmail.org/tips/relaying.html has quite a few useful bits of information...
  • Feature(nouucp) is buggy in all versions of sendmail up into the 8.10 betas, as well as in 8.11.1 (fixed in 8.11.2) If you enable this feature, you will need to manually add the ! character back into sendmail.cf's CO macro.
    # operators that cannot be in local usernames (i.e., network indicators)
    CO @ % !
  • Failure to do this may result in your machine relaying for UUCP pathed checks.
  • If you need sendmail on a machine so that processes can send out mail, but no inbound mail facilities are needed, all you need to do is change sendmail's startup settings by removing the "-bd" flag. It's the -bd flag (-bD if run in the foreground) which tells sendmail to listen on port 25 and if that is deleted, it will only deliver locally generated mail rather than acting as a full-blown mailserver. Please note: this will only secure a server for as long as the -bd flag is disabled, so should be regarded as a temporary measure. Eventually, someone is bound to accidentally re-enable the -bd flag. Wherever possible, please update to sendmail 8.9.3 or later.
  • Sendmail 4.x, 5.x, 8.6, 8.7: These cannot be secured against unauthorised third party relaying without major work. Additionally, most versions have major vulnerabilities allowing remote attackers to execute arbitrary commands as the sendmail userID (usually root) and which may allow remote or local attackers to gain a root shell on the server. If you have one of these sendmail versions, disable or update it immediately and audit the security of the entire machine, taking particular care to check for installed backdoors..

    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

  • Sendmail 8.8: Some of the antirelay .cf file hacks linked from mail-abuse.org/ar-fix.html don't adequately protect against relay attacks using %, : or ! pathing control characters in the RCPT TO: header.

    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!

  • Anyone continuing to use a Sendmail version earlier than 8.9.3 is sitting on a security-related time bomb. Update before your server is abused as a spam relay or used as a relay point for other attacks.

  • Sendmail 8.9.0 and 8.9.1 are susceptable to relaying attacks using the : pathing control character in the RCPT TO:<> header. They are also unsupported by Sendmail, Inc. Update to 8.9.3. Details of sendmail 8.9 built in relay/spam protection features can be found at http://www.Sendmail.ORG/antispam.html
  • Sendmail 8.10: Sendmail 8.10.2 is out and proven stable

    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.

  • Sendmail 8.11: Sendmail 8.11.1 is out and proven very stable. This contains support for strong encryption thanks to recent relaxation of US Govt export restrictions and replaced a planned release of 8.10.3.

    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.

  • When upgrading sendmail to secure versions: Always generate a new sendmail.cf - continuing to use the sendmail.cf from a previous version which had a relaying vulnerability will usually result in that relaying vulnerability not being fixed.
  • A warning from www.Sendmail.org: FEATURE(`relay_local_from') will allow relaying if the sender specifies a return path (i.e. MAIL FROM: <user@domain>) domain which is a local domain. This a dangerous feature as it will allow spammers to spam using your mail server by simply specifying a return address of user@your.domain.com. - this feature should only be used on non-Internet connected servers.
  • If you are uncomfortable with M4 scripting, WIDE in Japan have a .cf generator which may be useful. It can be downloaded from ftp://ftp.jpcert.or.jp/pub/security/tools/CF/
  • Redhat linux users: ftp://admin.netus.com/sendmail/ has sendmail 8.9.3 rpms you might like to try out. Last update 27 March 1999: "pop-before-smtp with a DUL map fallthrough from the poprelay ed map".

    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...

  • Postfix admins: See http://www.postfix.cs.uu.nl/faq.html#open_relay and http://www.postfix.cs.uu.nl/uce.html
  • SMTPD admins: An admin has reported that they've been detected relaying due to this bug: http://download.sourceforge.net/mirrors/OpenBSD/src/libexec/smtpd/src/CREDITS
    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
  • TIS smap users: There are patches for the TIS FWTK smap to stop smap from being a wide-open relay. See the paragraph at http://www.fwtk.org/fwtk/patches/patches.html#2.2 for a list of the available patches. The preferred anti-relay patch is the yao-smap.pch documented in item 2 - this has been tested as clean by ORBS and also allows addons with RBL blacklist lookups to be used.

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

  • Post.Office and Intermail admins - the latest from Software.com:
  • From: Paul Kincaid-Smith
    "...Software.com's Post.Office and InterMail
    documentation clearly states
    that restricting relay by IP address is preferable to restricting relay by
    domain information. As we're all aware, the envelope headers are easy to
    forge, so don't define relay restrictions based on the "From"
    We will add a section to the Post.Office FAQ to encourage our
    customers to reexamine the effectiveness of their anti-relay

    Apparently Software.com will be releasing updated MTAs with vastly improved antirelay featuresets in June 1999.

    In the meantime, to prevent spammers relaying by not specifying a domain (MAIL FROM: at smtp level): either disable address completion completely, or set the completion to example.com. Do not make up something which looks non-existant, example.com is reserved for this kind of purpose.

    Some (not all - this only happens on machines with multiple IP addresses) Post.Office admins have been reporting that even when secured as described above, their machines are failing on MAIL FROM:<user@ip.address> - without the RFC-required [] around the literal IP address. That test is actually aimed at dealing with broken MS Exchange installations, as that MTA regards [x.x.x.x] as a malformed envelope, however spammers have been observed using it. If anyone has a pointer on preventing Post.Office relaying for this particular envelope (other then the obvious - "don't use multiple IP addresses") please advise ORBS so we can put the details on this page.

    Other admins have reported that setting "Verify recipients within Local Mail Domains before accepting mail" to "no", turns all relay control settings off. Leave it at "yes" - the default.

  • SCO OpenServer (MMDF):See http://www.sco.com/cgi-bin/ssl_reference?104596
  • Qmail admins: Qmail's current version is secure by default, but earlier versions were insecure. Most admins know enough to follow the instructions for securing it before putting qmail into service, however it usually drops ORBS test messages checking for UUCP pathing vulnerabilities - "! pathing" - into the admin mailbox. As ! is a standard network addressing indicator, this can only be charitably described as yet another Qmail bug. Qmail is extremely network unfriendly and generates denial of service attacks on other mailservers in its enthusiasm to deliver as many messages as possible in a short period of time. For this reason it is best reserved for mailing list server purposes only.
  • NTmail admins: Gordano have been very slow to act in the last couple of years and many admins have complained loudly to ORBS about lack of user support, however they now (September 2000) appear to have things under control.

    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

  • SLMail admins: Only version 4.0 or later can be fully secured. All 3.* versions relay for % addressing hacks and the only fix Seattle Labs offer is to upgrade - for a cost.
  • The fields for IP addresses allowed to relay are IP ranges, not the more usual network/netmask. IE, [start address - end address]. If you specify something like -, you'll allow every IP address from through to to have relay access to your server, not the expected -

    "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.
  • cc:Mail admins: Lotus have officially killed cc:mail off. Update to Domino.

    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.

  • Lotus Notes has one of the absolute worst user/administrator interfaces ever designed and as a direct result, stuffing things up is both easy and common. There's a good review of its multitude of failings posted at http://www.iarchitect.com/lotus.htm.
  • Lotus Notes admins: This can be secured and Lotus have recently released information on doing so:

    Update to Lotus Notes version 4.6.4 or later

    In NOTES.INI, set:


    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.

  • For Notes 5.x:

    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.

  • Even when correctly set up, Lotus Notes servers cannot be tested by abuse.net. Just file your server closed once you believe you have applied the fixes correctly and have restarted the server.
  • If ORBS tests lock up your Lotus Domino server, the most likely explanation is a corrupted user database. Rebuild it and things should return to normal.
  • Novell's Mail software is broken by design. It is an awful kludge of a poorly designed proprietary mail system to handle open standards which fails miserably in a number of areas, violating large chunks of applicable standards. Dump it and get something which works. If you can't dump it, then read on, but dumping it is the best and cheapest solution.
  • Novell Groupwise admins: Even if Novell's antirelay switches are set in this MTA, 4.x still relays for RCPT TO:<victim%target@relay> - which is becoming popular with spammers because of the number of "fixed" relays still open to this recipient envelope. Don't send us mail telling us your server is secured and we're making things up if you get a notice showing this fault. Novell's mail authors need to be spanked. Meantime, put the open relay behind a firewall and MX via an intermediate secure server.
  • Article TID10016672 (now changed to 10016672) at support.novell.com is completely wrong. ORBS only counts hosts as insecure if they deliver mail to the ORBS tester. Bounces and dumping mail do not count as open relaying. Arguing with Novell about this one by presenting evidence of the relayed message is like trying to hold a conversation with a broken record. They will ignore the evidence and parrot the same TID again.

    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.
    Yet another admin reported that the TID instructions are broken on one of the Novell admin mailing lists.
       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

    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.

  • Even when correctly set up to not relay, GWIA servers cannot be tested by abuse.net. Just file your server closed once you believe it is secured and have restarted it.
  • Wildcat5 (AKA Winserver, WcSmtp.exe): This does not allow relay by default, however a small text file called iprelay.dat in your WC5CONFIG subdir is needed to totally block relaying. As an example of what's needed:
  • - substitute your netblock and netmask for these values.
  • Mustang Listcaster All versions up to 2.1 of the SMTP service in this mailing list product are open relays and cannot be secured.

    Upgrade to version 2.2 and read http://www.mustang.com/knowledgelink/articles/441.htm

  • Smail admins: Update to or later.
  • InfiniteMail (Interchange) admins: This software cannot be secured. Dump it.
  • MERCUR admins: You MUST update to version 3.2 and service pack 1. Service pack one fixes all known holes. ALL earlier versions contain relaying holes of one type or another and MUST be updated.
  • PMDF admins: General information is available at the Innosoft website.

    PMDF Relay blocking information is available here.

  • Mercury admins: All versions of Mercury mail after 1.42 are OK, however strict relaying must be set in the .ini file and the README file MUST be carefully followed when upgrading from earlier versions.

    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.

  • WorldGroup admins:From the documentation
    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
    Set SMTDHOST to YES and SMTDLOCR set to YES.
  • Apple Internet Mail Server (AIMS): This was bought by Qualcomm several years ago and is now Eudora Internet Mail Server (EIMS). 1.0 is _not_ secureable (but was free anyway). 2.* is securable, but is not freeware. 2.* supports <Authenticated SMTP. which means it supports roaming users with no further modification required.
  • Appleshare admins: http://til.info.apple.com/techinfo.nsf/artnum/n31108 has details on securing Appleshare IP 6.2 servers. Earlier versions are not securable.
  • Mailbeamer admins: http://www.dataenter.co.at/doc/mailbeamer_admin_options.htm#Relay has details on securing Mailbeamer servers.
  • InterScan VirusWall admins: See http://solutionbank.antivirus.com/solutions/solutionDetail.asp?solutionID=3641 Unfortunately, various antispammers report that the posted fix is woefully ineffective and will result in serious mail losses as it uses text content matching, not relay control techniques.
  • McAfee WebShield admins: This software has no effective relay control. Antivirus processing must be placed after your mailserver, not in front of it.
  • Norton Antivirus for Internet gateways: This software has no effective relay control. Antivirus processing must be placed after your mailserver, not in front of it.
  • Stalker Internet Mail Server: This is secure by default, free, runs on Macintosh and is the little brother of Communigate pro.

    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.

  • Mail Essential: This is a front end MTA for MS Exchange servers, produced by GA(?)

    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:. 
  • Xtramail: This was owned by Artisoft, but is now a Spartacom product. See Technote RN4077 and Technote TN4078 for details of how to correctly fix this package.
    Admins may wish to reconsider using this package, as Artisoft have hired spamhausen in the past and reports are still appearing of spam from their new owners - mainly via Digital River.
  • Other useful items

  • DRAC - Dynamic Relay Authorisation Control - one method of allowing remote users to use a secured relay. DRAC is specifically designed to scale across clusters of servers - separate smtp and pop3 servers, possibly more than one of each - however it also works very well on single machine setups.
  • Other pop-before-smtp solutions:






  • Note: ANY MTA which uses external IP access tables can be adapted to use pop-before-smtp or DRAC authentication methods. The modifications made are to the POP3 server, not the mail server.
  • AUTHENTICATED SMTP - The way of the future - DRAC, pop-before-smtp and other mthods are out-of-band hacks. This is the only method which closes off all possibilities of unauthorised third parties coming in just behind an authorised user.

    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.

  • SSH tunnelling - a wonderful solution. Encrypted (and compressed if desired) links mean that message bodies, UserIDs and passwords are all safely hidden away from Prying Eyes. The nice people at Northeastern University have a SSH tunnel setup help page for their users which can be easily adapted for use on any mailserver which has a SSH server running.
  • Spamhaus databases

  • The MAPS RBL The grand-daddy of all RBL-style systems. No site should ever be without a set of filters referring to this RBL. ORBS only databases open relays. The MAPS database contains known rogue netblocks, spam factories and problem relays with admins who flat-out refuse to fix them.

    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.

  • Open Relay databases

  • MAPS RSS MAPS Relay Spam Stopper. Originally created by Al Iverson because he felt ORBS was picking up too many open relays which hadn't (yet) been used to spam. This only contains direct relays which have been used in spam attacks and may be more suitable for admins who want to block spam but don't want to block every open relay. RSS contains around 10% the number of open relays that ORBS does, however every entry is documented as actually relaying spam.

    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
    ". MAPS removed TXT records in mid-August 2000, citing excessive zone transfer traffic - if they were really concerned about that they would remove the bogus entries.

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

    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";

    "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.

  • The Internet Mail Relay Service Survey. Down since October 1999, will never return This actively sweeps netblocks worldwide looking for open mailservers. It's also fed from an extensive range of spamtrap addresses. This is the database to use if you want to tag or stop mail from open relays, however implementing filters based on data from it may be politically sensitive because of the "hunting down open relays" aspect of their operation. While IMRSS databases wide-open relays (and there are a lot more of them in the IMRSS database than there are in ORBS), ORBS quite often includes hosts which IMRSS thinks are OK, because they fail ORBS more extensive range of tests. IMRSS contains around 5 times as many open relays as ORBS.
  • Dialup or other endpoint databases

  • Dialup User List - a database of IP addresses assigned to dialup modem lines. These should be using their local SMTP server, not yours. Implementing filtering based on this will substantially reduce spams received "Direct from dialup" - ie, not via an open relay and usually from an account the spammer regards as expendable.
  • Direct Spam Sources List - another defunct IMRSS project. Lookups in this RBL domain are converted to names via reverse-DNS lookup, then pattern-matched with what's known to be used by ISPs in dialup naming. Implementing filtering based on this should reduce received "Direct from dialup" spam.
  • Things which don't work - Rate limiting and limiting recipients per message.

    These don't work as relay control methods. They used to have some effect, but all that happens now is that spammers are relaying a few messages per server through a lot of servers in each spam run. It is actually resulting in the spam relay problem becoming worse again, because admins using rate limiting techniques or setting low maximum numbers of recipients believe that their machines are secured, so refuse to take further action. While individual machines become less abuseable, the overall effect on spam is negligable - and admins who limit messages to fewer than 20 recipients per message are only succeeding in irritating their own users. Most current spamware is capable of automatically determining the maximum number of recipients a server will allow, then sending to that many per message.
  • Teergrubing is still effective to some degree for relay control, but only when it used with exponential backoff algorithms. In general it's easier to implement external authentication mechanisms.

    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.

  • Other useful links

  • Get that spammer!
  • Netdemon - a useful piece of windows software with selectable automatic ORBS reporting and testing for open relays it finds.
  • SpamCop.
  • Spam Killer Central
  • A securityportal article covering ORBS
  • Sapient Fridge's Spamware shame pages
  • Spamhaus.org's lookup database
  • Junkfaxes.org - spam has been around longer than the Internet as we know it.
  • MacInTouch's Spam Resources page.
  • Brad Spencer's musings on how to use a recently closed relay as a way of fighting off spammers.
  • Consultants who may be able to help you close your relay [link deleted, file not available]
  • Japanese admins - click here for Kanji antispam pages.
  • ORBS has no affiliation with any of the websites or domains listed above. If you wish to block/filter spam from being received, you should consider using MAPS+ORBS+DUL at minimum. We recommend MAPS+ORBS+DUL and use this on our main server.
    Back to ORBS Home^H^H^H^H^H^H^H^H^HNorman's Anti-Spam Page

    Database disclosure policy [not needed on this page, nothing collected]