Re: A Clever Way to Reduce Spam Load on an Email Server

Re Nolisting: It's definitely an interesting idea, but I suspect
spammers will work around it just as they do with greylisting.

I have been running greylisting for about 2 years, and it does work, but
I still get a lot of spam. Some of it gets relayed through legitimate
email servers where I may have a forwarding address or belong to a group
alias that gets forwarded through that server. And there are still
open/misconfigured relays out there that run bona fide MTAs that will
queue and resend spam mail, defeating greylisting. Nolisting wouldn't
affect these issues, since such bona fide MTAs will move to the next MX
record if the first doesn't work.

However, it would be faster than greylisting, especially if you had a
host configured as the target of the MX record that refused connections
on port 25 (i.e. send TCP RSTs in response to the opening SYN). That
would quickly cause a bona fide MTA to proceed to the next MX record,
but a spambot might not. Greylisting usually makes the

Greylisting does seem to work against botnets that are used for
spamming, and it's conceivable that nolisting would do the same.

Regarding the nameserver zone-transfers, I believe the DNS, especially
in a fairly open network, is a public database. UCB has put much of its
DNS information on a public website for as long as I can remember. Yet
we restrict zone transfers to on-campus hosts, and we do this not to
protect the data, but to protect the servers from malicious or
misconfigured hosts that might initiate zone transfers and place
additional load on the servers. Even this is a fairly weak reason,
since most DNS software has evolved to deal with this sort of threat,
and our servers are at the point where they can handle the load. But
it's not really necessary to change things now, so I leave the
restrictions in place.

I did have a funny exchange with a "security consultant" who gave me a
"free" unsolicited review of security issues in our DNS and pointed out
that U. Oregon allowed zone transfers of our zone from anywhere. He
couldn't understand why I didn't care, even after I pointed out that
most of the info was already on the web for anyone to download.

You're correct about the NYU nameserver--it's a master nameserver
colocated at NYU. This is documented at
<http://net.berkeley.edu/DNS/campus.shtml>.

michael

jon kuroda wrote:
> I tried this at home off and on a year or so back. Granted,
> my home servers don't deal with say calmail's volume, but it
> seemed to have a beneficial effect. I don't have logs from
> back then, but maybe I can dig up my old notes on how well
> this approach worked.
>
> What I notice more is spammers going for lower priority (aka
> higher MX number) MXs on the hope that they get less attention
> paid to them or that they will not be as diligent about spam
> detection as the primary MXs (say a friend offers to be a backup
> MX in case your primary MXs go down)
>
> CalMail doesn't have that sort of multiple MX structure setup,
> so the nolisting approach may have more of an effect, especially
> compared to the nonexistent effect of backup MXs being the
> spammers' first targets.
>
> But, I wonder though, will spammers eventually just hit the next
> best MX, or all the MXs?
>
> This reminds me of the problem of people locking DNS zone
> transfers on their master DNS servers, but not on their
> secondary DNS servers, often hosted offsite by other orgs
> much as UCLA and U. Oregon do for us[1]. So then people had
> to lock down zone transfers on the secondary DNS servers.

> [1] (You may notice a DNS server at NYU in Berkeley's NS
> records -- that's an actual primary server as I recall, a UCB
> system located at NYU. And we do the same for NYU. Mr Sinatra
> could probably fill in details/correct misstatements) And enough
> of that tangent.
>
> On Mon, Oct 23, 2006 at 09:35:04AM -0700, Jon Forrest wrote:
>> At Shel's talk last week Jan Fong mentioned the huge
>> number of spam messages received by the CalMail servers.
>>
>> I recently learned about a technique called "Nolisting",
>> as opposed to "Graylisting". It's described at
>> http://www.joreybump.com/code/howto/nolisting.html .
>>
>> The basic idea is that if an email server has multiple MX records,
>> and you deliberately misconfigure the one with highest
>> priority to point to an address that has nothing listening
>> on the SMTP port, most spam senders won't try any of
>> the other MX records. At worst, legitimate senders will have to retry
>> messages, but since most legitimate senders use caching
>> mechanisms the amount of retries is minimal.
>>
>> One nice result from this approach is that it can substantially
>> reduce the load on the destination mail server because the
>> server receives many fewer connections. This also means content-based
>> spam filters will have less work to do.
>>
>> I wonder what you Micronetters think of this approach.
>>
>> Cordially,
>> --
>> Jon Forrest
>> forrest_at_ce.berkeley.edu
>> Computer Resources Manager
>> Civil and Environmental Engineering Dept.
>> 305 Davis Hall
>> Univ. of Calif., Berkeley
>> Berkeley, CA 94720-1710
>> 510-642-0904
>>
>>
>> ------------------------------------------------------------------------
>> The following was automatically added to this message by the list server:
>>
>> For information about Micronet, including subscribing to
>> or unsubscribing from its mailing list and finding out
>> about upcoming meetings, please visit the Micronet Web site:
>> <http://micronet.berkeley.edu/>.
>
> ------------------------------------------------------------------------
> The following was automatically added to this message by the list server:
>
> For information about Micronet, including subscribing to
> or unsubscribing from its mailing list and finding out
> about upcoming meetings, please visit the Micronet Web site:
> <http://micronet.berkeley.edu/>.

------------------------------------------------------------------------
The following was automatically added to this message by the list server:

For information about Micronet, including subscribing to
or unsubscribing from its mailing list and finding out
about upcoming meetings, please visit the Micronet Web site:
<http://micronet.berkeley.edu/>.
Received on Wed Oct 25 2006 - 01:12:24 PDT