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

Re: Possible SPAM mitigation trick

Expand Messages
  • Wietse Venema
    ... 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
    Message 1 of 14 , Nov 22, 2005
    • 0 Attachment
      Nathanael Hoyle:
      > 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

      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
    • Nathanael Hoyle
      ... 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
      Message 2 of 14 , Nov 22, 2005
      • 0 Attachment
        Wietse Venema wrote:
        > Nathanael Hoyle:
        >
        >>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
        >
        >
        > 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?

        --
        Nathanael Hoyle
        Systems and Networking
        Speed Express Networks, LLC
        nhoyle@...
        432.837.2811
      • 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 3 of 14 , Nov 22, 2005
        • 0 Attachment
          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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.