Loading ...
Sorry, an error occurred while loading the content.

186720Re: Possible SPAM mitigation trick

Expand Messages
  • Nathanael Hoyle
    Nov 22, 2005
    • 0 Attachment
      mouss wrote:
      > Nathanael Hoyle a écrit :
      >
      >>
      >> I liked Jorey's idea enough to give it a shot. Actually implemented it
      >> yesterday. I debated about having the 'dead' MX host point at a system
      >> which dropped the requests but logged them (via iptables or similar),
      >> not so much to see how much legitimate email made it through (which
      >> seems to be pretty much all of it so far), but to see how much nasty
      >> traffic hit the primary 'dead' host that failed to retry on the second.
      >> For now, I have gone with a somewhat different approach. I actually
      >> have the primary MX listed as an IP that is a network boundary (and
      >> therefore flatly unusable),
      >
      >
      > what do you mean here?

      The IP is a network boundary address. i.e., if it were a class C
      network (/24). the address would be x.x.x.0, rather than 1-254 or
      broadcast (255). Because this IP refers to the *network* rather than a
      host therein, it cannot actually be assigned to a host. This means I
      both avoid wasting an otherwise usable IP, and have no worries that
      something might ever be assigned that IP which would interact in an
      undersired manner with mail delivery attempts. In my particular case
      (which you can find out from the MX records anyhow):

      MX 10 nosoupforyou.speedexpress.net
      MX 100 mail.speedexpress.net

      nosoupforyou.speedexpress.net A 66.142.28.32
      mail.speedexpress.net A 66.142.28.50

      The 66.142.28.32 address is the network boundary for 66.142.28.32/28
      (255.255.255.240 subnet, with .33 as the first usable IP).

      >
      > the advantage I see is that the connect
      >
      >> attempt will fail notably faster than it would if it had to time out,
      >> which reduces the burden on legitimate hosts, but is still just as
      >> undeliverable, keeping the desired effect. I will post with further
      >> results as I have the opportunity to observe them.
      >>
      >


      --
      Nathanael Hoyle
      Systems and Networking
      Speed Express Networks, LLC
      nhoyle@...
      432.837.2811
    • Show all 14 messages in this topic