Subject: Relay honeypots (RE: [Asrg] define spam)

From: Paul Judge <[email-masked]>
Date: Fri, 4 Apr 2003 11:46:21 -0500

Changing subject of this thread.

> -----Original Message-----
> From: Brad Spencer [mailto:[email-masked]] 
> Sent: Friday, April 04, 2003 11:44 AM
> To: [email-masked]
> Subject: Re: [Asrg] define spam
> 
> 
> At 11:20 AM 4/4/2003 -0500, you wrote:
> 
> >Process question.  How do you become a relay honeypot without being
> >blacklisted?
> 
> Spammers scan for open relays.  When they find you you become 
> (more often 
> than not) an active honeypot.  I got checked about  15 
> minutes ago - a 
> recipient (dropbox) I don't recognize.  The weekend is coming 
> up - I'll see 
> if I get spam (I decided to deliver this one.)
> 
> At least one operator has reported enhanced results by being 
> blacklisted - 
> he nominated himself.  Open relay DNSBL's list the open 
> relays.  If the IP 
> you are using will never be a spam source then having it 
> blacklisted causes 
> no harm to any valid email.  It does cause harm to the 
> spammer who gets his 
> lists of open relays by consulting a blacklist.
> 
> Originally I ran a combined server/honeypot (I separated 
> relay spam from 
> valid email.)  I got blacklisted.  It was (still is) an .edu IP.  In 
> reality the number of times a user complained about blocked 
> delivery was so 
> small it wasn't a problem (plus I smart-hosted the 
> server/honeypot to an IP 
> that wasn't blacklisted for a long time.)
> 
> I think blacklists should be salted with honeypots - it's 
> about as easy a 
> way to give spammers grief that I can imagine.  Salt them 
> enough and the 
> spammers will stop using them as lists of open relays.  Maybe 
> I'm weird but 
> I always find it funny when a spammer sends relay spam to a 
> honeypot - in 
> addition to its function a salted-address honeypot could be a 
> source of 
> amusement.  It's REALLY funny (to me) to deliver a relay test 
> in the middle 
> of the spam run - Spammy has tumbled somewhat to the fact that his 
> responses are zip from the spam sent to that particular relay 
> and he's 
> checking it.  He sees: no problem, it relays fine.  How can 
> you not laugh?
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 4 Apr 2003 14:22:53 -0500

At 10:57 AM -0600 4/4/03, Brad Spencer wrote:
>For the honeypot to work all you need deliver are the spammer test 
>messages.  The spammers don't nominate you for DNSBL's if you do - 
>you're safe.  If you deliver the test messages then you intend to 
>receive and hold the spam.  Do that and you won't get blacklisted. 
>Not that you care, unless you're concerned about SPEWS-like 
>over-zealous blocking that could spill over.

Given that blacklisters range from those who block the IP, to those 
who block an entire range of IPs.  And given that you are depending 
on blacklisters testing for delivery and not just existance.  And 
given that the detection process has to be manual, and has to 
distinguish between blacklister tests and spammer tests.  I don't 
think you are going to find a lot of people willing to set up 
honeypots of this type.

-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Spencer <[email-masked]>
Date: Fri, 04 Apr 2003 15:13:48 -0600

At 02:22 PM 4/4/2003 -0500, you wrote:

>Given that blacklisters range from those who block the IP, to those who 
>block an entire range of IPs.  And given that you are depending on 
>blacklisters testing for delivery and not just existance.  And given that 
>the detection process has to be manual, and has to distinguish between 
>blacklister tests and spammer tests.  I don't think you are going to find 
>a lot of people willing to set up honeypots of this type.

I doubt many base their decision on what you've identified, I doubt saying 
anything about it will have an effect, but I think you greatly 
over-estimate that potential problem.  You'd have to have an over-eager 
blocklist that concentrates on open relays and that actively searches for 
the same.  That's no one I know of.

I usually just accept the test messages and don't deliver them - my current 
interest is in that aspect of the spamming problem.  I'd be very glad to 
see many more people setting up systems just to trap relay tests, no 
more.  If the tests were reported (say in NANAS) that would help describe 
the spammer test practices to a wider audience.  The person running the 
honeypot could learn more about how the spammers test in his portion of the 
internet and quite easily could see and identify a new form of relay 
test.  I trap some tests with addressees that are so extreme 
([email-masked]) that I have to believe the spammer 
actually relies on the bounces (to, for instance, 
[email-masked]).  What else might be discovered?

The spam problem is not solved, relay tests are a key part of much spam.  I 
think it is worth the tiny amount of effort involved to trap the tests. If 
the ISP (in the example case, PacBell) of the spammer was at all responsive 
then there could even be action taken.  In the absence of action all I have 
is documentation of inaction.  That may be worthless - maybe not.

---

From: Brad Spencer <[email-masked]>
Date: Sun, 06 Apr 2003 07:44:00 -0500

>a lot of people willing to set up honeypots of this type.

This is ASRG, of IETF.  I take the "engineering" seriously.  I'm a chemist, 
not an engineer, but I worked several years in an engineering group that 
designed a product - a scientific instrument.  I have some concept of what 
engineering is.  Sometimes engineers do a superficial analysis of the 
problem and then leap into implementation of a solution that appears 
useful, based on that analysis.  Often the solution an engineer chooses is 
one that can be characterized as having complexity that is directly related 
to the types of things the engineer wants to do.  That isn't necessarily 
good engineering.  I'm as guilty as anyone: my first honeypot efforts arose 
from a quick analysis and were strongly influenced by my desires: I wanted 
to do as little as possible to achieve a solution.  I put no effort at that 
time into analysis of the overall problem: I just wanted to make a system 
that I couldn't easily or cheaply secure the standard way stop relaying 
spam.  Since I couldn't make it not accept the spam I chose to make it not 
deliver the spam.  That worked, that led to a fuller understanding of the 
concept and of the overall problem. Most of the analysis I did was after 
implementation.  It's still good analysis.  It deserves attention.

The psychology you describe is interesting, may even be pertinent, but I 
ask that such considerations be removed from the engineering aspects while 
the value of a method is being considered.  Honeypots, implemented 
properly, are 100% effective in stopping spam and 100% effective in 
avoiding collateral damage.  They may succeed in identifying the IP a 
spammer is using (this now more likely happens with open proxy honeypots), 
which can allow notice to the spammer's ISP and possible termination of the 
spammer.  In any case a full honeypot, in operation, may succeed in 
stopping significant amounts of spam.  This is spam directed at others but 
it can be several orders of magnitude greater than the spam that would go 
to the operator of that honeypot, were it to have a published email 
address.  Tremendously successful honeypots have been implemented using 
laughable equipment: 1 100 MHz 486 DX4, a 120 MHz Pentium.  Email is an old 
application, ran on old systems.  Honeypots are not computationally 
intensive - they can run on about anything that boots and has a network 
connection.  If I could get Linux running on my old 16 MHz, 4 Mb 386 I have 
no doubt I could run a successful honeypot on it.  On something that old 
I'd just run sendmail -bd.  That system isn't important - the importance 
lies in the very low resource requirements for a honeypot.  Just as 
significantly millions of Windows users can run Jackpot - they have no MTA, 
port 25 is not being used for any real application, their systems have no 
SMTP receiver function.  The resource requirements are low, there are 
millions of potential systems for use, the software is small and easily 
downloaded - the honeypot approach deserves full attention.

For a huge portion of current spam open relays and open proxies are 
used.  From an engineering standpoint it is useful (perhaps necessary) to 
know how spammers find and then abuse open resources.  As it is close to 
the most trivial thing possible to detect the tests used by spammers it 
would seem that any serious effort at stopping spam would include a 
significant effort toward that detection.  Just this morning I captured a 
relay test that looks different from any I've captured before.  With two 
honeypots (home and "work") I'm not likely to see all forms of relay 
test.  I think serious anti-spammers should know all the ways spammers use 
to detect open relays.  In a sense there's only one: send a test message 
and see what happens, but there are differences in the test 
messages.  Knowing more about those differences means you know more about 
the spammers.  Quite possibly it could be seen that there were clusters of 
spammers - some who used one form of relay test, some who used 
another.  This might help in learning more about which spammers are 
associated with other spammers.  It might not, of course - some simply 
could be using the same purchased tool.  Still, watching relay tests is 
watching spammers.  That's worth doing.

So.  If the psychology is ignored what is the value of honeypots?  The 
value may only accrue to those who don't succumb to the psychology - what 
value is there to those brave souls who choose to run honeypots?  If there 
were 10,000 of them would they make a big 
difference?  100?  1000?  10?  The 100 MHz 486 DX4 crippled Ralsky's Dallas 
operation for a while - that was one honeypot.  The situation may have been 
unique and may never occur again but the significance of that success needs 
to be appreciated.  Is there any other way that a major spammer has been 
driven off 3 different ISPs in one weekend on the basis of the information 
gathered by a single computer?  (By the way: the 486 DX4 had other tasks as 
well - the honeypot didn't consume or need all its resources.)

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 6 Apr 2003 17:01:11 -0400

>The psychology you describe is interesting, may even be pertinent, 
>but I ask that such considerations be

It's a pain to do, and it can get my mail server shut down if I make 
a mistake.  That's not a very complex piece of psychology.

Show me a risk-free, automatic process to do it, and then you'll have 
some takers.  Please do not assume that everyone fighting spam is 
sitting around with spare IP addresses and lots of free time.

>removed from the engineering aspects while the value of a method is 
>being considered.  Honeypots, implemented properly, are 100% 
>effective in stopping spam and 100% effective in avoiding collateral 
>damage.  They may succeed in identifying the IP a spammer is using 
>(this now more likely happens with

They "stop" spam only if the spammer has so many open proxies that 
they don't know which to choose from.  Spammers don't send a message 
once to each person and then stop.  They send things over and over 
again.  If you don't like psychology, then maybe you could give us 
the math.  How many fake proxies do you need?  I'm sure it's possible 
to calculate.  Given N real open-proxies, how many fake ones do you 
need before the amount of spam being sent drops to a negligible 
level?  (Sorry, it's been way too many years since my probability 
course.)  Don't forget.  If you start having a noticeable impact on 
the amount of spam, the spammers will start taking counter measures 
to see if they can tell real proxies from fake ones.

>open proxy honeypots), which can allow notice to the spammer's ISP 
>and possible termination of the spammer.  In any case a full 
>honeypot, in operation, may succeed in stopping significant amounts 
>of spam.  This is spam directed at others but it can be several 
>orders of magnitude greater than the spam that would go to the 
>operator of that honeypot, were it to have a published email 
>address.  Tremendously successful honeypots have been implemented 
>using laughable equipment: 1 100 MHz 486 DX4, a 120 MHz

I really don't care about CPUs.  I care about how much real time I 
have to spend monitoring something.  And I care about the fact that I 
have a limited supply of IP addresses and I currently run real mail 
servers on them.  If someone mistakes my honeypot for the real 
thing--I'm screwed.

>which spammers are associated with other spammers.  It might not, of 
>course - some simply could be using the same purchased tool.  Still, 
>watching relay tests is watching spammers.  That's worth doing.

Absolutely.  I didn't once say that this was not a valuable test 
tool.  Please don't confuse the two issues.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Brad Spencer <[email-masked]>
Date: Sun, 06 Apr 2003 21:20:41 -0500

At 09:04 PM 4/6/2003 -0400, you wrote:
>At 5:45 PM -0500 4/6/03, Brad Spencer wrote:
>>OK.  Run your MTA with delivery stopped and write software that 
>>recognizes relay tests of your IP and delivers those.  To make it even 
>>safer write software that does that just once per day, maximum.
>
>Yes.  If you recall, the very first thing I asked you when you talked 
>about this technique was whether you had software I could use to try 
>it.  You said no.  I'm the one complaining about lack of time, remember?

This is ASRG.  It is perfectly reasonable to suggest approaches that have 
not been implemented.

Years ago I described using sendmail -bd (sendmail is no longer that simple 
but the concept remains) as a honeypot.  As described it will trap relay 
tests - that is fully automated.  Something additional would need to be 
added to recognize relay tests and deliver them.  I separated spam from 
legitimate email on a server/honeypot automatically, I recognized relay 
tests and forced their delivery (saving a copy) fully 
automatically.   Jackpot (http://jackpot.uk.net/) is fully automated and 
runs on any system with a Java Virtual Machine.  I've seen it deliver small 
quantities of single-recipient spam, therefore I didn't recommend it to 
you.  There's also been a honeypot written in Perl published. Michael 
Tokarev's honeypot in Moscow was automated to the point that it sent an 
email message to Michael whenever a probable relay test message was 
received along with instructions (I imagine just a string to cut and paste 
into a window connected to the honeypot system) that would deliver that one 
test message.  That's not fully automated so I didn't report it.  If you 
want to just trap relay tests (which is fully reasonable, helps, and is 
what I usually do) just disable delivery in some way.  Smarthost to a 
coffee pot or something like that - anything that prevents delivery.  I 
stop the queue on a VMSsystem, I run Jackpot with delivery off at home.

>>Even easier, do what I do: run an MTA with delivery stopped and report 
>>relay tests to the appropriate ISP.  If you claim you are going to get 
>>blacklisted because spammer relay tests go in to your system and 
>>disappear you'll need to explain how that happens.
>
>I thought what you said was that to get this started, you had to let 
>through the initial relay tests.  Telling those from BL relay tests is my 
>concern.  Plus the fact that it has to be done manually.

You can choose the level of operation you desire.  I've cut back, mostly, 
to just trapping relay tests.  I consider that to be a useful activity.  It 
also works to deliver spammer relay tests and then trap spam that 
follows.  That isn't essential.  IT can be very satisfying, you can 
sometimes do additional damage if you trap the spam.  For a while a spammer 
was sending me spam in which he used dropbox addresses for his replies and 
had a lot of those so he wouldn't be badly wounded if  a few got reported 
and the accounts got closed.  I reported hundreds at a time - that hurt him 
a bit more.  These were swirve.com and snowboarding.com dropboxes.  Also 
some excite.com addresses - the main difference is that I heard back from 
outblaze but not from excite.com.

>>I'm describing actual factual occurrences, not things I imagine.  If you have
>
>No.  You are imagining a world in which thousands of people do this and it 
>stops spam.  I'm telling you that if you want that happen you a) need to 
>show that the software can be written to do it automatically and b) need 
>to show the numbers.  Instead you keep coming back and telling me how well 
>your honeypot works.  I've never denied that it works.  Show me how it's 
>going to get deployed!  Show me facts.

I'm imagining thousands, up to millions.  Yes.  Even one honeypot has an 
effect.  One honeypot surely is not going to stop spam  (but does have an 
effect) and my goal is not to deal with spam but to end it.  The number 
needed may be less than millions.  As a system as simple as Jackpot already 
exists I have no doubt that in time millions of systems could be 
deployed.  In the default configuration Jackpot accepts only, doesn't 
deliver anything.  That's a huge step forward compared to doing nothing at 
all.  I'd be tickled right now with a few hundred Jackpots that only 
trapped relay tests.   If there were a few hundred I'd pretty soon see if 
exponential growth started - that's what I want and expect.

>This is what so many proposals on this list have done.  They imagine a 
>perfect world in which a whole bunch of people decide to put up with a 
>bunch of grief in order to make the world a better place. Yes, those 
>people exist.  No, you're not going to solve things that way.  The number 
>of people who don't make the effort is way larger.

Understood, and thank you.  Yes.  I don't see grief, though.  If it seems 
too much effort to anyone, if someone doesn't want o do it because he's 
allergic to bee stings and the name "honeypot" disturbs him, no 
problem.  There still has to be thousands willing to do it if they know 
about it and if they aren't scared away by false concerns.

>Take the honeypot idea.  Propose a way of automating it.  Describe how you 
>are going to deal with countermeasures.

I'm lazy.  It is automated so that's done.  Dealing with countermeasures 
rather depends on the countermeasures and I don't intend to tell spammers 
the best way to combat honeypots.  I'm confident the anti-spammers can keep 
the upper hand.  The ultimate spammer defense is to stop sending realy 
tests and to stop sending spam.  I'll let them win that way. If all you do 
is trap relay tests and if trapping relay tests and reporting them becomes 
(through ISP education) a significant way of stopping spammers then there 
are no countermeasures - do a test and get busted.  There is obviously the 
possibility that spammers will switch to doing all their tests through open 
proxies: then the effective weapons are open proxy honeypots.  As a general 
defense against countermeasures i advocate distributing honeypots in source 
form and letting the talented users modify and improve them.  If you don't 
see how this will rapidly result in a plethora of versions you haven't been 
watching software very long.  I want a plethora of versions, an impossible 
snarl.  I'd never be able to figure such a situation out.  More to the 
point, a spammer would never be able to figure it out.  There would be no 
simple, reliable procedure for figuring out an IP isn't a real open 
relay.  Right now there is, of course, since IPs are so perfectly divided 
into just two classes: open relays and non-open relays.

To take any countermeasure the spammer has to start with a test.  Capture 
the test and you have him.  If the honeypot is a standard MTA run as a 
honeypot then I see little chance the spammer can discover it is a honeypot 
without running a test.  If he's going through an open proxy then he has 
slimmer chances of avoiding detection at the open proxy.

>Describe how you are going to deal with spammers reporting you as an open 
>relay to black list operators.

So long as it isn't an idiotic blocklist that expands open relay listings 
there's no problem.  I ran  a server/honeypot that was listed: I invited 
ORBS to test and list me.  I did rely on the apparent low usage of ORBS by 
.edu email managers at the time but that was a server.  I  don't care if 
the IP of the honeypot is listed - I may want it listed may self-nominate 
for listing.  It isn't a permanent black mark on a person's character, it's 
just a listing.  You can take pride in running a listed honeypot: you are 
helping screw any spammer who lazily relies on listings to find open 
relays/open proxies.

One spammer/relay tester did routinely include a blocklist in the 
destination of his tests.  Why, I don't know.  ORDB, I think it was.  I 
didn't and don't care.  I'm not anti-blocklist.  I am against accurate 
blocklists.  The inaccuracy I desire is, of course, that some listed IPs 
not be open relays but instead be honeypots.  That has no impact on 
anti-spam use - the honeypot IP never comes up for anti-spammers.  If it 
is, as I recommend, a system with no valid email function.

>And how you are going to let spammer mail through, but not tests or real 
>spam.  Make a proposal!

You mean, I think, spammer tests through, anti-spammer tests and spam not 
through.  I use sting searches to find relay tests in my mail queue.  My IP 
in plaintext, my IP encoded in decimal ascii, and the string MAILINF0 
(where I could use my IP as encoded in that type of test - I just 
don't.)  I do this manually, when there's also spam in the queue.  When I 
ran fully automated I just used strings (there were more strings - more 
than needed.  I know more now.)  If you fail then you don't deliver a 
spammer test because it isn't encoded in a way you recognize- it's 
fail-safe.  Currently - a spammer could start putting the relay IP in the 
body of real spam - then you'd have to test slightly harder. When I ran 
automated I simply did the string matches, saved copies of the tests, and 
delivered them.  I'm not really a unix shell programmer but I could, if I 
were doing this on a Unix/Linux system, come up with a cron task that would 
automate the entire thing.  Some have gone so far as to automate sending 
complaints to the ISP of the source (Jackpot shows the abuse address, if 
known, of the ISP for each spam-source IP.)  I've done cron commands that 
recognized spam and rm'd it - that was a different problem.

>So far all you've done is what everyone else has done.  You've said, "Hey, 
>there's the great thing, and it works great for me, everyone should do it."

Yep.  But I also give numbers.  Elsewhere I've done the analysis that shows 
the effect would be predicted to grow as the number of honeypots grow.  I 
was a royal PITA in NANAE (past tense may be self-fllattery) about the 
idiocy of simply securing open relays.  For those the effect of securing a 
relay on the delivered spam volume is 0.00000000% until almost every open 
relay is secured, until the existing open relays are inadequate for the 
spam volume.  RFC 2505 says securing open relays is not a viable approach 
to stopping spam.  Nonetheless that approach was taken.  RFC 2505 
says  that is because spammers can find and abuse new (to them, or truly 
new) open relays.  That's what I wish to attack: the ability to find open 
relays.  You can't do anything more about the true open relays so the 
attack has to use non-open relays.  The attack is simple: make them look to 
the spammer (who is constantly searching for open relays) like open 
relays.  Get my thousands or millions of people doing that and the spammer 
will no longer be able to find open relays.  To be effective my ideas 
depends on thousands or millions of participants.  The first hundred or so 
are the hard ones to get - their results will make getting the rest 
progressively easier.

>A data point on the scale of the problem.  Whether it's relay specific or 
>not, I don't know.  I know an ISP which has been blacklisting single IP 
>addresses when they attempt to connect with bogus HELO strings.  They 
>noticed that these came preliminary to an actual spam flood attempt, so 
>they started blocking them as soon as they saw them.  So far he's blocked 
>close to 100,000 distinct IP addresses.

Sure.  For a while, believe it or not, my honeypot was used by a spammer to 
test systems for open proxy.  He'd HELO me and then QUIT.  He'd do it 
always through different open proxies.  For a longer while I constantly got 
connections form a spammer whose spamware depended on EHLO being 
recognized.  My original honeypot, using an MTA, was based on software so 
old it doesn't recognize EHLO (not any Unix software.  If it's vulnerable 
to being OWNed the hacker is going to have to figure it out all on his own 
- there's not even source that can be associated with the software.)  The 
guy you mention is almost certainly blocking open proxies - no surprise at 
the number of them.

Like these:

### Begin SMTP from 199.183.67.8; Tue, 7 Jan 03 01:44 CST
<-- HELO mail.jondoninc.com

### Begin SMTP from dsl-216-222-118-170.az.rmci.net; Tue, 7 Jan 03 02:06 CST
<-- HELO smtp.msn.com

### Begin SMTP from dhcp065-029-068-003.indy.rr.com; Tue, 7 Jan 03 05:40 CST
<-- HELO 164.100.80.127:8080  (probably telling me something right there)

### Begin SMTP from 206.67.58.234; Tue, 7 Jan 03 09:17 CST
<-- HELO lkpug.yahoo.com

They lie.

I keep getting these:

### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:42 CDT
### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:32 CDT
### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:30 CDT
### Begin SMTP from dynamic-62-99-161-123.804.inode.at; Sun, 6 Apr 03 20:28 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 20:22 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 20:12 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 20:02 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:52 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:42 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:32 CDT
### Begin SMTP from dynamic-81-223-36-184.804.inode.at; Sun, 6 Apr 03 19:21 CDT

always EHLO's something like a hotmail IP.  I can't do EHLO, he quits.  If 
I did EHLO I think I might get spam.

The honeypot approach has worked in Italy, Denmark, Germany, Moscow, 
Wisconsin (me, yay!), New Orleans, Atlanta, and surely many other 
places.  It isn't centralized (although Fred Woods is working on a central 
database of recipient addresses, to help detect spammer dropboxes if they 
start spamming those to detect honeypots.)  Anyone with cable or DSL 
potentially could do this- it helps to not be running a real MTA.