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
>> 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 Mon Oct 23 2006 - 13:03:21 PDT
This archive was generated by hypermail 2.2.0 : Mon Oct 23 2006 - 13:03:23 PDT