From: Rich Kulawiec (rsk@gsp.org)
Date: Sat Aug 09 2003 - 15:46:36 EDT
[ This isn't really a summary, because I didn't ask a question. However,
given the increasing amount of traffic focused on this question, or
ones very much like it, I decided to adapt something I wrote elsewhere
and present it here in the hopes that it would help some people out.
I've been doing some anti-spam consulting and trying to persuade people
rather that rather ihan buying expensive software, most of them can
"roll their own" and get what they need much more cheaply -- with
the added bonus that it's highly customizable. And "customizable" is
important here, because spammers keep changing strategies and tactics:
so if that nifty-looking does-it-all solution that cost you a fortune
doesn't adapt as fast as needs dictate, try some of this.
But please note: this is not The Best Approach. It's only One Approach.
And I've left out significant detail, because it's pretty long as it is.
And I probably made some mistakes on top of that. My goal here isn't to
give you every last piece of information, but to give you a general
outline of can be done and point you to places where more information
can be found. You need to RTFM, RTFFAQ, and RTF web sites.
Some of you may have no need of this: consider yourselves lucky.
As of July 2003, 90% of the incoming SMTP traffic here was spam, and
the percentage continues to increase. ---Rsk ]
How to set up a simple anti-spam system using
open-source software and freely-available data
or
A simple anti-spam methodology, from A to Z
Here's how to stop most spam from reaching your users/systems without
spending a lot of money or time. These are all production-tested
techniques that I and other folks are using on mail systems which
handle everything from single users to millions of users. They all
use free, open-source software, and freely-available public sources
of information. (Though they can be used with non-free, closed-source
software as well in many cases.)
A. [highly recommended] Use an open-source MTA (e.g. sendmail,
postfix, exim) on an open-source OS (I highly recommend OpenBSD,
http://www.openbsd.org, due to its strong security; FreeBSD and NetBSD
and many Linux variants also work nicely). Properly configured, this
will not only help you stop spam from coming in, it will go a long toward
preventing you from ever being (ab)used to SEND spam. See (V).
[ And since this is Sun-Managers, I'll point out that this all
works just fine on Solaris too. Solaris 9 ships with a nice
close-to-new version of sendmail: if you're running an older version,
it's worth getting sendmail 8.12.9 and building from source. Or if
you want to run postfix, etc., you can go that direction. ]
B. [highly recommended] If you have some kind of clunky internal mail
system that you're stuck with, use A as the gateway to it. Create two
(or more) equivalent A's on two (or more) networks to address questions
of performance and reliability.
C. [optional] Install a DNS server on A (which you might want to restrict
to only answering queries from A) with a big cache. I recommend BIND 9; see:
http://www.isc.org/products/BIND/bind9.html
This can really help with performance, especially if you use
DNSBLs -- see below.
D. [optional] Go get a list of known spammer domains from any of:
http://www.spamhaus.org/rokso
http://blackholes.easynet.nl
or other sources and install it in a local deny list. (In sendmail
terms, this is /etc/mail/access, and usage is covered in cf/README in
the source tree. Be sure to RTFM on "makemap", in particular on the use
of the "-c" flag, if you use a large list of domains.) Other MTAs have
equivalent features.
Experience here indicates that this will block about 50% of the incoming
spam. So even if you stop here, that means that a couple of old Sparc
boxes or or PCs with a free OS and a free MTA can cut your spam in HALF.
(You'd be surprised how much mail such a box can handle, IF properly
configured and IF relieved of the burden of delivering spam.)
E. [optional] Instead of using one of those lists as-is, compare it to
your incoming spam/mail logs. Not everyone gets the same spam traffic,
so you could list only the domains that are actually spamming you.
(Which means you can augment the list as more spam arrives from new
sources.) Note that listing spammer domains doesn't work if they forge
the sender address or the originating MTA greeting, which many of them do:
that's why there are other techniques. Keep reading.
Now for the DNSBLs.
DNSBLs use the mechanisms of DNS to propagate information and enable
mail systems to either permit/reject mail from certain IP addresses.
Experience here is that using such DNSBLs kills about 80-90% of the
spam that makes it past step E. All modern MTAs are able to use DNSBLs
easily, by adding a line or two to their configuration files. If you're
going to do large numbers of DNS queries, you should arrange with the
DNSBL maintainers to do zone transfers (and perhaps provide a secondary
as a service to the community).
You should read the web site/FAQ of every DNSBL that you are thinking
about using BEFORE you deploy it, and make sure you understand exactly
what its policies are, and are not.
You can use DNSBLs to (a) block mail (b) tag mail (c) quarantine mail.
Which is best for you...depends. I've opted for (a) for now.
F. [optional but highly recommended] Use a DNSBL that lists organized
spam gangs. The Spamhaus ROKSO project tracks spammers who have *already*
been kicked at least off three ISPs: there's no reason for anybody on
the planet to accept another piece of mail from these career spammers,
ever. (Although there is plenty of reason to ask the ISPs currently
giving them connectivity how they could possibly be so stupid/greedy to
permit these spammers to remain on their networks for another minute.)
Spamhaus provides this DNSBL:
sbl.spamhaus.org http://www.spamhaus.org/sbl/
and other folks provide mirrors of it in various places around the world;
please use a mirror if possible. (That goes for all DNSBLs.) For most
folks, this step will block a LOT of their incoming spam.
G. [optional but highly recommended] Use several DNSBLs which specialize
in open relays and open proxies. Open relays are systems which will relay
SMTP traffic for anyone. This means that they are broken and should be
shut down until they're repaired; however, that often doesn't happen.
Open proxies are similar systems: they're either hijackable or have
already been hijacked by spammers, and turned into injection points
for spam.
Spammers actively scan for both at ferocious rates: any system found to
be either WILL be used to send spam, probably sooner rather than later.
[ We are logging incredible amounts of spam from open proxies on consumer
broadband: Comcast, Verizon, SWBell, etc. Numerous complaints with full
logs have resulted in no (visible) action and no response. ]
Here are the DNSBLs that we use for this purpose: note that these
are just *some* of the choices, and there are many others:
proxies.blackholes.easynet.nl http://proxies.blackholes.easynet.nl/errors.html
proxies.relays.monkeys.com http://www.monkeys.com/upl/
list.dsbl.org http://dsbl.org/
dnsbl.njabl.org http://njabl.org/
relays.ordb.org http://ordb.org/
opm.blitzed.org http://opm.blitzed.org/
spamguard.leadmon.net http://www.leadmon.net/spamguard/
http.dnsbl.sorbs.net http://http.dnsbl.sorbs.net/
smtp.dnsbl.sorbs.net http://smtp.dnsbl.sorbs.net/
socks.dnsbl.sorbs.net http://socks.dnsbl.sorbs.net/
Note that the open relay/proxy problem is enormous. Here's part of the
latest published statistics from just the SORBS folks (current as of
August 2, 2003):
Unique HTTP based proxy server ports open: 491736
Unique SOCKS based proxy server ports open: 504956
Unique miscellaneous (ftp/telnet etc) proxy server ports open: 94428
Total Open Proxy Server ports: 1091120
Total Blocked Ports/Addresses: 1095402
That's part of the reason for using several of these: what's missed by
one may be handled by another.
H. [optional] Use a DNSBL that lists hijacked network blocks. Some
spammers have started taking advantage of dot-com flameouts and the
resulting abandoned network blocks by forging documents that claim they
own them and convincing ISPs to route traffic for them. You might also
want to consider null-routing all IP traffic to/from such blocks.
zombie.dnsbl.sorbs.net http://zombie.dnsbl.sorbs.net/
I. [optional] Use a DNSBL that lists dynamic/dialup IP space. (Make sure
you know how to exempt your own users if you do this. For that matter,
make sure you know how to do that if using *any* DNSBL.) We use:
dialups.visi.com http://www.pan-am.ca/pdl/
Anyone in dynamic IP space should be using their own ISP's mail servers
(presumably on static IPs).
J. [optional] Consider using DNSBLs which list particular networks
or geographic regions. Dozens of these can be found at
Which ones work for you will depend on who you expect to get mail from:
it wouldn't do to add a network where most of your correspondents happen
to be! However, if a particular network or region sends you 100% spam,
you might want to use one of these.
For example, in response to:
we began using this DNSBL:
burst.blackholes.us http://burst.blackholes.us/
on a permanent basis. We also happen to be using (among others):
doubleclick.blackholes.us http://doubleclick.blackholes.us/
valuenet.blackholes.us http://valuenet.blackholes.us/
because we do not wish to receive any SMTP traffic from those networks.
K. [optional] Use a DNSBL which pro-actively lists network blocks
that are persistent sources of spam and/or which provide support
services to spammers: hosting their web sites, providing DNS for
them, giving them connectivity, etc., and whose operators (for
whatever resason) do not act quickly and efficiently to remove
their spammers when informed of their presence.
One such DNSBL is SPEWS, the Spam Protection Early Warning System.
The SPEWS FAQ covers this in exhaustive detail, but roughly speaking,
the idea is that such a network is likely to attract *more* spammers in
the future because it's either incompetently managed or is actually being
paid off by spammers to "look the other way". Some network operators
have gone so far as to move their spammers around -- assigning them
new IP addresses in order to evade DNSBL listings. Others have even
swapped spammer and non-spammer IP addresses, then lodged disengenuous
protests about how unfair the DNSBLs are. And still others have handed
over the mail addresses of complainers TO THE SPAMMERS, who sometimes
respond by mailbombing them or forging them into the "From" lines of
their subsequent spam runs (a "joe-job"). Here's where you can find SPEWS:
spews.relays.osirusoft.com http://www.spews.org/
It's worth noting that there's a significant overlap in the coverage
of some of these DNSBLs, and so what order you list them in may affect
your performance as well as the load that you impose on the DNSBLs.
(The idea is to put the DNSBL first which blocks the most spam that
*you're* getting, to minimize the number of DNS lookups that your MTA
will perform.)
L. [optional] Change the default SMTP greeting to be multi-line.
This breaks a surprising amount of ratware (slang for spam-sending
programs). Caution: it also may break some buggy MTAs. And eventually
the ratware will have this bug fixed.
M. [optional] The combination of these techniques will block the
overwhelming majority of the spam that nearly any site gets. However,
if that's still not a high enough blocking percentage, then deploy one of:
SpamAssassin http://www.spamassassin.org
SpamBouncer http://www.spambouncer.org/
bogofilter http://www.tuxedo.org/~esr/bogofilter
or a similar classifier to deal with what's left over. Some of these
programs (e.g. SpamAssassin) go far beyond just searching for keywords:
they evaluate messsages based on hundreds of different features whose
weights have been carefully tuned and which are combined to yield an
overall score which can then be used to reject messages, tag them,
divert them to a different mailbox, etc. The set of features used
and their weights are constantly updated to keep pace with changes in
spammer tactics. While early versions of these programs were a bit
rough around the edges (as would be expected) their current versions
are amazingly accurate. They're all free/open-source/peer-reviewed.
N. [highly recommended] Make sure you exempt your "postmaster" and maybe
your "abuse" addresses from the above so that they're still reachable.
Unfortunately, they *will* get spammed (yes, there are spammers stupid
enough to send spam to "abuse") but at least everyone else is spared.
Note that a non-working "postmaster" address may get you listed on some
DNSBLs, e.g.:
RFC-Ignorant http://www.rfc-ignorant.org/
and that a non-working "abuse" address makes it very difficult for people
to contact you to tell you not only about abuse FROM your network, but
abuse OF your network. (No, web forms are NOT an acceptable substitute.)
See RFCs 2822 and 2142.
O. [highly recommended] Make sure -- if you're rejecting mail via any of
these measures -- that the rejection notice makes it very clear why you're
doing it, how anyone who isn't a spammer can contact you to explain the
mistake, and how anyone whose system is broken (e.g. open relay/proxy) can
get it re-tested and removed from the relevant DNSBL(s) once they fix it.
[ Note for Sun-Managers; for DNSBLs, I point them to the DNSBL's web site. ]
P. [mandatory] Look at your logs, where "look at" could mean "read them
every day" or "feed them to scripts that do analysis on them". If you've
goofed, the information you need to find and fix it will be there.
This is especially important to do after you make any changes.
One thing to look for is the correlation between outbound and inbound
mail: if you have users sending to foo@example.com, then you probably
want to make sure you're not blocking example.com. See (T).
Q. [optional] Use your logs to generate a daily/weekly report to
your users telling them what was blocked on their behalf. This
adds more pairs of eyeballs to the log analysis and is a good way
to spot any mistakes.
R. [highly recommended] Make sure you do this for ALL your MX's: some
spammers are deliberately targeting backup MX's because they sometimes
aren't as well-protected. And some ratware will attempt delivery, in
sequence, to all your MX's if its first try fails.
S. [recommended] Join the Spam-L mailing list, where you will find the
highest concentration of experienced mail system admins/spamfighters.
This is the place to learn about new anti-spam techniques or how
to best use the ones that are already around.
http://www.claws-and-paws.com/spam-l/
You might also want to wade into the Usenet newsgroup
news.admin.net-abuse.email, although it's very busy and often contentious.
But it's quite useful to search it when trying to track down a
spammer/spammer domain/technique/tool/person/etc.:
http://groups.google.com/groups?safe=off&group=news.admin.net-abuse.email
T. [mandatory] Make sure you train your users to never, ever, reply to any
spam. No matter how sincere the "...reply here to be removed" message is,
no matter what it says, no matter how angry they are, they must NEVER
reply. (Why? Because all it will do is confirm for the spammer that
the address is valid and receives spam. They'll send it more, and --
since it has been proven to work -- add it to the lists of addreses
which are sold/traded among spammers.)
U. [highly recommended] Make sure that your users NEVER read mail with
an HTML-cognizant mail reader. Spammers (and other unscrupulous people)
often embed intrusive "web bugs" (in the HTML markup) which are triggered as
soon as the message is read -- thus informing the spammer not only of the
user's address (as in (T) above) but their IP address, what mail client
they're using, etc., all of which they of course use to optimize future
spam targeting the same address. (Not to mention invade your privacy,
compromise the security of your network, etc.)
This will also help ensure that none of your users ever send mail
marked up with bloated/broken HTML, which is an entirely good idea
in itself.
V. [recommended] If you insist on running Microsoft products, then
put every system running them behind a non-M$ firewall, stay on top of
the patches (if you can), and keep your virus definitions up-to-date.
Spammers are writing and launching viruses/worms which turn infected
systems into hijackable, anonymizing spamplifiers. If one of these
gets onto your network, you could be sending out an incredible amount
of spam without knowing it -- well, that is, until your IP addresses
start showing up on the DNSBLs which list spam sources and your outbound
mail starts bouncing. See:
http://www.lurhq.com/sobig-e.html
for an analysis of one such virus/worm.
Personally, I think it's much easier/cheaper/better to rip out all
traces of M$ products and replace them with professional-grade,
peer-reviewed, open-source operating systems, servers, and applications,
but if you want to do things the hard way, then make sure you do
at least this so that your operation isn't a hazard to others.
W. [mandatory] Along with (V), make sure that you're reading
your "postmaster" and "abuse" mailboxes every day. Should a system
on your network start emitting spam, this is most likely how you will
first be informed of it. If that happens, RUN, DO NOT WALK, to the
affected system(s) and physically disconnect it/them from your network.
Then go back and answer the mail, take corrective action, etc.
If you're not quick enough to do this, you may end up listed on one
or more of the DNSBLs which list open relays/proxies (see H). If that
happens, you will have to go through the procedures established by
each one to get yourself removed. This is onerous and annoying, so
it's much better to make sure you never get listed in the first place.
Also consider blocking outbound port 25 traffic from all systems EXCEPT
your mail gateways: this will dramatically mitigate the effects of
anything that manages to get past your defenses.
X. [highly recommended] Use some of the many tools which are
available to check ALL of your systems to make sure that they're not
open relays/proxies. Here's a few of the many free/open-source tools
available; note that some DNSBLs also provide facilities on their sites
to conduct testing.
rlytest http://www.unicom.com/sw/rlytest/
blq http://www.unicom.com/sw/blq/
proxycheck http://www.corpit.ru/mjt/proxycheck.html
nmap http://www.insecure.org/
pxytest http://www.unicom.com/sw/pxytest/
While you're at it, learn about the spam problem and what you can do
to help fight it. In addition to the URLs already given, try:
RFC-Ignorant http://www.rfc-ignorant.org
SpamFAQ http://www.spamfaq.net/
AbuseNet http://spam.abuse.net/
CluelessMailers http://cluelessmailers.org/
(CluelessMailers is the home of the amazing "spamdemic" map.)
OpenRBL http://www.OpenRBL.org/
(provides a way to check many DNSBLs at once)
Dr. Mash's site http://moensted.dk/spam/
(so does this)
UXN Spam Combat http://combat.uxn.com/
(numerous anti-spam tools)
Nadine http://www.honet.com/Nadine/
(a look at how bad things have gotten)
SpamSites http://www.spamsites.org/
(people selling ratware)
SueSpammers http://www.suespammers.org/
SpamLaws http://www.spamlaws.com/
Y. [recommended] Do not buy the snake-oil products of carpetbagging
profiteers who would like to sell you a quick-fix, one-size-fits-all
"solution" to the spam problem. In some cases -- they ARE spammers.
(Pretty good racket, eh?) In others, they're selling expensive,
badly-designed systems which are very cost-ineffective. In yet
others, they're hawking systems which make the problem WORSE
(e.g. challenge/response), not better. [More on that elsewhere.]
There's no need for any of that. The anti-spam community, which has long
stood in the path of the spammers who would trample the entire Internet,
has devised and furnished, at no charge, effective spam countermeasures --
and was doing so long before these late-comers discovered a profitable
market and showed up to exploit the Internet's collective misery for
profit. The approach I've outlined here -- which is based entirely on
all that volunteer work -- will work very well for just about everybody.
If it works well for *you*, you might consider saying thanks to the
people responsible, or providing a mirror of their web site, or a DNS
secondary, or something to acknowledge their hard work.
Z. [highly recommended] Along with (Y), take the Boulder Pledge:
ttp://www.panix.com/~tbetz/boulder.shtml
and help remove the economic support which props up many/most spammers.
It's ironic how many people complain about spam, but then proceed to
purchase the goods and services that FUND spam. So don't do it: find
out who's spamming and never buy from them again -- or AT LEAST until
they stop spamming. *Make sure they know that you've done this and why.*
That includes finding out if the ISP which connects *you* to the
Internet or hosts your web site(s) is part of the problem (or part of
the solution). It's equally ironic how many people complain about spam
that's being facilitated by and coming from *their own ISP*.
If this is what's happening to you, you might want to ask your ISP just
what the H-E-double-hockey-sticks they think they're doing. (You also
might want to share the gist of these conversations with the folks
on Spam-L and in news.admin.net-abuse.email, who can often shed
considerable light on the subject thanks to long collective memory.)
If it turns out your ISP is knowingly furnishing services of any kind to
spammers, then an appropriate response from you is "Shut if off...RIGHT NOW."
Long, painful experience has shown that "warnings" and "temporary
suspensions" and other half-measures are completely ineffective, and
that, unfortunately, the only thing which works is immediate, permanent
disconnection of all services without warning (accompanied by clean-up
charges, fines, confiscation of equipment and data, etc.): so that is
what you should insist that your ISP do.
ISP which do this are good folks to buy services from. Spammers quickly
figure out who they are and stay away in droves.
ISPs which don't do this end up hosting lots of spammers, get listed
on various DNSBLs, provide sub-standard service to their customers,
and often spend more time whining about how unfair it all is instead
of solving the actual problem(s). Or they just collect the checks:
use your favorite engine to search for "pink contract" and read what
you find.
----Rsk
Addendum for Sun-Managers: Here is a sample portion of a sendmail ".mc"
file which can be used to build a sendmail.cf WARNING WARNING WARNING:
you should make sure you FULLY understand EVERY line of this before you
try to use ANY of it. Failure to do so may yield disastrous results.
*Don't complain to me if that happens: you need to RTFM and test instead
of believing my scribbles.*
If you don't know what a ".mc" file is, then you probably don't care
about this. (If you want to learn, see cf/cf/README and then cf/README
in the sendmail source code distribution.)
This particular set of configuration options -- which is NOT COMPLETE --
is part of what I use. I've included it here just to give you some
idea what's possible and a starting point. You really really really
should learn this stuff for yourself if you want to use it.
These options (among other things):
- turn off the SMTP VRFY and EXPN commands
- disable return-receipts
- puts in a multi-line SMTP greeting string
- disable sendmail's ability to handle UUCP mail
- uses delay_checks to postpone DNSBL checking until
after seeing is the user is authorized (so as not
to block our own users who happen to be at an IP
that might otherwise be blocked, e.g. dialed up)
- enables use of the "access" file.
- enables use of half a dozen or so DNSBLs
OSTYPE(solaris2)dnl
DOMAIN(generic)dnl
define(`confPRIVACY_FLAGS', ``needmailhelo,needvrfyhelo,authwarnings,novrfy,noexpn,noreceipts'')dnl
define(`confSMTP_LOGIN_MSG',`$j Sendmail $b\nNO UBE (spam) permitted\nBy connecting to this server, you consent to being tested\nfor common security vulnerabilites.\nSuch detected vulnerabilities may result in rejection of your mail,\nand/or a report to security or anti-spam organizations.\nReport general mail issues to postmaster\nReport spam and other abuse issues to abuse\n$j ESMTP')
define(`confMAX_MESSAGE_SIZE', `5000000')dnl
define(`confEIGHT_BIT_HANDLING', `pass8')dnl
LOCAL_USER(`root,postmaster')dnl
FEATURE(accept_unresolvable_domains)dnl
FEATURE(use_cw_file)dnl
FEATURE(access_db)dnl
FEATURE(nouucp,nospecial)dnl
FEATURE(`delay_checks', `friend')dnl
FEATURE(`dnsbl', `blackholes.easynet.nl', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by easynet.nl DNSBL (http://blackholes.easynet.nl/errors.html)"', `')dnl
FEATURE(`dnsbl', `list.dsbl.org', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by dsbl.org DNSBL (http://dsbl.org/)"', `')dnl
FEATURE(`dnsbl', `dnsbl.njabl.org', `"550 5.7.1 mail delivery refused - "$&{client_addr}" listed by njabl DNSBL (http://njabl.org/)"', `')dnl
FEATURE(`dnsbl', `proxies.relays.monkeys.com', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by monkeys.com UPL DNSBL (http://www.monkeys.com/upl/)"', `')dnl
FEATURE(`dnsbl', `relays.ordb.org', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by ordb DNSBL (http://ordb.org/)"', `')dnl
FEATURE(`dnsbl', `opm.blitzed.org', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by blitzed.org OPM DNSBL (http://opm.blitzed.org/)"', `')dnl
FEATURE(`dnsbl', `dnsbl.sorbs.net', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by sorbs.net DNSBL (http://dnsbl.sorbs.net/)"', `')dnl
FEATURE(`dnsbl', `dialups.visi.com', `"550 5.7.1 mail delivery refused - "$&{client_name}" listed by pan-am PDL DNSBL (http://www.pan-am.ca/pdl/)"', `')dnl
FEATURE(`dnsbl', `sbl.spamhaus.org', `"550 5.7.1 mail delivery refused - IP range of "$&{client_name}" listed by Spamhaus DNSBL (http://www.spamhaus.org/sbl/)"', `')dnl
MODIFY_MAILER_FLAGS(`LOCAL', `+S')dnl
MAILER(local)dnl
MAILER(smtp)dnl
And here is a tiny sample of what you might want to put in /etc/mail/access:
RTFM and remember to always rebuild the .db version from the text version.
I've included some coments here: DO NOT include them in the access file.
Spam:abuse@ FRIEND
Spam:postmaster@ FRIEND
"abuse" and "postmaster" get mail from everyone, even spammers
From:some-non-spamming-domain.com OK
some-non-spamming-domain.com can send us mail even if otherwise blocked.
This means that spammer can forge this domain and get through, but they'll
have to guess it first.
big@boss.com ERROR:5.7.1:"550 mail delivery refused - Sobig worm detected and rejected"
Block the Sobig worm, at least as it exists today.
hahaha@sexyfun.net ERROR:5.7.1:"550 mail delivery refused - Hybris worm detected and rejected"
Same for Hybris. This isn't much of an antivirus solution, but it helps.
test2@test2.com ERROR:5.1.1:"550 mail delivery refused - User unknown"
test@test.com ERROR:5.1.1:"550 mail delivery refused - User unknown"
test@test.net ERROR:5.1.1:"550 mail delivery refused - User unknown"
verify@email.com ERROR:5.1.1:"550 mail delivery refused - User unknown"
verify@pisem.net ERROR:5.1.1:"550 mail delivery refused - User unknown"
verify@testmail.com ERROR:5.1.1:"550 mail delivery refused - User unknown"
Block commonly-used spamer probe addresses.
CacheFlowServer@ ERROR:5.7.1:"550 mail delivery refused - compromised CacheFlowServer detected and rejected"
Block mail from almost-certainly hijacked CacheFlowServers...assuming that
we're not running one ourself that we expect to get mail from.
cyberpromo.com ERROR:5.7.1:"550 mail delivery refused - blocked domain cyberpromo.com, contact abuse@MYDOMAIN for further information""
Block notorious spammer Sanford Wallace's domain.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:54 EDT