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

Weird setup query

Expand Messages
  • Pete Barnwell
    Hi, I m trying to setup the following behavior for relaying:- if source is in a particular IP range AND the sender address is in a list of domains then allow.
    Message 1 of 20 , Sep 27, 2007
    • 0 Attachment
      Hi,

      I'm trying to setup the following behavior for relaying:-

      if source is in a particular IP range AND the sender address is in a
      list of domains then allow.

      OR

      if source is in a particular IP range AND the recipient address is in a
      list of domains the allow.


      To explain what I'm wanting:-

      The setup is - I'm setting up a relay to accept mail from xDSL clients.
      In a bid to cut down on spam generated by infected windows machines I
      plan on redirecting outbound traffic destined for port 25 to this server
      - then I want to check that the email is at least addressed *from* my
      clients' domains. I can do this with smtpd_restriction_classes, but the
      problem is some clients have their own servers which forward email out
      to other accounts eg hotmail. These emails have the clients address as
      the recipient address, but could be anything as the sender. This could
      equally be done with restriction classes, but I can't figure how to make
      it work if either of them matches? The only way I can see to make it
      work is to hand the email off to a script setup similarly to
      greylisting, but I'd prefer to do it all within Postfix if possible.


      I haven't managed to turn anything up in list archives that matches what
      I'm trying to do, but surely somebody else must have done similar?

      Thanks

      Pete Barnwell
    • Jorey Bump
      ... Why won t your objective be met by the use of SMTP AUTH and common spam filtering techniques? Your proposed solution sounds overly complex and prone to
      Message 2 of 20 , Sep 27, 2007
      • 0 Attachment
        Pete Barnwell wrote, at 09/27/2007 11:51 AM:
        > Hi,
        >
        > I'm trying to setup the following behavior for relaying:-
        >
        > if source is in a particular IP range AND the sender address is in a
        > list of domains then allow.
        >
        > OR
        >
        > if source is in a particular IP range AND the recipient address is in a
        > list of domains the allow.
        >
        >
        > To explain what I'm wanting:-
        >
        > The setup is - I'm setting up a relay to accept mail from xDSL clients.
        > In a bid to cut down on spam generated by infected windows machines I
        > plan on redirecting outbound traffic destined for port 25 to this server
        > - then I want to check that the email is at least addressed *from* my
        > clients' domains. I can do this with smtpd_restriction_classes, but the
        > problem is some clients have their own servers which forward email out
        > to other accounts eg hotmail. These emails have the clients address as
        > the recipient address, but could be anything as the sender. This could
        > equally be done with restriction classes, but I can't figure how to make
        > it work if either of them matches? The only way I can see to make it
        > work is to hand the email off to a script setup similarly to
        > greylisting, but I'd prefer to do it all within Postfix if possible.
        >
        >
        > I haven't managed to turn anything up in list archives that matches what
        > I'm trying to do, but surely somebody else must have done similar?

        Why won't your objective be met by the use of SMTP AUTH and common spam
        filtering techniques? Your proposed solution sounds overly complex and
        prone to errors.
      • Pete Barnwell
        ... Thanks for the suggestion. It would mostly meet the requirement, but I ve tried SMTP AUTH on a small scale for 3 months with a select group of more
        Message 3 of 20 , Sep 27, 2007
        • 0 Attachment
          Jorey Bump wrote:
          > Pete Barnwell wrote, at 09/27/2007 11:51 AM:
          >> Hi,
          >>
          >> I'm trying to setup the following behavior for relaying:-
          >>
          >> if source is in a particular IP range AND the sender address is in a
          >> list of domains then allow.
          >>
          >> OR
          >>
          >> if source is in a particular IP range AND the recipient address is in a
          >> list of domains the allow.
          >>
          >>
          >> To explain what I'm wanting:-
          >>
          >> The setup is - I'm setting up a relay to accept mail from xDSL clients.
          >> In a bid to cut down on spam generated by infected windows machines I
          >> plan on redirecting outbound traffic destined for port 25 to this server
          >> - then I want to check that the email is at least addressed *from* my
          >> clients' domains. I can do this with smtpd_restriction_classes, but the
          >> problem is some clients have their own servers which forward email out
          >> to other accounts eg hotmail. These emails have the clients address as
          >> the recipient address, but could be anything as the sender. This could
          >> equally be done with restriction classes, but I can't figure how to make
          >> it work if either of them matches? The only way I can see to make it
          >> work is to hand the email off to a script setup similarly to
          >> greylisting, but I'd prefer to do it all within Postfix if possible.
          >>
          >>
          >> I haven't managed to turn anything up in list archives that matches what
          >> I'm trying to do, but surely somebody else must have done similar?
          >
          > Why won't your objective be met by the use of SMTP AUTH and common
          > spam filtering techniques? Your proposed solution sounds overly complex
          > and prone to errors.

          Thanks for the suggestion.

          It would mostly meet the requirement, but I've tried SMTP AUTH on a
          small scale for 3 months with a select group of more technically clued
          users, but most of the users seem unable to follow any instruction on
          setting up MUAs etc - I want something that would be completely seamless
          to the users, and only stop stuff I *know* is wrong, rather than risking
          false-positive on outgoing mail. If I can get it right it appears to me
          I run 0% risk of false positives (I accept some spam could sneak
          through, but I'm trying to minimise the risk, not eliminate it)

          I can't use POP-before-smtp since not all of my clients are collecting
          mail from my pop servers - some have it direct delivered to their own
          servers.

          Regards

          Pete
        • Vadim Pushkin
          Greetings All; I have two Postfix servers, one on a DMZ, it accepts all email for my domains and sends email internal to another postfix server. The internal
          Message 4 of 20 , Sep 27, 2007
          • 0 Attachment
            Greetings All;

            I have two Postfix servers, one on a DMZ, it accepts all email for my
            domains and sends email internal to another postfix server.

            The internal postfix server resends based on the recipients email address,
            uses aliases for this purpose.
            Some of the domains, just two actually, get all email to another SMTP
            server, based on what is in the postfix transport map.

            I am looking to know if it is possible to do the following within my postfix
            set up:

            If a source IP address connecting to my internal mailserver is listed in say
            a flatfile, then DO NOT use the aliases file at all, instead simply forward
            whatever it is trying to send to another SMTP server, actually an exchange
            bridgehead in this case.

            We are trying to implement a DL which will be different from one domain to
            another, and the above is required.

            Many thanks in advance.

            .vp
          • Jorey Bump
            ... Bite the bullet, and enforce SMTP AUTH. You do your users a disservice by ignoring universally adopted solutions to common problems. Yes, it s true, even
            Message 5 of 20 , Sep 27, 2007
            • 0 Attachment
              Pete Barnwell wrote, at 09/27/2007 01:47 PM:

              > It would mostly meet the requirement, but I've tried SMTP AUTH on a
              > small scale for 3 months with a select group of more technically clued
              > users, but most of the users seem unable to follow any instruction on
              > setting up MUAs etc - I want something that would be completely seamless
              > to the users, and only stop stuff I *know* is wrong, rather than risking
              > false-positive on outgoing mail. If I can get it right it appears to me
              > I run 0% risk of false positives (I accept some spam could sneak
              > through, but I'm trying to minimise the risk, not eliminate it)
              >
              > I can't use POP-before-smtp since not all of my clients are collecting
              > mail from my pop servers - some have it direct delivered to their own
              > servers.

              Bite the bullet, and enforce SMTP AUTH. You do your users a disservice
              by ignoring universally adopted solutions to common problems. Yes, it's
              true, even today I had to troubleshoot a relaying problem for a user who
              continually forgets to configure his MUA to authenticate (and who is, in
              fact, a computer professional), but all of the alternatives you are
              contemplating raise bright red security flags and expose your system to
              risk. It's not worth the price for a few clueless users.
            • mouss
              ... at some point, they configure their outgoing mail server . at that same time, they could set the port to 587 instead of 25. even without auth, this will
              Message 6 of 20 , Sep 27, 2007
              • 0 Attachment
                Pete Barnwell wrote:
                > Jorey Bump wrote:
                >> Pete Barnwell wrote, at 09/27/2007 11:51 AM:
                >>> Hi,
                >>>
                >>> I'm trying to setup the following behavior for relaying:-
                >>>
                >>> if source is in a particular IP range AND the sender address is in a
                >>> list of domains then allow.
                >>>
                >>> OR
                >>>
                >>> if source is in a particular IP range AND the recipient address is in a
                >>> list of domains the allow.
                >>>
                >>>
                >>> To explain what I'm wanting:-
                >>>
                >>> The setup is - I'm setting up a relay to accept mail from xDSL clients.
                >>> In a bid to cut down on spam generated by infected windows machines I
                >>> plan on redirecting outbound traffic destined for port 25 to this server
                >>> - then I want to check that the email is at least addressed *from* my
                >>> clients' domains. I can do this with smtpd_restriction_classes, but the
                >>> problem is some clients have their own servers which forward email out
                >>> to other accounts eg hotmail. These emails have the clients address as
                >>> the recipient address, but could be anything as the sender. This could
                >>> equally be done with restriction classes, but I can't figure how to make
                >>> it work if either of them matches? The only way I can see to make it
                >>> work is to hand the email off to a script setup similarly to
                >>> greylisting, but I'd prefer to do it all within Postfix if possible.
                >>>
                >>>
                >>> I haven't managed to turn anything up in list archives that matches what
                >>> I'm trying to do, but surely somebody else must have done similar?
                >> Why won't your objective be met by the use of SMTP AUTH and common
                >> spam filtering techniques? Your proposed solution sounds overly complex
                >> and prone to errors.
                >
                > Thanks for the suggestion.
                >
                > It would mostly meet the requirement, but I've tried SMTP AUTH on a
                > small scale for 3 months with a select group of more technically clued
                > users, but most of the users seem unable to follow any instruction on
                > setting up MUAs etc - I want something that would be completely seamless
                > to the users, and only stop stuff I *know* is wrong, rather than risking
                > false-positive on outgoing mail. If I can get it right it appears to me
                > I run 0% risk of false positives (I accept some spam could sneak
                > through, but I'm trying to minimise the risk, not eliminate it)
                >
                > I can't use POP-before-smtp since not all of my clients are collecting
                > mail from my pop servers - some have it direct delivered to their own
                > servers.
                >


                at some point, they configure their "outgoing mail server". at that same
                time, they could set the port to 587 instead of 25. even without auth,
                this will make your life easier.
              • Pete Barnwell
                ... What security risks am I running if I managed to implement my proposed setup? The *almost* universal solution here is to simply relay anything from within
                Message 7 of 20 , Sep 27, 2007
                • 0 Attachment
                  Jorey Bump wrote:
                  > Pete Barnwell wrote, at 09/27/2007 01:47 PM:
                  >
                  >> It would mostly meet the requirement, but I've tried SMTP AUTH on a
                  >> small scale for 3 months with a select group of more technically clued
                  >> users, but most of the users seem unable to follow any instruction on
                  >> setting up MUAs etc - I want something that would be completely seamless
                  >> to the users, and only stop stuff I *know* is wrong, rather than risking
                  >> false-positive on outgoing mail. If I can get it right it appears to me
                  >> I run 0% risk of false positives (I accept some spam could sneak
                  >> through, but I'm trying to minimise the risk, not eliminate it)
                  >>
                  >> I can't use POP-before-smtp since not all of my clients are collecting
                  >> mail from my pop servers - some have it direct delivered to their own
                  >> servers.
                  >
                  > Bite the bullet, and enforce SMTP AUTH. You do your users a disservice
                  > by ignoring universally adopted solutions to common problems. Yes,
                  > it's true, even today I had to troubleshoot a relaying problem for a
                  > user who continually forgets to configure his MUA to authenticate (and
                  > who is, in fact, a computer professional), but all of the alternatives
                  > you are contemplating raise bright red security flags and expose your
                  > system to risk. It's not worth the price for a few clueless users.
                  >
                  What security risks am I running if I managed to implement my proposed
                  setup? The *almost* universal solution here is to simply relay anything
                  from within our netblock, without doing any sanity checking on it at
                  all. We do use SMTP AUTH for road-warrior users who grab whatever
                  connection they can, but for fixed (within my range) IP DSL clients the
                  usual solution is to let them send what they want.

                  If I am missing something please let me know ;-)

                  Pete
                • Pete Barnwell
                  ... Yes, there would be no problem with that (well not insurmountable ones). but that doesn t achieve what I want, which is to do some sanity checking on the
                  Message 8 of 20 , Sep 27, 2007
                  • 0 Attachment
                    mouss wrote:
                    > Pete Barnwell wrote:
                    >
                    >> Jorey Bump wrote:
                    >>
                    >>> Pete Barnwell wrote, at 09/27/2007 11:51 AM:
                    >>>
                    >>>> Hi,
                    >>>>
                    >>>> I'm trying to setup the following behavior for relaying:-
                    >>>>
                    >>>> if source is in a particular IP range AND the sender address is in a
                    >>>> list of domains then allow.
                    >>>>
                    >>>> OR
                    >>>>
                    >>>> if source is in a particular IP range AND the recipient address is in a
                    >>>> list of domains the allow.
                    >>>>
                    >>>>
                    >>>> To explain what I'm wanting:-
                    >>>>
                    >>>> The setup is - I'm setting up a relay to accept mail from xDSL clients.
                    >>>> In a bid to cut down on spam generated by infected windows machines I
                    >>>> plan on redirecting outbound traffic destined for port 25 to this server
                    >>>> - then I want to check that the email is at least addressed *from* my
                    >>>> clients' domains. I can do this with smtpd_restriction_classes, but the
                    >>>> problem is some clients have their own servers which forward email out
                    >>>> to other accounts eg hotmail. These emails have the clients address as
                    >>>> the recipient address, but could be anything as the sender. This could
                    >>>> equally be done with restriction classes, but I can't figure how to make
                    >>>> it work if either of them matches? The only way I can see to make it
                    >>>> work is to hand the email off to a script setup similarly to
                    >>>> greylisting, but I'd prefer to do it all within Postfix if possible.
                    >>>>
                    >>>>
                    >>>> I haven't managed to turn anything up in list archives that matches what
                    >>>> I'm trying to do, but surely somebody else must have done similar?
                    >>>>
                    >>> Why won't your objective be met by the use of SMTP AUTH and common
                    >>> spam filtering techniques? Your proposed solution sounds overly complex
                    >>> and prone to errors.
                    >>>
                    >> Thanks for the suggestion.
                    >>
                    >> It would mostly meet the requirement, but I've tried SMTP AUTH on a
                    >> small scale for 3 months with a select group of more technically clued
                    >> users, but most of the users seem unable to follow any instruction on
                    >> setting up MUAs etc - I want something that would be completely seamless
                    >> to the users, and only stop stuff I *know* is wrong, rather than risking
                    >> false-positive on outgoing mail. If I can get it right it appears to me
                    >> I run 0% risk of false positives (I accept some spam could sneak
                    >> through, but I'm trying to minimise the risk, not eliminate it)
                    >>
                    >> I can't use POP-before-smtp since not all of my clients are collecting
                    >> mail from my pop servers - some have it direct delivered to their own
                    >> servers.
                    >>
                    >>
                    >
                    >
                    > at some point, they configure their "outgoing mail server". at that same
                    > time, they could set the port to 587 instead of 25. even without auth,
                    > this will make your life easier.
                    >

                    Yes, there would be no problem with that (well not insurmountable ones).
                    but that doesn't achieve what I want, which is to do some sanity
                    checking on the emails they're sending. The IP they connect fom issue is
                    actually largely irrelevant, I can firewall off my relay from everyone
                    except the range I'm interested in. This reduces the problem to "either
                    the mail has to come from domain in this list OR it has to be going to a
                    domain in this list", but it's that OR I can't do.

                    Regards

                    Pete
                  • Scott Kitterman
                    On Thursday 27 September 2007 14:44, Pete Barnwell wrote: the range I m interested in. This reduces the problem to either ... That can fairly trivially be
                    Message 9 of 20 , Sep 27, 2007
                    • 0 Attachment
                      On Thursday 27 September 2007 14:44, Pete Barnwell wrote:
                      the range I'm interested in. This reduces the problem to "either
                      > the mail has to come from domain in this list OR it has to be going to a
                      > domain in this list", but it's that OR I can't do.

                      That can fairly trivially be done in a policy server.

                      Scott K
                    • Steven F Siirila
                      ... How about malware on computers within your netblock sending out spam via your (possibly well-known) mail relay server? That cannot happen in our
                      Message 10 of 20 , Sep 27, 2007
                      • 0 Attachment
                        On Thu, Sep 27, 2007 at 07:40:24PM +0100, Pete Barnwell wrote:
                        > Jorey Bump wrote:
                        > > Pete Barnwell wrote, at 09/27/2007 01:47 PM:
                        > >
                        > >> It would mostly meet the requirement, but I've tried SMTP AUTH on a
                        > >> small scale for 3 months with a select group of more technically clued
                        > >> users, but most of the users seem unable to follow any instruction on
                        > >> setting up MUAs etc - I want something that would be completely seamless
                        > >> to the users, and only stop stuff I *know* is wrong, rather than risking
                        > >> false-positive on outgoing mail. If I can get it right it appears to me
                        > >> I run 0% risk of false positives (I accept some spam could sneak
                        > >> through, but I'm trying to minimise the risk, not eliminate it)
                        > >>
                        > >> I can't use POP-before-smtp since not all of my clients are collecting
                        > >> mail from my pop servers - some have it direct delivered to their own
                        > >> servers.
                        > >
                        > > Bite the bullet, and enforce SMTP AUTH. You do your users a disservice
                        > > by ignoring universally adopted solutions to common problems. Yes,
                        > > it's true, even today I had to troubleshoot a relaying problem for a
                        > > user who continually forgets to configure his MUA to authenticate (and
                        > > who is, in fact, a computer professional), but all of the alternatives
                        > > you are contemplating raise bright red security flags and expose your
                        > > system to risk. It's not worth the price for a few clueless users.
                        > >
                        > What security risks am I running if I managed to implement my proposed
                        > setup? The *almost* universal solution here is to simply relay anything
                        > from within our netblock, without doing any sanity checking on it at
                        > all. We do use SMTP AUTH for road-warrior users who grab whatever
                        > connection they can, but for fixed (within my range) IP DSL clients the
                        > usual solution is to let them send what they want.

                        How about malware on computers within your netblock sending out spam
                        via your (possibly well-known) mail relay server? That cannot happen
                        in our environment, as we require either:

                        1) Registration of an IP address to allow non-AUTH SMTP sessions, or

                        2) SMTP AUTH

                        and of course we use the standard submission port, 587.

                        > If I am missing something please let me know ;-)
                        >
                        > Pete

                        --

                        Steven F. Siirila Office: Univ Park Plaza, Room 750
                        Internet Services E-mail: sfs@...
                        Office of Information Technology Voice: (612) 626-0244
                        University of Minnesota Fax: (612) 626-7593
                      • Noel Jones
                        ... Postfix can t make aliasing or routing decisions based on the client IP. I think your best choice is to have these servers point directly to your exchange
                        Message 11 of 20 , Sep 27, 2007
                        • 0 Attachment
                          At 01:16 PM 9/27/2007, Vadim Pushkin wrote:
                          >Greetings All;
                          >
                          >I have two Postfix servers, one on a DMZ, it accepts all email for
                          >my domains and sends email internal to another postfix server.
                          >
                          >The internal postfix server resends based on the recipients email
                          >address, uses aliases for this purpose.
                          >Some of the domains, just two actually, get all email to another
                          >SMTP server, based on what is in the postfix transport map.
                          >
                          >I am looking to know if it is possible to do the following within my
                          >postfix set up:
                          >
                          >If a source IP address connecting to my internal mailserver is
                          >listed in say a flatfile, then DO NOT use the aliases file at all,
                          >instead simply forward whatever it is trying to send to another SMTP
                          >server, actually an exchange bridgehead in this case.
                          >
                          >We are trying to implement a DL which will be different from one
                          >domain to another, and the above is required.
                          >
                          >Many thanks in advance.
                          >
                          >.vp

                          Postfix can't make aliasing or routing decisions based on the client IP.

                          I think your best choice is to have these servers point directly to
                          your exchange bridgehead, rather than force postfix to jump hoops.

                          If you must do this in postfix, you will need to run a second
                          instance of postfix (with its own queue and config directories - not
                          just another smptd listener defined in master.cf) on another IP or
                          port. Configure that instance to only accept mail from these special
                          servers and add transport_maps entries to route the mail as
                          required. If the special servers must submit mail to the official
                          IP:port, you will need to use firewall rules to redirect them to the
                          proper postfix instance. This is pretty messy; hope you can find
                          some way to avoid it.

                          --
                          Noel Jones
                        • Jorey Bump
                          ... I think our knee-jerk reaction to this concerns your intention to base a security mechanism on easily forged, user-supplied data. Even though you mitigate
                          Message 12 of 20 , Sep 27, 2007
                          • 0 Attachment
                            Pete Barnwell wrote, at 09/27/2007 02:44 PM:

                            > Yes, there would be no problem with that (well not insurmountable ones).
                            > but that doesn't achieve what I want, which is to do some sanity
                            > checking on the emails they're sending. The IP they connect fom issue is
                            > actually largely irrelevant, I can firewall off my relay from everyone
                            > except the range I'm interested in. This reduces the problem to "either
                            > the mail has to come from domain in this list OR it has to be going to a
                            > domain in this list", but it's that OR I can't do.

                            I think our knee-jerk reaction to this concerns your intention to base a
                            security mechanism on easily forged, user-supplied data. Even though you
                            mitigate this by restricting the network, it's still hard for us to
                            accept it as good practice when much better alternatives are available,
                            especially when considering your stated goals. It's fine to develop and
                            apply additional policy, but don't do it as a replacement for
                            tried-and-true methods. The configuration that most of us consider as
                            basic already seems to meet your needs without inconveniencing your
                            users any more than any other email provider.
                          • Pete Barnwell
                            ... OK - let s explore a little (since I m thinking I didn t explain my reasoning properly):- Assume I set everything up to use SMTP auth, and client s machine
                            Message 13 of 20 , Sep 27, 2007
                            • 0 Attachment
                              Jorey Bump wrote:
                              > Pete Barnwell wrote, at 09/27/2007 02:44 PM:
                              >
                              >> Yes, there would be no problem with that (well not insurmountable ones).
                              >> but that doesn't achieve what I want, which is to do some sanity
                              >> checking on the emails they're sending. The IP they connect fom issue is
                              >> actually largely irrelevant, I can firewall off my relay from everyone
                              >> except the range I'm interested in. This reduces the problem to "either
                              >> the mail has to come from domain in this list OR it has to be going to a
                              >> domain in this list", but it's that OR I can't do.
                              >
                              > I think our knee-jerk reaction to this concerns your intention to base
                              > a security mechanism on easily forged, user-supplied data. Even though
                              > you mitigate this by restricting the network, it's still hard for us
                              > to accept it as good practice when much better alternatives are
                              > available, especially when considering your stated goals. It's fine to
                              > develop and apply additional policy, but don't do it as a replacement
                              > for tried-and-true methods. The configuration that most of us consider
                              > as basic already seems to meet your needs without inconveniencing your
                              > users any more than any other email provider.
                              >

                              OK - let's explore a little (since I'm thinking I didn't explain my
                              reasoning properly):-

                              Assume I set everything up to use SMTP auth, and client's machine gets
                              hijacked - there's absolutely nothing to stop malware etc using Outlook
                              to send out whatever emails it wants, with any email addresses both to
                              and from, since Outlook has all the authentication info required stored
                              in it. So in this case all SMTP auth does is confirm that it's a valid
                              user attempting to relay (but I can safely assume that anyway from the
                              IP address they're connecting from - if I wanted the username I could
                              get it from RADIUS session info at a pinch since they've *already*
                              authenticated to get an Internet connection) This would only work to
                              meet my requirement if *no* malware/viruses (present/past/future) used
                              Outlook to send messages from, but rather used their own built in smtp
                              engine. Since they don't (a lot harvest the address book in Outlook to
                              get their to/from anyway) then using SMTP AUTH gets me nowhere - to meet
                              my original requirement I'd still want to provide the filtering *as
                              well*, all I'd do is introduce another level of complexity with SMTP
                              AUTH, and probably support calls would go through the roof, assuming
                              most of our clients didn't simply move to an 'easier' ISP.

                              The fact is that most ISPs (in the Uk at least) will let their users
                              send anything through their relay servers, providing the user is
                              connected via the ISPs network - I'm trying to tighten up on that,
                              without raising the bar for users making things work.

                              I see where you're coming from, but I think I haven't explained well
                              enough what I'm trying to do...

                              Regards

                              Pete
                            • Pete Barnwell
                              ... Unless I m mis-reading this (1) is exactly what I m trying to avoid - under this setup if the IP is registered then you ll accept anything from them,
                              Message 14 of 20 , Sep 27, 2007
                              • 0 Attachment
                                > How about malware on computers within your netblock sending out spam
                                > via your (possibly well-known) mail relay server? That cannot happen
                                > in our environment, as we require either:
                                >
                                > 1) Registration of an IP address to allow non-AUTH SMTP sessions, or
                                >
                                > 2) SMTP AUTH
                                >
                                > and of course we use the standard submission port, 587.
                                >

                                Unless I'm mis-reading this (1) is exactly what I'm trying to avoid -
                                under this setup if the IP is registered then you'll accept anything
                                from them, including spam from a compromised machine.

                                Similarly SMTP AUTH doesn't help when the malware uses Outlook to send
                                it's crap out, since Outlook has the auth details in it.

                                I'm essentially wanting to add 'in top' to catch things that would
                                otherwise be sent.

                                Regards

                                Pete
                              • mouss
                                ... and would you throttle the IPs if one user gets infected? with authentication, you can throttle the user, you can get knowledge about his sending
                                Message 15 of 20 , Sep 27, 2007
                                • 0 Attachment
                                  Pete Barnwell wrote:
                                  > Jorey Bump wrote:
                                  >> Pete Barnwell wrote, at 09/27/2007 02:44 PM:
                                  >>
                                  >>> Yes, there would be no problem with that (well not insurmountable ones).
                                  >>> but that doesn't achieve what I want, which is to do some sanity
                                  >>> checking on the emails they're sending. The IP they connect fom issue is
                                  >>> actually largely irrelevant, I can firewall off my relay from everyone
                                  >>> except the range I'm interested in. This reduces the problem to "either
                                  >>> the mail has to come from domain in this list OR it has to be going to a
                                  >>> domain in this list", but it's that OR I can't do.
                                  >> I think our knee-jerk reaction to this concerns your intention to base
                                  >> a security mechanism on easily forged, user-supplied data. Even though
                                  >> you mitigate this by restricting the network, it's still hard for us
                                  >> to accept it as good practice when much better alternatives are
                                  >> available, especially when considering your stated goals. It's fine to
                                  >> develop and apply additional policy, but don't do it as a replacement
                                  >> for tried-and-true methods. The configuration that most of us consider
                                  >> as basic already seems to meet your needs without inconveniencing your
                                  >> users any more than any other email provider.
                                  >>
                                  >
                                  > OK - let's explore a little (since I'm thinking I didn't explain my
                                  > reasoning properly):-
                                  >
                                  > Assume I set everything up to use SMTP auth, and client's machine gets
                                  > hijacked - there's absolutely nothing to stop malware etc using Outlook
                                  > to send out whatever emails it wants, with any email addresses both to
                                  > and from, since Outlook has all the authentication info required stored
                                  > in it. So in this case all SMTP auth does is confirm that it's a valid
                                  > user attempting to relay (but I can safely assume that anyway from the
                                  > IP address they're connecting from - if I wanted the username I could
                                  > get it from RADIUS session info at a pinch since they've *already*
                                  > authenticated to get an Internet connection) This would only work to
                                  > meet my requirement if *no* malware/viruses (present/past/future) used
                                  > Outlook to send messages from, but rather used their own built in smtp
                                  > engine. Since they don't (a lot harvest the address book in Outlook to
                                  > get their to/from anyway) then using SMTP AUTH gets me nowhere - to meet
                                  > my original requirement I'd still want to provide the filtering *as
                                  > well*, all I'd do is introduce another level of complexity with SMTP
                                  > AUTH, and probably support calls would go through the roof, assuming
                                  > most of our clients didn't simply move to an 'easier' ISP.

                                  and would you throttle the IPs if one user gets infected?

                                  with authentication, you can throttle the user, you can get knowledge
                                  about his sending habits/ratios/... that can in turn allow you to
                                  suspend/throttle the account if something bad is noticed.

                                  will you do so with the IPs in question? would you throttle an IP (which
                                  is either that of an ISP, and is thus shared, or it is that of a user,
                                  and it may be reallocated). Of course, if the IP is static and bleongs
                                  to one user, then that's some form of (weak) authentication. but this is
                                  not my understanding of your situation.

                                  >
                                  > The fact is that most ISPs (in the Uk at least) will let their users
                                  > send anything through their relay servers, providing the user is
                                  > connected via the ISPs network - I'm trying to tighten up on that,
                                  > without raising the bar for users making things work.
                                  >
                                  > I see where you're coming from, but I think I haven't explained well
                                  > enough what I'm trying to do...
                                  >


                                  you've been warned. now, achieving what you asked for should be trivial
                                  since you can do each of the conditions. and OR can be converted to a
                                  sequence:

                                  if (foo OR bar) then OK
                                  is the same as
                                  if (foo) then OK
                                  if (bar) then OK

                                  so putting one check after the other solves the problem.

                                  but relaying mail based on the sender is highly risky.
                                • Steven F Siirila
                                  ... (1) assumes a static IP. In such a case, that IP can be shut down easily until the responsible party fixes their box. ... (2) assumes a dynamic IP
                                  Message 16 of 20 , Sep 27, 2007
                                  • 0 Attachment
                                    On Thu, Sep 27, 2007 at 10:16:10PM +0100, Pete Barnwell wrote:
                                    >
                                    > > How about malware on computers within your netblock sending out spam
                                    > > via your (possibly well-known) mail relay server? That cannot happen
                                    > > in our environment, as we require either:
                                    > >
                                    > > 1) Registration of an IP address to allow non-AUTH SMTP sessions, or
                                    > >
                                    > > 2) SMTP AUTH
                                    > >
                                    > > and of course we use the standard submission port, 587.
                                    > >
                                    >
                                    > Unless I'm mis-reading this (1) is exactly what I'm trying to avoid -
                                    > under this setup if the IP is registered then you'll accept anything
                                    > from them, including spam from a compromised machine.

                                    (1) assumes a static IP. In such a case, that IP can be shut down easily
                                    until the responsible party fixes their box.

                                    > Similarly SMTP AUTH doesn't help when the malware uses Outlook to send
                                    > it's crap out, since Outlook has the auth details in it.

                                    (2) assumes a dynamic IP generally, but doesn't have to.
                                    You allow your users to save their credentials in Outlook?
                                    Even if you do, you have the ability to turn off the user's ability to
                                    authenticate to the SMTP gateway until they fix their box.

                                    Both (1) and (2) are meant to tie a user to the SMTP sessions in order
                                    to allow abuse to be stopped in its tracks.

                                    > I'm essentially wanting to add 'in top' to catch things that would
                                    > otherwise be sent.
                                    >
                                    > Regards
                                    >
                                    > Pete

                                    --

                                    Steven F. Siirila Office: Univ Park Plaza, Room 750
                                    Internet Services E-mail: sfs@...
                                    Office of Information Technology Voice: (612) 626-0244
                                    University of Minnesota Fax: (612) 626-7593
                                  • Jorey Bump
                                    ... Allowing relaying by IP address is vastly more permissive than requiring individual user authentication. Being an open relay for all hosts in your network
                                    Message 17 of 20 , Sep 27, 2007
                                    • 0 Attachment
                                      Pete Barnwell wrote, at 09/27/2007 05:13 PM:

                                      > OK - let's explore a little (since I'm thinking I didn't explain my
                                      > reasoning properly):-
                                      >
                                      > Assume I set everything up to use SMTP auth, and client's machine gets
                                      > hijacked - there's absolutely nothing to stop malware etc using Outlook
                                      > to send out whatever emails it wants, with any email addresses both to
                                      > and from, since Outlook has all the authentication info required stored
                                      > in it. So in this case all SMTP auth does is confirm that it's a valid
                                      > user attempting to relay (but I can safely assume that anyway from the
                                      > IP address they're connecting from - if I wanted the username I could
                                      > get it from RADIUS session info at a pinch since they've *already*
                                      > authenticated to get an Internet connection)

                                      Allowing relaying by IP address is vastly more permissive than requiring
                                      individual user authentication. Being an open relay for all hosts in
                                      your network may allow you to identify the originating IP, but it
                                      doesn't mean an authorized user is relaying. SMTP AUTH certainly raises
                                      the bar and provides an audit trail. Besides, you don't need to include
                                      these hosts in $mynetworks when you provide and enforce SMTP AUTH.

                                      > This would only work to
                                      > meet my requirement if *no* malware/viruses (present/past/future) used
                                      > Outlook to send messages from, but rather used their own built in smtp
                                      > engine. Since they don't (a lot harvest the address book in Outlook to
                                      > get their to/from anyway) then using SMTP AUTH gets me nowhere.

                                      I imagine most malware falls into these categories:

                                      1. Make direct connections to recipient's MX.
                                      2. Obtain a list of useable relays.
                                      3. Search network for unsecured relays.
                                      4. Subvert an exploitable client, possibly using stored credentials.

                                      The first and second can be fought with firewalls, and the third is
                                      remedied by SMTP AUTH. The fourth is probably the least common, and
                                      requires active vigilance on the part of the user. But you can cut off
                                      the user if their account is compromised and you are using SMTP AUTH.

                                      > - to meet
                                      > my original requirement I'd still want to provide the filtering *as
                                      > well*, all I'd do is introduce another level of complexity with SMTP
                                      > AUTH, and probably support calls would go through the roof, assuming
                                      > most of our clients didn't simply move to an 'easier' ISP.
                                      > The fact is that most ISPs (in the Uk at least) will let their users
                                      > send anything through their relay servers, providing the user is
                                      > connected via the ISPs network - I'm trying to tighten up on that,
                                      > without raising the bar for users making things work.

                                      SMTP AUTH is de rigeur, these days. A few years ago, Verizon attempted
                                      to 'secure' their network by allowing relaying only if their domain was
                                      in the From: header, and they quickly became a source of spam and the
                                      laughingstock of the industry. This could have been avoided simply by
                                      giving users the SMTP AUTH and STARTTLS they were begging for (I was
                                      among those users). Don't make the same mistake.

                                      > I see where you're coming from, but I think I haven't explained well
                                      > enough what I'm trying to do...

                                      I think you're obsessing on fringe cases without giving established and
                                      recommended best practices a reasonable evaluation. Your problem isn't
                                      special, and most of us have solved the bulk of it by implementing SMTP
                                      AUTH, STARTTLS and various kinds of filtering, all without alienating
                                      our users.
                                    • Charles Marcus
                                      ... How exactly would you *prevent* them from doing so?
                                      Message 18 of 20 , Sep 27, 2007
                                      • 0 Attachment
                                        On 9/27/2007 Steven F Siirila wrote:
                                        > You allow your users to save their credentials in Outlook?

                                        How exactly would you *prevent* them from doing so?
                                      • Steven F Siirila
                                        ... It s a matter of education and policy. You can t prevent them from shooting themselves in the foot. -- Steven F. Siirila Office: Univ Park Plaza, Room
                                        Message 19 of 20 , Sep 28, 2007
                                        • 0 Attachment
                                          On Thu, Sep 27, 2007 at 10:48:59PM -0400, Charles Marcus wrote:
                                          > On 9/27/2007 Steven F Siirila wrote:
                                          > >You allow your users to save their credentials in Outlook?
                                          >
                                          > How exactly would you *prevent* them from doing so?

                                          It's a matter of education and policy. You can't prevent them from
                                          shooting themselves in the foot.

                                          --

                                          Steven F. Siirila Office: Univ Park Plaza, Room 750
                                          Internet Services E-mail: sfs@...
                                          Office of Information Technology Voice: (612) 626-0244
                                          University of Minnesota Fax: (612) 626-7593
                                        • Charles Marcus
                                          ... Normal people do not consider saving the account password shooting themselves in the foot - they consider it a massively major convenience. And since
                                          Message 20 of 20 , Sep 28, 2007
                                          • 0 Attachment
                                            On 9/28/2007, Steven F Siirila (sfs@...) wrote:
                                            >>>You allow your users to save their credentials in Outlook?

                                            >> How exactly would you *prevent* them from doing so?

                                            > It's a matter of education and policy. You can't prevent them from
                                            > shooting themselves in the foot.

                                            Normal people do not consider saving the account password 'shooting
                                            themselves in the foot' - they consider it a massively major convenience.

                                            And since such a policy is impossible to enforce, it is, in my mind,
                                            totally useless and even stupid.

                                            --

                                            Best regards,

                                            Charles
                                          Your message has been successfully submitted and would be delivered to recipients shortly.