|How do I turn on SMTP Authentication?
SMTP Authentication is required when sending email out via most major ISP mail servers and most corporate mail servers. It is simply a username/password system which permits authenticated e-mail senders, just like most other computer accounts require authentication.
If you do not have SMTP Authentication turned on in your email software (Outlook, Entourage, Eudora, Apple Mail, etc.) you run the risk that the mail server will not recognize that you are a legitimate customer.
If the mail server is using spam filters (such as Spamhaus' PBL or XBL) it may refuse to take your email, because it thinks you are a stranger and your dynamic IP address is probably on Spamhaus' PBL list of dynamic IP addresses which mail servers should not accept mail from unless the sender is authorized to use that mail server.
To fix this, you need to turn on "SMTP Authentication", here's how:
In Microsoft Outlook & Outlook Express:
Start Outlook 2000 or Outlook Express. From the menu, select Tools, then Accounts. Click once on the appropriate account from the Mail tab. Select Properties. From the account properties dialog box, choose the Servers tab. Put a check in the box for "My server requires authentication". Click on the "Settings" button. In the 'Outgoing Mail Server' dialog box, make sure "Use same settings as my incoming mail server" is selected. Press "OK". Back at the "Properties", click "Apply", then "OK". Click "OK" to close out of all dialog boxes.
Open Eudora, pull down the Tools menu and select "Options..." to display the Options window. Select the "Getting Started" category on the left-hand side. Select the "Allow authentication" checkbox and click "OK".
In Apple Mail:
Open Apple Mail. Click on the "Mail" menu in the top menubar. Click on Preferences. Click on Accounts. Click on the account that you want to modify. Click on Account Information. Click on the "Outgoing Mail Server (SMTP)" pulldown list. Select "Edit SMTP Server List..." from the bottom of the list. Click on "Advanced". Make sure Authentication is set to "Password" or "MD5 Challenge-Response" (this depends on your ISPs instructions). Make sure your User Name is correct. Make sure your Password is correct (must be exactly as your ISP gave it to you, be ware of uppercase or lowercase). Your username and email password are normally the same ones you use to retreive your POP or IMAP email. Click on OK. Close the Preferences window by clicking on the X in the upper left hand corner of the window.
Tools >> Servers and Accounts >> Outbound Email Server
Connection: TLS if available
Login Method: Username and password
Advanced Settings: Port: 587
Wikipedia and Google have lots more information about "smarthosts" and "SMTP AUTH".
|Is there a way to report spam to Spamhaus?
No. Spamhaus DNSBLs are not based on spam reported to us (we have our own systems for detecting and identifying spam, proxies, etc.). Please DO NOT forward your spam to any Spamhaus.org address, we can not do anything with spam you send us, except bin it ourselves (we block people who do forward spam to us from connecting to our mail servers again).
The only public DNSBL system you can currently report spam to is SpamCop.
You can also report your spam (by forwarding it complete with full headers) to the U.S. government's spam-evidence database run by the FTC at: firstname.lastname@example.org
Many ISPs and webmail providers have spam reporting addresses for spam received by their users. Often it is as simple as clicking a "This Is Spam" button. Those reports help the ISP build their own spam filters, and sometimes are aggregated for reports to the spammer's host network via feedback loops.
Some places where you can learn about more about spam and how to report it include:
http://spam.abuse.net/ The Great Granddaddy of all anti-spam sites
http://www.abuse.net/ The Network Abuse Clearinghouse (abuse addresses)
http://spamcop.net/fom-serve/cache/19.html (how to view full headers)
http://www.stopspam.org/email/headers.html (archived) header-reading tutorial
http://www.pop-cram-spam.net/SMTP.htm (archived) basics of Simple Mail Transport Protocol (SMTP, or e-mail)
Also see our Online Scams FAQ for other groups fighting against the scams found in spam.
|I am being blocked, but my IP/domain is not listed on Spamhaus
Our IP Address Lookup page (http://www.spamhaus.org/lookup) shows IPs that are currently listed in one or more of Spamhaus' databases. If the IP address you are checking is not found in any of our databases, but you are receiving email reject (bounce) messages from various networks saying it is listed by Spamhaus, then these are the possible causes:
- It is possible that the IP address was on one of our databases but has been removed recently. If an IP address has been removed recently, then it is possible that local DNS servers around the internet which serve Spamhaus spam filter information to mail servers have not yet updated their data. In this case, wait 1-2 hours and the blocking should clear by itself.
- If the IP Address you are using is shared with other users (such as a dynamic ADSL line), It is also worth checking to see if your IP address was recently removed by someone else from the CBL database (CBL data is imported into the Spamhaus XBL) using the CBL lookup form at: http://cbl.abuseat.org/lookup.cgi
- If you have recently removed your IP Address from a Spamhaus database such as XBL (CBL) or PBL, but still many hours later (or even days later) are experiencing email rejections from networks saying that your IP Address is "listed by Spamhaus", it is probable that those networks have not yet updated their local spam filter data. Most networks that use Spamhaus DNSBLs automatically update their spam filter data every half-hour, however some networks prefer to update every few hours only (and some only update once or twice a day). Spamhaus has no control over when networks update their data (there is nothing Spamhaus can do to force a 3rd party network to update its spam filter data faster). In this case we advise you to contact those networks rejecting your email and tell them that their mail server is incorrectly saying the IP is listed at Spamhaus when it is not.
- If you are experiencing email rejections by only one network in particular, then it is likely there is a local problem at that network. We advise you to contact that network, tell them that their mail server is incorrectly saying the IP is listed at Spamhaus when it is not, and ask them to whitelist your IP Address.
|What do "/32" or "/24" mean after an IP address? (CIDR)
The number after the slash refers to the significant digit in a 32-bit byte. So, "/1" would refer to the most significant digit (the one on the left) and "/32" refers to the least significant digit (the one on the right).
Classless Internet Domain Routing (CIDR) replaced the traditional "A-Class", "B-Class", and "C-Class" networks with notation such as:
A-Class | 22.214.171.124/8 == 126.96.36.199 - 188.8.131.52 (1,703,936 IPs)
B-Class | 184.108.40.206/16 == 220.127.116.11 - 18.104.22.168 (65,536 IPs)
C-Class | 22.214.171.124/24 == 126.96.36.199 - 188.8.131.52 (256 IPs)
Think about binary or "base-2" numbers, and positional notation or place-value notation. The "/n" part refers to the significant bit in a 32-bit byte which defines the subnet. So, a "/32" is the thirty-second most significant bit, or a single IP. A "/31" is twice that, a "/30" is twice a "/31", and a "/29" is 8 contiguous IP addresses. CIDR subnets fall on natural boundaries which are mathematical exponents of 2, so they can only start on certain IP numbers. For example, a CIDR subnet cannot be 184.108.40.206/27 because 10 is not an exponential value of 2.
Here's another way to think about it. Looking at the four binary eight-bit bytes (octets) of an IP address, count the bits, starting from the left, until you find the significant bit (1) designating the address range:
^^^^^^^^ ^ ^ ^
12345678 16 24 32
This is a very brief explanation, not intended for a complete understanding of the math, nomenclature, or history of IP allocation. For more information, try these pages:
|Can registrars suspend domains for spam and abuse?
Yes! They need an anti-spam Acceptable Use Policy (AUP) which they can enforce. And most do. Spammers very often use false information in domain registrations. Registrars can also suspend domains for bad "whois" information:
"Applicable Provisions of the ICANN Registrar Accreditation Agreement"
220.127.116.11 A Registered Name Holder's willful provision of
inaccurate or unreliable information, its willful
failure promptly to update information provided to
Registrar, OR its failure to respond for over fifteen
calendar days to inquiries by Registrar concerning the
accuracy of contact details associated with the
Registered Name Holder's registration shall constitute
a material breach of the Registered Name Holder-
registrar contract and be a basis for cancellation of
the Registered Name registration.
Read carefully - it's an "OR" clause! (emphasis ours) The registrant's "willful provision of inaccurate information" alone is sufficient to "constitute a material breach" of the registration contract and therefore is a basis for immediate cancellation of the domain. Only non-willful errors qualify for the 15 day grace period.
That same page goes on to assign the responsibility of anonymizing registrars (or resellers) over abuses committed in their name (as it is their name on the registration, unless they decloak the anonymity):
18.104.22.168 Any Registered Name Holder that intends to license use
of a domain name to a third party is nonetheless the
Registered Name Holder of record and is responsible for
providing its own full contact information and for
providing and updating accurate technical and
administrative contact information adequate to
facilitate timely resolution of any problems that arise
in connection with the Registered Name. A Registered
Name Holder licensing use of a Registered Name according
to this provision shall accept liability for harm caused
by wrongful use of the Registered Name, unless it
promptly discloses the identity of the licensee to a
party providing the Registered Name Holder reasonable
evidence of actionable harm.
To suspend a domain, registrars must first put it on "REGISTRAR-HOLD", and at the same time change the listed namesevers to ones that return no, or a null, result. To further lock down a spammer's domain, a registrar can update the domain's email contact addresses to some catch-all mailbox of their own (e.g.: email@example.com).
May 2009: Registrars, please point glue records for suspended domains to 22.214.171.124. ISC.ORG is the owner of that IP address and has specifically assigned it as the correct address for that purpose.
Oct 2009: Considerable confusion as well as trespass on other network's addresses would be avoided, and identification of suspended domains would be simpler, if everyone used 126.96.36.199 as a standard response for suspended glue records. Presently Spamhaus is aware of the following "bad domain" return codes published in public DNS: 0.0.0.0, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11.
Some example of the namesever methods are:
Registrars may suspend for reasons other than spam and abuse, for example bogus information, or other reasons, and may use other nameserver domains for that:
Organisation Name.... INWW Cancelled Domains
Name Server.......... adenine.melbourneit.com.au
Name Server.......... enterprise.melbourneit.com.au
Also, if a spammer has dozens, hundreds, or in some cases thousands of domains registered, terminating the spammer's entire account can have a profound effect at reducing spam volume and spammer's incentives.
The Spamhaus Project strongly encourages registrars to assist in the fight against spam and network abuse.
|Is my e-mail address listed in SBL?
"No" is the short answer. Spamhaus lists (SBL, XBL, PBL, DBL) can not list e-mail addresses! It is physically impossible for our lists to contain e-mail addresses. Spamhaus lists only include IP addresses or domains, not e-mail addresses.
An IP address is the numeric address of a machine connected to the Internet. IPs are usually written in a dotted quad format like this: 18.104.22.168. A single IP can host no domains, one domain, or many domains, and it can host no servers, one server, or many servers or other devices. Similarly, a domain or hostname can point to any number of IP addresses. There is not a 1:1 relationship between IPs and domains!
A domain name (for example "spamhaus.org") is associated with one or more IP addresses via the fundamental part of the Internet called the Domain Name System (DNS). The owner of a domain name can point the DNS for their domain to any IP they choose...hopefully one they have permission to use!
E-mail, with its addresses in the form of "user@domain", relies on the DNS system for delivery of messages. Messages are delivered to the MX record of the recipient's domain. However, the sender can send e-mail using their own address from many servers, in fact from nearly any server where they are authorized, for example by using SMTP AUTH. So, if you are sending legitimate mail and you find your mail rejected due to the IP address you are sending from, try sending your mail out via a different server on a different IP address. Your ISP or IT service can help you configure your mail program to make that connection.
You can check whether an IP address or domain is in any Spamhaus list with our lookup form.
|Is my IP address listed in SBL?
This lookup form will tell you if an IP is in any of our DNSBL zones (lists). That data is the most current available but the data in our public mirrors should be accurate within about 15 minutes (caching and update time). Links from that lookup will show you which of our zones lists the IP (SBL, XBL or PBL) and how to have it removed.
Sometimes people see a rejected e-mail but don't see their IP in a Spamhaus list. That could be for several reasons. One is that the listing may have expired or otherwise been removed. Another is that there are many other reasons that e-mail is rejected, including many other DNSBL lists, public and private. Well-configured servers will give the sender accurate information about why a message was rejected, but there are some less well configured servers that simply say any rejection was due to Spamhaus (or sometimes some other reason or no reason at all).
The best person to ask is the administrator of your mail server, followed by the administrator of the server that rejected your mail. Be prepared to show them the actual rejection message from the rejecting server ("Delivery Status Notification", sometimes called a "bounce").
|How to secure your SSH daemon (sshd)
We at Spamhaus come across compromised (web)servers frequently, which turned out to be hijacked by spammers or other cybercriminals to host spammer sites, malware distribution sites or even botnet controllers. Many of these compromised servers have been hacked using SSH brute forcing.
With the SSH bruteforcing method, an attacker tries to guess (brute force) the password by using the "try and error" principle. If the victim system is using a weak password the chance is high than an attack can result in a positive match, after which the attacker is able to get (root) access to the system.
Fortunately there are several technical measures that can help to mitigate SSH bruteforce attempts.
Change the port SSHd is listening on
One of the most effective ways to prevent your system getting hacked by brute forcing the SSH password, is simply changing the port where the SSH daemon (SSHd) is listening on to a non-standard port. SSHd usually listens on 22 TCP, which makes it attractive for attackers. You should change it to something else eg. port 2233 or 2244. You can do this by changing the configuration file of SSHd which usually resides in
/etc/ssh/sshd_config. Please consider that there are two files: sshd_config and ssh_config. Make sure that you edit sshd_config. In the config file, somewhere at the top you will find an option called
Port which should have the value
22. All you need to do is change this option to a different port (eg. 2233) and restart the SSH daemon using the command
sudo /etc/init.d/ssh restart. SSHd should now listen on the port you have just specified in the configuration.
Fail2ban is a open source tool that looks for failed SSH login attempts in the SSH logs and bans the attacking IP address for a specific time period using iptables or nullroute. The installation and configuration of Fail2Ban is pretty simple. If you are using Ubuntu or Debian you can simply install the Fail2Ban packet from the repository by using apt-get:
sudo apt-get install fail2ban
The configuration file of Fail2Ban is usually located in
/etc/fail2ban/jail.conf. There are various options you can configure, for example the email address where notifications should be sent to or the default ban action (usually iptables-multiport which means that the attacking IP address will be blocked on all ports using iptables). Per default, Fail2Ban monitors the SSH log located at
/var/log/auth.log for failed login attempts. If Fail2Ban is configured correctly, you should see something like this in your Fail2Ban configuration file:
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
With the option
enabled you can define if the rule/filter is active or not (true or false). The option
filter defines which filter configuration this rule will use. The filter configuration files are located in
/etc/fail2ban/filter.d/. Basically what this rule/filter does is monitoring the SSH log
auth.log and bans the attacking IP address after 6 failed login attempts for 600 seconds (see option
bantime) using iptables (see option
If you want to monitor the activities of Fail2Ban you might wan to check out the logfile that is being produced by Fail2Ban: it is usually located in
If you are interested in Fail2Ban you can find more information on the Fail2Ban project website:
Another tool to prevent that attackers gain access to your server using brute forced SSH credentials is running DenyHosts on your server. DenyHosts is open source project that maintains a database of IP addresses that are know to be a source of SSH attacks. The tool works similar as fail2ban by monitoring the sshd log for failed login attempts. Once an SSH attack has been detected, DenyHosts will block the offending IP address by adding it to /etc/hosts.deny. If you are running Ubuntu or Debian you can simply install DenyHosts using the following command:
sudo apt-get install denyhosts
This command will install denyhosts on your linux/unix server. Usually, the configuration for DenyHosts comes out of the box, but if you want to check the configuration you can find the config file in
/etc/denyhosts.conf. Ensure that the path to the SSH log (
SECURE_LOG) is set correctly and that DenyHosts blocks login attempts from the offending host for sshd (
More information about DenyHosts can be found here:
|Someone's spamming with my return address, will you blacklist me?
The From field in most spam is forged and meaningless. Some spamware uses addresses from the spammer's "To" list to also fill in the "From" address. Usually that is just a random selection, but occasionally spammers "bounce bomb" a particular recipient with thousands of forged return-paths forged in the victim's name, either out of revenge or simply because their ratware is shoddy and the random rotation fails.
Such an attack is sometimes called a Joe job, but a Joe job attack falsely implicates the victim as being the beneficiary of the spam message. A forged From attack is more similar to what happened to Flowers.com and resulted in civil judgement against the spammer (, ). Both those attacks occurred in 1997. Abuse desks and anti-spammers are well aware of such things.
Either way, Spamhaus is careful to avoid such innocent victims of spammers. We don't list for forged From and we don't list Joe Job victims.