Spamhaus
The Spamhaus Project
Home  |  News  |  FAQ Index
 FAQ Documents


Frequently Asked Questions (FAQ)

Data Feed
DNSBL Technical
DROP FAQ
Generic Questions
Glossary
ISP Spam Issues
Legal Questions
Marketing FAQs
Online Scams
ROKSO FAQ
Spamhaus PBL
Spamhaus SBL
Spamhaus XBL


ISP Spam Issues

"Abuse@domain" & "Feedback Loops"
We get a lot of abuse mail, how can we handle it?
How do I connect with other "abuse desks" in the industry?
Dynamic IP lists & port 25 blocking - strongly suggested!
How do users send mail if Port 25 is blocked?
What is "proxy hijacking"? What do I need to know about proxies?
What is a "honeypot" or "proxypot"? What is a "proxy hijack source" or "C&C"?
Should an ISP use the XBL to block their own users since it means they have a virus or open proxy?
Backscatter from spam firewalls and anti-virus systems
Why should I worry about reverse DNS (rDNS)?
How do I get rDNS working?
What rDNS naming convention should I use?
Got any info on PHP Nuke exploits?
What's this ARP (Address Resolution Protocol) daemon spoofing?
What is "fast flux" hosting?
Info on the Windows MetaFile exploit (WMF)
My customer says it's not them; is that true or an excuse?
What is the right way to send bulk e-mail?



"Abuse@domain" & "Feedback Loops"
Reporting spam is a long and venerable tradition on the internet. Most ISPs consider well-crafted spam reports to be a favor to them; they want to know about the problem so they can fix it. In fact, spam reports are often the most effective means of identifying a problem on your network before it becomes worse (or listed in SBL!). There are even specific "abuse role accounts" required by the "RFC" documents which are the blueprints of the internet:

ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt "Postmaster"
ftp://ftp.rfc-editor.org/in-notes/rfc2142.txt "Abuse" (and others)

A "role account" is an e-mail address which serves a role function, not an individual person, for example "sales@" or "info@". Postmaster@domain and abuse@domain are the two accounts which every ISP, webhost, mail service, and DNS host must have in order to promptly identify spam and abuse related problems on their network. Networks which don't tolerate spammers are careful to look at their "abuse" mail every day and take effective actions to stop any problems which arise.

A standard Abuse Reporting Format (ARF) has been proposed and is in the early adoption phase. It is intended to help streamline the spam reporting process when used in conjunction with automated "feedback loops" established between the reporting ISP and the recipient. ARF follows existing RFC2045 MIME standards for e-mail (and the earlier RFC1341).

A single spam report could be a fluke or someone reporting mail they actually signed up for, or it could represent 10,000 or more spam recipients. For wide-scale, pure-spam mailshots, the reporting rate is often even lower than 1:10,000. In general, hand-crafted reports are more likely to be actual spam than reports from automated "this is spam" buttons. Evaluate reports as you will; ignore them at your peril!

Here are some tools which can help direct spam reports to your proper role account:

1. The Network Abuse Clearinghouse
Not a reporting service per se, but a database of correct addresses for spam reports based on domain. Registered users can send spam reports via its mail server, or anyone can query it to find reporting addresses for a particular domain. Since reports are not automated, volumes tend to be lower and reports hand-crafted. This may identify some of the more "stubborn" spammers on a network, for example clickthroughs and redirectors.

To add your abuse role account to abuse.net, contact update@abuse.net and use format given in the example on http://www.abuse.net/addnew.html ("domain: role-account").

2. SpamCop
SpamCop reports the spam source, relay, and spamvertised URLs in the message body based on IP. Anyone can use SpamCop to report spam. It can be high volume depending on your network. Follow the instructions on this page if you wish to receive SpamCop reports or daily summaries about spam problems in your IP space. For more information see the SpamCop FAQ for abuse-desks and administrators.

3. AOL Feedback Loop: http://postmaster.aol.com/tools/fbl.html
When AOL users click the "This Is Spam" button in their e-mail client, this system can generate a "SCOMP" report to you. You must sign up for this free service with AOL. While it can be high-volume, it offers excellent feedback on proxies and virus infections on your network. (And same with the MSN, Yahoo!, and Outblaze systems, too.) AOL's whitelist info is here.

4. Yahoo!'s spam reporting service for spam detected on their network: http://help.yahoo.com/help/us/mail/defer/index.html

5. Outblaze (mail.com)
Request a feedback loop for your network by contacting postmaster@outblaze.com.

6. Microsoft, msn.com and hotmail.com, has feedback loops and other information for bulk mailers at http://postmaster.msn.com/. Their here, and see their "SNDS pages.

7. Juno/Netzero bulk mailer feedback loop and whitelisting policy.

8. Road Runner Feedback Loop FAQ

"Coming soon" are feedback loops with Earthlink, Excite and more. Watch their websites for more information. (And we'll be happy to post it here, once it's announced...please let us know.)

Finally, be sure that your network has an enforcible Acceptable Use Policy (AUP) as a part of your contract with each and every customer! More examples are here. Seek legal counsel to ensure that your AUP will cover you in the event of account termination for abuse.


We get a lot of abuse mail, how can we handle it?
There are two queue-management tools designed specifically with the needs of an abuse desk in mind. They both come highly recommended and are both used in production environments at large ISP/NSP abuse departments:

  • Abacus commercial ticketing/tracking system
  • RT Incident Response open-source ticketing tool

    Also, procmail can be extremely useful for sorting an inbound mail stream.


  • How do I connect with other "abuse desks" in the industry?
    The Messaging Anti-Abuse Working Group (MAAWG) is the first step in an effort to align the messaging industry stakeholders along three directives: Collaboration, Technology and Policy. MAAWG provides an excellent opportunity for social networking with other responsible senders and receivers. Another touchstone is the Coalition Against Unsolicited Commercial Email (CAUCE) and its international affiliates. Two open-subscription, discussion-format mailing lists have quite a few abuse desk staff on them, Spam-L and NANOG.

    Dynamic IP lists & port 25 blocking - strongly suggested!
    Dynamic IP ranges are a huge source of spam: dialup, cable, and DSL. The users of those ranges are often vulnerable to attacks by viruses and Trojan Horse proxy software installed by virus infections which turn their computers into zombie spam spewers. Dynamic IP users on your network should send their mail out through your network's outbound customer servers, or through other dedicated outbound "smarthosts" accessible via SMTP AUTH (authenticated) on port 587: RFC2554, RFC2476, RFC4409.

    The best way, then, to stop the massive amounts of dynamic IP proxy spam is for your network to filter port 25 on dynamic ranges, only allowing port 25 access to your smarthosts (or not even that, if your smarthosts use AUTH). The Messaging Anti-Abuse Working Group (MAAWG) has its recommendations on port 25 blocking here. If you run a NAT gateway, see http://cbl.abuseat.org/nat.html

    But even if you cannot (yet) block port 25, most other networks would rather not accept any mail from dynamic ranges. To help them do that, it is polite for your network to list your dynamic, end-user, IP ranges in these common DNSBL "dynamic IP" lists:

    Spamhaus PBL (coming soon; Q3/Q4 '06)
    SORBS DUHL (publicly accessable)
    NJABL Dynablock (publicly accessable)
    MAPS DUL (proprietary use only)

    Besides being a good Internet neighbor and helping other networks avoid spam from your users, listing your addresses in a dynamic IP list makes those ranges less attractive to spammers because they know they can't deliver to many networks which use those lists.

    Please add your dynamic IP ranges to those lists!


    How do users send mail if Port 25 is blocked?
    With SMTP AUTH "SUBMISSION" protocol: ftp://ftp.rfc-editor.org/in-notes/rfc2554.txt

    What is needed:

  • ISP configures its server to accept SMTP AUTH connections on port 587; nearly all modern mail servers support it.

  • Each user configures his or her mail client (MUA) to connect via 587, with username/password. Nearly clients nowadays have that as an option; use the mail client's "help" menu.

    In Outlook and Outlook Express, the menus for that are something like this:

    - Internet E-mail Settings
    - - Outgoing Server
    - - - [x] My outgoing server (SMTP) requires authentication
    - Advanced
    - - Server Port Number
    - - - Outgoing server (SMTP): [587]
    - - - [x] This server requires an encrypted connection
    That way, only authorized users can connect to your mail server, you know exactly what account it is, and they bypass "port 25 blocking". Users with "SMTP AUTH" can then send mail from their computer via your server from anywhere they can connect, so it is very good for travelers like business people and students.

    You should also consider filtering outbound spam on your mail server, possibly with something like http://spamassassin.apache.org/.


  • What is "proxy hijacking"? What do I need to know about proxies?
    A proxy is any computer which can perform a function as a surrogate for another computer, under control of a remote operator. When an insecure proxy is used by spammers to transmit spam, that proxy computer is said to be "hijacked." The most common proxies seen in spam are the virus-installed trojans which actually transmit the spam via SMTP (they usually receive their commands on other ports). Other proxies used in spamming include web-cache and promiscuous DNS proxies, explained in this presentation in your choice of .ppt or .pdf formats. Currently, the most popular proxy protocols used by these virus-installed trojans are SOCKS4, SOCKS5 and HTTP-connect, but they may operate on any port. Increasingly, computers controlled by these virus-installed trojans -- "zombies" -- are parts of larger botnets controlled by criminal spam gangs and other Internet criminals.

    ISP admins need to be able to identify proxies, secure them and block unauthorized access to them, and remove the software if necessary. Many trojan proxies do not show up with routine port scans, either operating on obscure high-number ports or using evasive mechanisms to avoid detection. Their filenames are not consistent. It may be necessary to do complete forensics, including packet sniffing and system monitoring, to identify the malware. For many end-user systems, it is simply more effective to wipe the hard disk and reinstall a fresh system, or to pay a professional to clean the system.


    What is a "honeypot" or "proxypot"? What is a "proxy hijack source" or "C&C"?
    [hijack source/C&C;]---(SOCKS)--->[zombie PC]---(SMTP)--->[spam rcpt]
    Even more important than securing proxies is locating the proxy hijack source - the command and control (C&C;) server for a botnet composed of many proxies (tens of thousands). These C&C; servers are the actual originating source servers which send spam out through compromised proxy systems. The proxies hide the originating IP address from showing up in spam headers, of course, so you probably will not see spam reports, but special honeypots called "proxypots" identify the server motherships. Proxypots mimic a zombie PC, but unlike the zombie, they record the spammer's source IP. Spamhaus uses proxypots -- and other techniques -- to identify those C&C; or proxy hijack servers.

    To confirm those detections, as well as to monitor your own network routinely, every ISP should have the tools and skills to do traffic flow analysis. When you look at traffic flowing from a C&C; server, you will see many connections on high-number ports to many destination IP address around the 'net - thousands and thousands of connections on unusual high-number ports! The destinations are almost always compromised proxies on end-user broadband networks. Be prepared with a good network monitoring tool to check traffic flows from suspected hijack servers. Some of the tools we've heard of include Tippingpoint, Fortinet, Sandvine, Packeteer, Allot NetEnforcer, Cisco's P-cube, and flow-tools for collecting and processing netflow data from Cisco and Juniper routers. Also see Stager for sorting and presenting data collected by those tools.

    Network operators can also subscribe to a daily report of reported C&Cs; on their network. ISOTF's "Drone Armies" research team posted a summary of their work on the NANOG mailing list and invited interested admins to contact them at c2report@isotf.org. Those reports show IP, time, domain, and port.

    Spamhaus hears two common excuses given by proxy spammers to trick abuse admins. One excuse is a cover-up for that unusual traffic flow pattern, "We're doing VOIP." A closer look at the packets will disprove that. The other common exuse is "we removed the virus from the computer." Since it wasn't a virus causing the problem, that obviously doesn't stop the spam. Remember, these are dedicated servers with large lists feeding into them. And also remember, if it was a virus problem, you'd see that IP in spam headers. *wink*


    Should an ISP use the XBL to block their own users since it means they have a virus or open proxy?
    We're getting a lot of reports of spurious blocking caused by sites using the Spamhaus XBL to block authenticated access to smarthosts / outgoing email servers. The XBL is only designed to be used on incoming email, i.e. on the hosts that your MX records point to.

    If you use the same hosts for incoming email and smarthosting / outgoing email, then you should always ensure that you exempt authenticated clients from XBL checks, just as you would for dynamic/dialup blocklists.

    As your users are often on dynamic IP addresses, a user may be assigned an IP address from his provider that is in the XBL due to the virus or open proxy situation of a previous user of that IP address.

    Another way of putting this is: "Do not use the XBL to block your own users".

    Using the XBL to alert an ISP's security department when a user's IP is in the XBL is permissible and a good thing. But remember, that user may not be the one with the virus or open proxy problem.

    Note: This also applies to using the XBL to deny access to web-forums, journals or blogs.


    Backscatter from spam firewalls and anti-virus systems
    So-called "spam firewalls," software running in front of production servers to process out spam and viruses, can be a problem for other networks if they simply deflect the spam on to other mailboxes. Most spam and all mail-borne viruses use a forged Sender address, and bouncing it back to that address only results in sending unwanted and burdensome mail to innocent third parties. Either reject the SMTP connection with a 5xy message, silently discard it (your firewall identified it as spam, remember?), or file it in a quarantine area for *your* users to glean. Don't make it someone else's responsibility when they are almost certainly not involved.

    On the Barracuda Spam Firewall, the option to turn spam bouncing off can be found in the Basic Tab under Spam Scoring. Near the bottom there is a check box for "Send Bounce." This is checked by default and should be unchecked. Instructions with screenshots are shown at http://postmaster.gtcs.com/CudaFix.php. Barracuda 300 may not have this option, but the 400 and 600 versions do have it. Barracuda Networks themselves have now published a document (pdf) on how to shut of this type of bouncing.

    When using the amavisd-new content scanner, the configuration file amavisd.conf should contain:

    $final_virus_destiny      = D_DISCARD; (or D_REJECT)
    $final_banned_destiny     = D_DISCARD; (or D_REJECT)
    $final_spam_destiny       = D_DISCARD; (or D_REJECT)
    
    Avoid the D_BOUNCE setting which is the one that causes problems. Note that the D_REJECT seeting has the same effect as a D_BOUNCE in a post queue filter. Thus D_REJECT should be used only for a pre-queue filter.

    Note from the above example that the same principle applies to anti-virus notifications and bounces as well. If it's a virus, and it's after the year 2003, 99.9% of the time the return path will be bogus. DO NOT SEND IT THERE!

    Other references on spam and virus backscatter:

  • http://www.spamcop.net/fom-serve/cache/329.html#bounces
  • http://www.postfix.org/BACKSCATTER_README.html
  • http://www.mailtraq.com/851/

  • Why should I worry about reverse DNS (rDNS)?
    Reverse DNS (rDNS) consists of mapping IP addresses into hostnames. While most Internet applications do not require rDNS to work, there are several reasons why defining rDNS in your network is highly desirable:
    • publishing rDNS allows people to associate quickly and easily your IP address with your domain name, and therefore it makes easier to report abuse from your IP address space to your abuse desk
    • publishing information about dynamically assigned IPs greatly helps other networks to distinguish the nature of different mail sources in your network (mail servers vs infected end user machines), and to block SMTP connections from dynamic addresses (if they wish to do so) without guessing and risking to inadvertently block mail servers
    • publishing proper rDNS for statically assigned IPs - and in particular for those corresponding to proper mail servers - greatly reduces the likelihood that other networks will block those servers by mistake, thinking that their IP belongs to residential dynamic space
    • moreover, some networks are refusing mail from IP addresses without rDNS defined
    • on the client side, there are security benefits in running applications such as ssh from an IP with rDNS assigned

    How do I get rDNS working?
    You need to get a delegation of the reverse DNS zone, and then configure the zone. If your network is, say, 1.2.0.0/16, "getting a delegation" means having a NS record for 2.1.in-addr.arpa pointing to your nameservers, while "configuring the zone" means inserting the right information in the corresponding zone file in your nameservers.

    Getting a delegation

    You get a rDNS delegation from the same entity that gave you the IP addresses: it may be the ISP you are taking connectivity from, or the regional Internet registry of your area.

    Regional Internet Registries (RIR) have formal procedures for assigning rDNS delegations: follow the links pertinent to your registry.

    Configure the zone

    For general information about defining a reverse zone in your nameservers, see for instance the APNIC guide or the RIPE pages linked above.

    Note that you do not need to insert all the individual records by hand. If you are using Bind, once you have defined a naming convention for a portion of your space you can use the powerful $GENERATE directive (described in the Bind 9 manual) to define several records with a single line. For instance, you can write in the 2.1.in-addr.arpa zone file:

       $ORIGIN 2.1.in-addr.arpa.
       $GENERATE 1-254 $.3 PTR adsl-1-2-3-$.dynamic.yourdomain.net.
    
    which is equivalent to 254 lines
       1.3.2.1.in-addr.arpa.   PTR adsl-1-2-3-1.dynamic.yourdomain.net.
       ...
       254.3.2.1.in-addr.arpa. PTR adsl-1-2-3-254.dynamic.yourdomain.net.
    

    Do not forget to check that matching forward A records are defined in the zone of yourdomain.net. This is very important because it "validates" the rDNS information. You can define them with another $GENERATE directive, like

       $ORIGIN dynamic.yourdomain.net.
       $GENERATE 1-254 adsl-1-2-3-$ A 1.2.3.$
    
    which is equivalent to 254 lines
       adsl-1-2-3-1.dynamic.yourdomain.net.   A 1.2.3.1
       ...
       adsl-1-2-3-254.dynamic.yourdomain.net. A 1.2.3.254
    

    What rDNS naming convention should I use?
    You will facilitate life to other people by using a fixed string like dynamic or dialup as a subdomain immediately below your domain, putting the geographical information (if it applies to your case) at the next level, andthe most variable information (like the last octet of the IP) at the outer level. Try to use dots as separators rather than dashes or other symbols, so as to create subdomains, and try to put the variable information on the leftmost part of the name. For instance,
       123.adsl7.timbuktu.dynamic.yourdomain.net
    
    is a good naming scheme.

    Clearly the same information could be made available with another scheme like dadsl7-123-tktu.yourdomain.net, but other people would have to define complex regular expressions to parse that, wasting resources and increasing the likelihood of making mistakes.

    We also recommend to use similar conventions to identify static IPs and business connections as clearly as possible. For instance, you can use something like

       245.sdsl.timbuktu.business.static.yourdomain.net .
    
    Such a scheme helps your business customers to maintain a good SMTP connectivity even when their IP neighbors are infected and send spam.

    Got any info on PHP Nuke exploits?
    PHP-Nuke Script Insertion Vulnerabilities

    Note that the webmail module has been removed from the PHP-Nuke distribution due to its poor security since version 7.2 (march 2004). Using a more recent distribution of PHP-Nuke is of no help if the webmail module has been retained from a previous release, or has been downloaded later from some other site as an "add-on".

    Also note that, according to user reports, it appears to be insufficient to disable the webmail feature to prevent the scammers from using it. You must delete the webmail module, causing removal of all the related files from the server.


    What's this ARP (Address Resolution Protocol) daemon spoofing?
    http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html

    It's a tricky way for a spammer to make their spam appear to come from a different IP than their dedicated server, but still on the same VLAN subnet.

    To avoid the problem, design your VLAN so that:
    - customers can't snoop on each other, even at broadcast level such as arp traffic;
    - no customer can send out packets with any source IP other than their assigned one;
    - no customer can generate ARP traffic for any IPs other than their own.

    As for identifying what server it really is, can you put a port monitor on the switch port of your router and sniff its packets? You should be able to see the MAC address of anything returned from those IP addresses, even if they were injecting forged packets from somewhere else on the Internet. And you should be able to see the gratuitous ARPs.

    This technique is in use in the wild. If you detect this on your network, Spamhaus would very much appreciate any details you can provide, including connection information for the spammer's "home base."


    What is "fast flux" hosting?
    Fast flux domain hosting involves the use of botnet zombie drones on broadband IPs infected to act as reverse proxies for the spammer's website or nameservers. The spamvertised domain, or its nameserver, is pointed at a rapidly changing series of zombie IPs (hence the name) with very short "TTL" values -- usually less than five minutes (300s). There are typically four or five "A" records to distribute the load and increase the odds of the website staying up. Their proxy service hides the IP location of the spammer's dedicated servers. As the very action of hijacking computers is illegal in most jurisdictions, such fast flux hosting is only used for further criminal activities such as phishing and child pornography. Because the criminals know they could be identified if they used valid "whois" data, they always use bogus data, so registrars can confidently HOLD (suspend) the domain based on ICANN 3.7.7.2.

  • Here's an example of the DNS of a child porn fast flux domain:
    $ dig @NS2.WESTNS.COM wildcard.malaga-53.com a
    
    ; <<>> DiG 9.2.4 <<>> @NS2.WESTNS.COM wildcard.malaga-53.com a
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13728
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;wildcard.malaga-53.com.                IN      A
    
    ;; ANSWER SECTION:
    wildcard.malaga-53.com. 180     IN      A       68.126.240.182
    wildcard.malaga-53.com. 180     IN      A       70.228.170.6
    wildcard.malaga-53.com. 180     IN      A       68.74.207.77
    wildcard.malaga-53.com. 180     IN      A       70.253.85.166
    wildcard.malaga-53.com. 180     IN      A       67.37.184.67
    
    ;; Query time: 145 msec
    ;; SERVER: 67.190.128.40#53(67.190.128.40)
    ;; WHEN: Sun Sep  3 17:xx:xx 2006
    ;; MSG SIZE  rcvd: 120
  • Here are the hostnames of those A-record addresses. Note that they are all dynamic broadband names typical of botnet zombies:
    [67.37.184.67] adsl-67-37-184-67.dsl.chcgil.ameritech.net.
    [70.228.170.6] ppp-70-228-170-6.dsl.emhril.ameritech.net.
    [68.74.207.77] adsl-68-74-207-77.dsl.milwwi.ameritech.net.
                   adsl-68-74-207-77.dsl.milwwi.sbcglobal.net.
    [70.253.85.166] ppp-70-253-85-166.dsl.austtx.swbell.net.
    [68.126.240.182] ppp-68-126-240-182.dsl.irvnca.pacbell.net.
    [67.190.128.40] c-67-190-128-40.hsd1.co.comcast.net.
  • And finally, here are the A-records for the NS hosts, again on botnet zombies:
    $ dig @ns2.WESTNS.COM ns2.westns.com a
    
    ; <<>> DiG 9.2.4 <<>> @ns2.WESTNS.COM ns2.westns.com a
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53259
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
    
    ;; QUESTION SECTION:
    ;ns2.westns.com.                        IN      A
    
    ;; ANSWER SECTION:
    ns2.westns.com.         180     IN      A       70.115.193.8
    
    ;; AUTHORITY SECTION:
    westns.com.             180     IN      NS      ns2.westns.com.
    westns.com.             180     IN      NS      ns4.westns.com.
    westns.com.             180     IN      NS      ns3.westns.com.
    westns.com.             180     IN      NS      ns5.westns.com.
    westns.com.             180     IN      NS      ns1.westns.com.
    
    ;; ADDITIONAL SECTION:
    ns4.westns.com.         180     IN      A       24.98.2.58
    ns3.westns.com.         180     IN      A       67.184.161.182
    ns5.westns.com.         180     IN      A       24.163.92.147
    ns1.westns.com.         180     IN      A       70.245.189.179
    
    ;; Query time: 2359 msec
    ;; SERVER: 67.190.128.40#53(67.190.128.40)
    ;; WHEN: Sun Sep  3 18:xx:xx 2006
    ;; MSG SIZE  rcvd: 198

  • Info on the Windows MetaFile exploit (WMF)
    Info on the Windows MetaFile exploit (WMF) has been moved here.

    My customer says it's not them; is that true or an excuse?
    Some of the excuses commonly used by spammers:

    - customer of a customer or reseller;
    - affiliates, fake and real;
    - it's opt-in (the list they bought said so!);
    - it's Double Opt In! We have IPs! (may come from "web bugs" in spam)
    - moving servers around to new IPs or "morphing";
    - using lots of domains, often with anonymized "whois";
    - turning servers back on as soon as the heat is off;
    - spam is sent from a different network than their web hosting;
    - using "VoIP" as an excuse to cover up proxy hijacking;
    - insisting the proxy hijack software was installed by a virus (it's not; it is large, dedicated software installed intentionally by a server administrator to spam).

    Other commonly seen tricks:

    - redirector URLs on throwaway pages land at their "bulletproof" site;
    - VPN tunnels and port forwarding to hide from port-sniffing (use traffic flow analysis);
    - asymetric routing via dynamic pools;
    - scripts installed on the same server as an MTA to send mail without leaving log tracks;
    - firewalling the host's corporate IPs so the host can't see the spammer's website.

    Steps to keeping your network free of spammers:

    1. Review your new customers before you sell them accounts. Treat unusual requests with suspicions. If an offer sounds too good to be true, it probably is.

    2. Use "reverse DNS" on your IPs which points to your domain.

    3. Be sure to read "abuse@your domain" every day, and have your upstream provide you with spam reports sent to them about your IPs.

    4. Establish "feedback loops" with SpamCop, AOL, The Network Abuse Clearinghouse (abuse.net), and other networks.

    5. When spam is reported, take prompt action to stop it.

    6. Do not trust spammers; they are inherently dishonorable people.


    What is the right way to send bulk e-mail?
    This is intended only as a basic outline of what it takes to manage a legitimate bulk e-mail list. Seek expert advice from appropriate companies and consultants for a more complete understanding of the complicated issues of legitimate bulk e-mail. Remember, all bulk e-mail must be "opt in", otherwise it is unsolicited. And Unsolicited Bulk E-mail (UBE) is spam.

    1. Address acquisition - Make sure it's Opt In! If the recipient didn't ask for it in the first place, the rest of the list management processes are irrelevant. While various transactions and business relationships can infer permission, if there's any doubt, or for any on-going bulk e-mail relationship, closed-loop Confirmed Opt In (COI) is the gold standard for verifying permission, in use since about 1997. Some examples of software which use COI include Majordomo-2, EZMLM, Mailman, and Lyris.

    For more on COI, see:
    - http://www.spamhaus.org/mailinglists.html
    - http://nct.digitalriver.com/ecm/doihowto/
    - http://www.spamhaus.org/permissionpass.html

    2. Truth in advertising - State your policies and the nature of the bulk e-mail at the point of subscription. Tell the subscriber what to expect: how often, how big, what kind, what topics and content, etc. Don't hide information about the subscription on remote pages, behind hyperlinks, or buried in jargon, legalese, and obfuscation.

    3. Identify yourself, or at least your company or organization. Use properly registered domains with working mail and web addresses. Have a website at those domains which properly identifies your company. Don't hide behind ever-changing mazes of domains. Anonymized "whois" records just shout "hey, I'm trying to hide something!" Do you buy your electronics off the back of unmarked trucks in an alley? Make bank withdrawals while wearing a ski mask?

    4. Maintenance - Keep your list current! Remove unsubscription requests and bounces promptly. Mail the list at regular intervals. Unmailed lists provoke high complaint rates when they reactivate, even from truly opt-in addresses. Addresses "churn" over time, that is, they are abandoned or re-used. For most commercial lists, mail at least once per week and remove any address with three sequential bounces, or with sequential bounces for more than two weeks.

    5. Bounce processing - Respect what the recipient's server tells you. SMTP "5xy" codes mean "NO!" Bouncing off the filters but showing up in the logs, or resuming spamming after filter rules come down, is a sure-fire way to really annoy server operators and mailbox owners alike. Addresses being converted to spamtraps will typically reject (5xy) all deliveries for about six months...you sure don't want those on your list!

    6. Unsubscription - Must work! Promptly. And for all the bulk mail you're sending to that address. It must work via e-mail (include correct info in headers) and many subscribers also appreciate a web link included in message body. Sign up for feedback loops (see top of this FAQ page), and consider that abuse reports may indicate more serious problems than can be fixed by simply unsubscribing the reporting address. Some jurisdictions also require snail-mail unsubscribe processing. Basically, if someone wants off your list, help them with their request no matter how they ask.

    7. Concurrency - Respect the receiving server's SMTP dialogue. If it says pipelining allowed, give it what it wants. If it accepts a bit slowly, throttle back your server so as not to flood smaller sites. Opening up lots of threads to a slow server is an excellent way to get tarpitted and blocked.

    8. Seek expert advice! There are highly qualified deliverability consultants, and some who aren't so qualified...buyer beware. Ask your ISP for advice. Consider a reputable E-mail Service Provider (ESP). If any deliverability consultant is not aware of the terms and problems in this very brief outline -- and more! -- or if they promise you that they can get you "whitelisted" anywhere but their own network, well, do you want to buy a bridge? <wink>


    Spamhaus Block List      Exploits Block List      Register Of Known Spam Operations