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

Re: Possible SPAM mitigation trick

Expand Messages
  • mouss
    ... The remote system has no idea how your network is subnetted. so the failure will mostly be caused by a routing error (no route to host) generated in your
    Message 1 of 14 , Nov 22, 2005
    • 0 Attachment
      Nathanael Hoyle a écrit :
      >
      > 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.
      >>>
      >>
      >
      >

      The remote system has no idea how your network is subnetted. so the
      failure will mostly be caused by a routing error (no route to host)
      generated in your network. A tcp rst (generated by an existing host)
      would be as fast. I think the advantage is in resource usage (no need to
      go through an ip filter or a tcp stack) in addition to what you said
      above (no need to use a real host's IP).
    • mouss
      ... - We live in CIDR. so remote client don t care. - broadcast and network addresses are valid (try a ping). so as Wietse says, packets will timeout, unless
      Message 2 of 14 , Nov 22, 2005
      • 0 Attachment
        Nathanael Hoyle a écrit :
        >
        > If you would please note, I used the bottom end network boundary, not
        > the top-end broadcast address. To my understanding, this would be
        > accurate in describing broadcast address behavior, but not network
        > boundary address behavier. Would this in fact still apply for, for
        > intance the .0 address in a class C?
        >

        - We live in CIDR. so remote client don't care.
        - broadcast and network addresses are valid (try a ping). so as Wietse
        says, packets will timeout, unless one of your routers returns an error.
      • Covington, Chris
        Guys, This is what I ve setup: fauxmx01.plusone.com MX 10 (fake MX, non-responding IP) nymeta01.plusone.com MX 20 (real MX) nymeta02.plusone.com MX
        Message 3 of 14 , Nov 22, 2005
        • 0 Attachment
          Guys,

          This is what I've setup:

          fauxmx01.plusone.com MX 10 (fake MX, non-responding <network> IP)
          nymeta01.plusone.com MX 20 (real MX)
          nymeta02.plusone.com MX 20 (real MX)
          fauxmx02.plusone.com MX 30 (fake MX, non-responding <broadcast> IP)

          This will slow down the "sneak in through the presumably
          less-restrictive, lower-priority MX" as well as the "go
          straight to the highest-priority MX" direct-to-MXers. And
          it uses no IPs, if you use your network and broadcast IPs.
          I wonder if this can be used in place of greylisting...

          We'll see how it works.

          ---
          Chris Covington
          IT
          Plus One Health Management
          75 Maiden Lane Suite 801
          NY, NY 10038
          646-312-6269
          http://www.plusoneactive.com
        • mouss
          ... no, this is different than GL: here, every host (legit or not) will try MX1, then if compliant, will try MX2. legit systems are thus somewhat penalized. In
          Message 4 of 14 , Nov 22, 2005
          • 0 Attachment
            Covington, Chris a écrit :
            > Guys,
            >
            > This is what I've setup:
            >
            > fauxmx01.plusone.com MX 10 (fake MX, non-responding <network> IP)
            > nymeta01.plusone.com MX 20 (real MX)
            > nymeta02.plusone.com MX 20 (real MX)
            > fauxmx02.plusone.com MX 30 (fake MX, non-responding <broadcast> IP)
            >
            > This will slow down the "sneak in through the presumably
            > less-restrictive, lower-priority MX" as well as the "go
            > straight to the highest-priority MX" direct-to-MXers. And
            > it uses no IPs, if you use your network and broadcast IPs.
            > I wonder if this can be used in place of greylisting...

            no, this is different than GL:

            here, every host (legit or not) will try MX1, then if compliant, will
            try MX2. legit systems are thus somewhat penalized.

            In GL, once a host has been "automatically whitelisted", it is no more
            deferred.


            Also here, a spamware that tries second MX won't be blocked. while in GL
            it will be deferred.

            so the approaches may be used together. I personally don't feel playing
            these MX games.
          • Covington, Chris
            ... The theory behind GLing is that direct-to-MX clients won t retry, so if they time out at the primary MX or at the lowest-value MX that might be just as
            Message 5 of 14 , Nov 23, 2005
            • 0 Attachment
              On Wed, Nov 23, 2005 at 02:23:39AM +0100, mouss wrote:
              > no, this is different than GL:
              >
              > here, every host (legit or not) will try MX1, then if compliant, will
              > try MX2. legit systems are thus somewhat penalized.
              >
              > In GL, once a host has been "automatically whitelisted", it is no more
              > deferred.
              >
              >
              > Also here, a spamware that tries second MX won't be blocked. while in GL
              > it will be deferred.

              The theory behind GLing is that direct-to-MX clients won't retry, so if
              they time out at the primary MX or at the lowest-value MX that might be
              just as effective as tempfailing them.

              ---
              Chris Covington
              IT
              Plus One Health Management
              75 Maiden Lane Suite 801
              NY, NY 10038
              646-312-6269
              http://www.plusoneactive.com
            • Jorey Bump
              ... It s important to note that both methods exploit the lack of RFC-compliant behavior common to malware, albeit using completely different approaches.
              Message 6 of 14 , Nov 23, 2005
              • 0 Attachment
                Covington, Chris wrote:
                > On Wed, Nov 23, 2005 at 02:23:39AM +0100, mouss wrote:
                >
                >>Also here, a spamware that tries second MX won't be blocked. while in GL
                >>it will be deferred.
                >
                > The theory behind GLing is that direct-to-MX clients won't retry, so if
                > they time out at the primary MX or at the lowest-value MX that might be
                > just as effective as tempfailing them.

                It's important to note that both methods exploit the lack of
                RFC-compliant behavior common to malware, albeit using completely
                different approaches. Furthermore, they attempt to do it in an
                RFC-compliant way.

                This is a stated weakness of both methods, because it is possible that
                malware authors will adapt. But, it's arguable that this adaptation
                offers benefits in the long run. If malware writers feel it's worth it
                to obey the RFCs, maybe others will follow suit.

                By gradually becoming a little less liberal in what we accept, the
                pressure will come to bear on administrators and software developers who
                unleash misbehaving mail systems on the rest of the world.
              • Xavier Beaudouin
                [...] ... Problem is that most low end users /mail administrator that handle only 3 or 4 mailboxes are mostly ignorant of the deal and the responsability
                Message 7 of 14 , Nov 23, 2005
                • 0 Attachment
                  [...]

                  > By gradually becoming a little less liberal in what we accept, the
                  > pressure will come to bear on administrators and software developers who
                  > unleash misbehaving mail systems on the rest of the world.

                  Problem is that most low end "users"/mail administrator that handle only 3
                  or 4 mailboxes are mostly ignorant of the deal and the responsability
                  about mail servers.

                  Also most of them are really agressive when someone tell them that his
                  server is badly configured and doesn't suit standards....

                  This is bad... but I had to reduce my spam filter for customers that
                  wanted their mails whatever it is spam or not...

                  I've got chance that postfix allow me to add several policies to avoid
                  being spammed :p

                  /Xavier

                  --
                  Quand on essaye continuellement, on finit par y arriver. Donc, plus ca
                  rate, plus on a de chance que ca marche...
                  (Proverbe Shadok)
                • Mark Nernberg
                  ... most is an understatement. ... How true. ... Instead, I ve taken a different approach. I allow my customers to have ALL of my spam filtering, or NONE of
                  Message 8 of 14 , Nov 23, 2005
                  • 0 Attachment
                    On 11/23/05 12:20 PM, "Xavier Beaudouin" <kiwi@...> wrote:

                    >
                    > [...]
                    >
                    >> By gradually becoming a little less liberal in what we accept, the
                    >> pressure will come to bear on administrators and software developers who
                    >> unleash misbehaving mail systems on the rest of the world.
                    >
                    > Problem is that most low end "users"/mail administrator that handle only 3
                    > or 4 mailboxes are mostly ignorant of the deal and the responsability
                    > about mail servers.
                    >

                    "most" is an understatement.

                    > Also most of them are really agressive when someone tell them that his
                    > server is badly configured and doesn't suit standards....

                    How true.
                    >
                    > This is bad... but I had to reduce my spam filter for customers that
                    > wanted their mails whatever it is spam or not...

                    Instead, I've taken a different approach. I allow my customers to have ALL
                    of my spam filtering, or NONE of my spam filtering. Nothing in between. I
                    explain to them that the problem is when sending servers are non-compliant
                    with the rules. I inform the sending server administrators that we are
                    blocking their mail. The admins don't really give a shit.

                    But when my customers start bothering the other admins users, and those
                    users start buggering the non-compliant admin, things seem to get done.


                    --
                    Mark J. Nernberg
                    Director of Technology
                    (412)478-6262

                    http://www.downtownhelpdesk.com/

                    Customer Support: support@...

                    Have you tried our on-demand remote support services?

                    Downtown Help Desk and 1-Fast Computer Service, providing quality technology
                    solutions to the small business since 2003.
                  Your message has been successfully submitted and would be delivered to recipients shortly.