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

Re: Possible SPAM mitigation trick

Expand Messages
  • Wietse Venema
    ... It does not matter. The all-bits-0 (old broadcast) and all-bits-1 broadcast address have meaning only for hosts on your own subnet. The all-bits-0 (old
    Message 1 of 14 , Nov 22, 2005
      Nathanael Hoyle:
      > >>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
      > >
      > >
      > > Oh yes it can.
      > >
      > > Your broadcast address is meaningful only for hosts on your subnet.
      > >
      > > Your broadcast address has no meaning for hosts on other subnets.
      > >
      > > Assign your broadcast address to an MX host record, and clients will
      > > experience TCP timeout waits just as if they connect to a host that
      > > is turned off.
      > >
      > > Wietse
      >
      > 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?

      It does not matter.

      The all-bits-0 (old broadcast) and all-bits-1 broadcast address
      have meaning only for hosts on your own subnet.

      The all-bits-0 (old broadcast) and all-bits-1 broadcast address
      have no meaning for hosts on other subnets.

      Assigning either of these to an MX host record means that clients
      will experience TCP timeout waits just as if they connect to a host
      that is turned off.

      Wietse
    • 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 2 of 14 , Nov 22, 2005
        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 3 of 14 , Nov 22, 2005
          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 4 of 14 , Nov 22, 2005
            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 5 of 14 , Nov 22, 2005
              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 6 of 14 , Nov 23, 2005
                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 7 of 14 , Nov 23, 2005
                  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 8 of 14 , Nov 23, 2005
                    [...]

                    > 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 9 of 14 , Nov 23, 2005
                      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.