A Clever Way to Reduce Spam Load on an Email Server

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
ht
tp://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
forrestce.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.be
rkeley.edu/>.

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.

--Jon

[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
> ht
tp://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
> forrestce.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.be
rkeley.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.be
rkeley.edu/>.

They always found a way don't they?  It used to be text
spam.  Over the 
last few months, I've seen it morph into GIF spam and now
PDF spam, which 
is really hard to filter out!

nancy


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.
> 
> --Jon
> 
> [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
>> ht
tp://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
>> forrestce.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.be
rkeley.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.be
rkeley.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.be
rkeley.edu/>.

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
>> ht
tp://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
>> forrestce.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.be
rkeley.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.be
rkeley.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.be
rkeley.edu/>.