Open Relay Checker before Opening MTA

Matthew Hawkins matthew at topic.com.au
Mon Feb 11 09:45:18 EST 2002


Hi everyone,

I'm killing three replies with the one email.  I've had a bit of
experience with anti-spam measures, and I was actually disappointed by
the fact I couldn't get to clug to contribute to the meeting on the
subject.

-M

On Sun, 10 Feb 2002, Ben Elliston wrote:
> I realise that Neil's idea would prevent his system from *accepting*
> mail from open relays.  Another approach I have heard about is to only
> accept mail for a domain (say, domain.com) from domain.com's listed MX
> hosts.  I don't know which MTAs implement this, though--anyone?

Postfix can.  I'm pretty sure Exim and Sendmail can too.

> If all you're trying to do is stop reading spam (as opposed to not
> receiving it), then you should check out SpamAssassin.

Sure, but unless you're doing something like using spamproxyd as a
content_filter in postfix, then you first must recieve the spam and pay
for it all before throwing it away with Spam Assassin.  Same problem
with other systems run out of delivery agents, like procmail/maildrop
filters etc.  I don't actually mind having to delete spam in my mailbox,
that's a simple single keystroke, and easily scripted/filtered.  What I
do mind is having to pay for the junk in the first place.

There was some guy in WA who actually sued a spam company and won - he
took them for his standard business charges for utilising his mail
service, and storing stuff on his disks, and so forth.  Didn't get any
more spam from them ;)


On Sun, 10 Feb 2002, Andrew Bartlett wrote:
> My e-mail is abartlet at pcug.org.au, but I'm also abartlet at samba.org. 
> Either way, all my e-mail is sent by smtp.webone.com.au.  Also many
> sites (including hawkerc.net) are (as Alex points out) configured to
> recieve e-mails at one host, but to send e-mails from another.  In my
> case this was a design decision.
> 
> Finally, you won't do this if you still want to get this list - as
> samba.org's outgoing mail also uses this arrangement...

Okay, first please note that an SMTP transaction involves lots of items
that could be identified as containing hostnames.  There's the client of
the SMTP transaction, it's PTR record, what it identifies itself as in
HELO, what the envelope sender address is, and what the message From header
address is.  For Neil's purposes, all he cares about is that the SMTP
client is not an open relay.  What it calls you in the envelope, and
what you call yourself in the message, are two separate and irrelevent
things.

Accepting mail from one system and sending from another is not necessarily
a bad design decision.  Think of a high-load mail service such as
hotmail - it's not just a simple matter of taking a mail and whacking it
into a local spool, or relaying/gatewaying it.  They would have systems
dedicated to just running an smtp acceptance and resolution of delivery
address, other systems designed to deliver mail to the box (doing ldap
or whatever lookups to determine where to put it) and still further
systems as dedicated relays for "local" clients.  The load necessitates
fine-tuning for performance and stability of these independent actions.

On Sun, 10 Feb 2002, jeremyb at supreme.pcug.org.au wrote:
> 2) Even if you're doing simple SMTP relay tests, many MTA's will "accept"
> your message, but then reject it some time later. So if an MTA apparently
> accepted your test, you could blacklist them before the rejection was
> returned to you (except you wouldn't get the rejection, because you've
> already blacklisted them :-(

It's a tricky thing, determining open relays.  Part of the heueristics
of a real system (and many of the public ones do this) would be to check
a few times, and blacklist only when you are certain it really is open.
Patience is a virtue :-)

> 3) If a spammer is actively abusing an open relay, that box can have a
> huge queue of messages to be processed. How long do you wait to complete
> your tests? 30 seconds? 5 minutes? 30 minutes? You could end up with
> long delays in delivering legitimate mail.

Depends on your own MTA.  A proper scalable MTA would not be single
threaded.  Take a look at http://www.postfix.org/big-picture.html for an
example.  Such a program would be difficult to DoS with such an attack.
(note postfix can, and does by default, run multiple smtpd threads)

But you have a good point - one problem with this type of approach is
the scalability.  Another problem is, how do you get off the blacklist?
Many open relays do not stay open for very long, as they find it
difficult to explain to their customers/managers/investors why their
mail is being bounced by many internet mail servers (apparently some
people don't like accepting responsibility for their actions)
So such a system as being discussed has to have some way of removing
blacklisted hosts that no longer meet the requirements of being
blacklisted.  That's further complications to an already complex
process.

> 4) Don't forget multipoint open relays - MTA 'A' accepts the message, but 
> passes it to MTA 'B' which returns the test to you. Do you block 'A', or
> 'B', or both? :-)

Both, since they're a tag team spam relay.

In conclusion, the proactive approach involves knowing your mail server,
knowing your email traffic, and keeping a close eye on your MTA log
files.  This means you either have to find the time yourself, hire
someone to do it, or provide some kind of automated system - or perhaps
many/all of the above.

I'd seriously recommend against using external blacklist services for
two reasons, first being a bit of extra traffic and second you have no
control over them; people like that ORBS dork, thankfully out of
business now, who spite-lists people/places he doesn't like regardless
of them being spam-friendly or not.  Many places now setup their own
DNS-based blacklists, transfer the zones from the remote systems (or
setup some kind of transfer agreement with them), so they can get the
control back while still having the benefits of a somewhat community-
based blacklisting service.  But, there are some who aren't bastards so
the cheapest way is to use them, you just have to find out which ones
you can and can't trust.

I'd post some more but I hate writing essays to mailing lists.  Perhaps
another clug session where I can empty my brain?  (it won't take long ;)

-- 
Matt




More information about the linux mailing list