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

Re: Possible SPAM mitigation trick

Expand Messages
  • mouss
    ... what do you mean here? the advantage I see is that the connect
    Message 1 of 14 , Nov 22, 2005
    • 0 Attachment
      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 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.
      >
    • Jorey Bump
      ... I m using a host that has no A record (NXDOMAIN) as the dead primary in some of my configurations. While it applies less of a penalty, it isn t
      Message 2 of 14 , Nov 22, 2005
      • 0 Attachment
        Nathanael Hoyle wrote:

        > 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), 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.

        I'm using a host that has no A record (NXDOMAIN) as the dead primary in
        some of my configurations. While it applies less of a penalty, it isn't
        RFC-compliant, so I'm not strongly recommending it:

        RFC 2181, 10.3. MX and NS records:

        This domain name must have as its value one or more address records.

        It's conceivable that someone would filter on this criteria (although I
        think it would be misguided, as long as there was a valid MX in the
        list). Many people filter on the presence of bogons, so avoid using
        these at all costs. Network boundary addresses come dangerously close to
        being easily identified as invalid, so be cautious with this approach.

        Wietse offered this advice in an earlier exchange:

        "If you're concerned about listing a primary MX record without valid
        A record, you could instead supply an IP address that immediately
        returns a TCP RESET. This could be done with a packet filter rule,
        or by giving a machine a second external IP address without an SMTP
        listener on it."

        Using a packet filter offers the opportunity for logging.
      • 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).
        Message 3 of 14 , 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
        • 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.