How Does Our Test Machine Works?


    The engine that works in our test machine is called ORVE (Open Relay Verifying Engine), its principle of work is to connect to a remote host to test, to request to send a message and to verify (if the message was sent) if it comes back intact.
    There are 20 vulnerability tests that our ORVE uses to test the remote host`s MTA. Below we describe some of them (more detailed in ORBS):
  1. The classic open-relay test:
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<relaytest@antispam-ufrj.pads.ufrj.br>

  2. The classic open-relay test with the "" (Sendmail 8.8 and others MTAs, much used by the spammers):
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<"relaytest@antispam-ufrj.pads.ufrj.br">

  3. The non-RFC821 compliant test (MS Exchange and SLmail betas):
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:relaytest@antispam-ufrj.pads.ufrj.br

  4. No sender-domain vulnerability (Post.Office, Intermail and Sendmail 8.8 misconfigurated):
    MAIL FROM:<spamtest>
    RCPT TO:<relaytest@antispam-ufrj.pads.ufrj.br>

  5. A heavily exploited vulnerability (Lotus Notes/Domino, Novell Groupwise, badly secured Sendmails and others):
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<relaytest%antispam-ufrj.pads.ufrj.br@{relay}>

    Where {relay} is [IP.address] and [reverse.DNS.name]

  6. A variation of the vulnerability above (using @ instead %, but less popular among spammers):
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<relaytest@antispam-ufrj.pads.ufrj.br@{relay}>

    Where {relay} is [IP.address] and [reverse.DNS.name]

  7. Mixed UUCP and Internet addressing (common with Sendmails with FEATURE(nouucp) set):
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<antispam-ufrj.pads.ufrj.br!relaytest@{relay}>

    Where {relay} is [IP.address] and [reverse.DNS.name]

  8. A heavily exploited vulnerability using the ':' character:
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<@{relay}:relaytest@antispam-ufrj.pads.ufrj.br>

    Where {relay} is [IP.address] and [reverse.DNS.name]

  9. An old UUCP style vulnerability:
    MAIL FROM:<spamtest@antispam-ufrj.pads.ufrj.br>
    RCPT TO:<antispam-ufrj.pads.ufrj.br!relaytest>

  10. NULL sender vulnerability:
    MAIL FROM:<>
    RCPT TO:<relaytest@antispam-ufrj.pads.ufrj.br>

  11. The most of the online testers actually perform a check as below:
    MAIL FROM:<spamtest@{relay}>
    RCPT TO:<relaytest@antispam-ufrj.pads.ufrj.br>

    Where {relay} is [IP.address] and [reverse.DNS.name]

    In spite of our ORVE work with no intention to cause any problems on the remote machine's operating systems that it's testing, we know that problems may occur in some systems, an example are systems running MS Exchange. A fragment of a report from a Microsoft Windows NT/2000 administrator about a relay-test from our ORVE is presented below:

    "Now please note that this unauthorized test by one of your users resulted in the processor running maxed out and our server being slowed to a crawl."

    Note that if a system crashed because of a simple open-relay test, its administrator(s) must consider to upgrade its Mail Transport Agent (MTA) or verify its configurations URGENTLY, because in a real spam attack the consequences may be unexpected.
    Some administrators consider spam-tests from online testers machines, like ORBS, an invasion or an unauthorized mail test of its machines. We have been observing that, generally, only the administrators of the insecure machines keep using this argument (unauthorized mail test), in the hope that their insecure machines will be removed from our databases before they secure their open-relays machines, if they secure them... We recomended that, instead of reporting their indignation to us because our ORVE's verification, they could use this precious time to secure their systems and/or MTAs quickly.

    NOTE: Our realtime lists are freely exported by anybody who wants to use them. If any host XXX blocked a delivering mail from a third-party host that is listed here, it is because the third-party host MUST comply with the rules that the XXX's admin (not our rules) requires to a mail message can be delivered to it. We are just verifing to the XXX's admin whether a host is a spammer, open-relay or IP/DIALUP machine or not.