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

Re: Whitelisting Redux

Expand Messages
  • Jorey Bump
    ... Is it possible to use the GUI for these purposes without messing up your manual Postfix configuration? It seems that the folks at Apple took the
    Message 1 of 17 , Apr 30, 2007
      Dennis Putnam wrote:
      > On Apr 30, 2007, at 10:45 AM, Jorey Bump wrote:
      >
      >> Stop using the GUI. It is too inflexible for your needs.
      >
      > Not that simple. Some things (unrelated to postfix) can only be done via
      > the GUI.

      Is it possible to use the GUI for these purposes without messing up your
      manual Postfix configuration?

      It seems that the folks at Apple took the smtpd_*_restrictions far too
      literally when designing the GUI. If it prevents you from exempting your
      authenticated users from RBL checks (your postconf output indicates
      this), you'll have no choice but to seek an alternative means of
      administration. Since I don't use OS X, I'll leave it to others who do
      to make a suggestion. FWIW, your problem is easily solved with a
      properly constructed (and not too complicated) main.cf, so it appears
      that the GUI represents your biggest hurdle.
    • Jason Pruim
      ... I think you might be slightly confused by what the Apple GUI does. You can stop using it for one service and still use it for others. I currently run the
      Message 2 of 17 , Apr 30, 2007
        On Apr 30, 2007, at 11:58 AM, Dennis Putnam wrote:


        >>
        >> Stop using the GUI. It is too inflexible for your needs.
        >
        > Not that simple. Some things (unrelated to postfix) can only be
        > done via the GUI.
        >

        I think you might be slightly confused by what the Apple GUI does.
        You can stop using it for one service and still use it for others. I
        currently run the GUI on everything BUT Postfix and DNS as I have
        made my own changes to it. All I'll do with the Apple GUI on those
        services now is start/stop it, and look at logs if I'm not in terminal.

        That being said, I can't help with the actual problem, just wanted to
        chime in on what Apple has done, and for the record, the postfix GUI
        that apple has is okay, for the most basic tasks, once you want to
        start blocking spam, and adding things like Grey Listing, you have to
        do it by hand. Same with the DNS, but that's out of the scope of this
        list :)


        --

        Jason Pruim
        japruim@...
        Production & Technology Manager
        MQC Specialist (2005 certified)
        3251 132nd Ave
        Holland MI 49424
        616.399.2355
        www.raoset.com


        "But when a long train of abuses and usurpations, pursuing invariably
        the same Object evinces a design to reduce them under absolute
        Despotism, it is their right, it is their duty, to throw off such
        Government, and to provide new Guards for their future security."
      • Dennis Putnam
        ... Sort of. I have it now so the GUI leaves it alone (with a couple of insignificant settings) until an Apple update is applied (I save the real file until
        Message 3 of 17 , Apr 30, 2007
          On Apr 30, 2007, at 12:52 PM, Jorey Bump wrote:

          > Dennis Putnam wrote:
          >> On Apr 30, 2007, at 10:45 AM, Jorey Bump wrote:
          >>> Stop using the GUI. It is too inflexible for your needs.
          >> Not that simple. Some things (unrelated to postfix) can only be
          >> done via the GUI.
          >
          > Is it possible to use the GUI for these purposes without messing up
          > your manual Postfix configuration?

          Sort of. I have it now so the GUI leaves it alone (with a couple of
          insignificant settings) until an Apple update is applied (I save the
          real file until after the update). Unfortunately, someone else did an
          update unaware of the problem. It was not until all the backups were
          over written that I learned the latest file was changed and a copy
          not made.

          >
          > It seems that the folks at Apple took the smtpd_*_restrictions far
          > too literally when designing the GUI. If it prevents you from
          > exempting your authenticated users from RBL checks (your postconf
          > output indicates this), you'll have no choice but to seek an
          > alternative means of administration. Since I don't use OS X, I'll
          > leave it to others who do to make a suggestion. FWIW, your problem
          > is easily solved with a properly constructed (and not too
          > complicated) main.cf, so it appears that the GUI represents your
          > biggest hurdle.
          >
          >

          It is a headache because Apple does not support everything via the
          GUI (if you call about a problem when you do it manually they make
          you buy a different service contract). They only support what they
          decided us admin's need (some of what they do is dead wrong). Anyway
          if I can get it back to where it is supposed to be manually, I'll be
          OK (I had a little chat with a certain admin). What are you seeing
          wrong with the postconf output? The check_sender_access is there and
          points to the right file.
        • Dennis Putnam
          ... I do the same but the problem is when I do updates it messed things up. Normally I make copies of the requisite files then restore then after the updates.
          Message 4 of 17 , Apr 30, 2007
            On Apr 30, 2007, at 1:09 PM, Jason Pruim wrote:

            >
            > On Apr 30, 2007, at 11:58 AM, Dennis Putnam wrote:
            >
            >
            >>>
            >>> Stop using the GUI. It is too inflexible for your needs.
            >>
            >> Not that simple. Some things (unrelated to postfix) can only be
            >> done via the GUI.
            >>
            >
            > I think you might be slightly confused by what the Apple GUI does.
            > You can stop using it for one service and still use it for others.
            > I currently run the GUI on everything BUT Postfix and DNS as I have
            > made my own changes to it. All I'll do with the Apple GUI on those
            > services now is start/stop it, and look at logs if I'm not in
            > terminal.
            >
            > That being said, I can't help with the actual problem, just wanted
            > to chime in on what Apple has done, and for the record, the postfix
            > GUI that apple has is okay, for the most basic tasks, once you want
            > to start blocking spam, and adding things like Grey Listing, you
            > have to do it by hand. Same with the DNS, but that's out of the
            > scope of this list :)
            >

            I do the same but the problem is when I do updates it messed things
            up. Normally I make copies of the requisite files then restore then
            after the updates. As I said previously, that did not happen in this
            case.
          • Jorey Bump
            ... You ll need a good backup or version control system for insurance against future mishaps. ... I prefer to put my RBLs at the end of
            Message 5 of 17 , Apr 30, 2007
              Dennis Putnam wrote:

              > Anyway if I can get
              > it back to where it is supposed to be manually, I'll be OK

              You'll need a good backup or version control system for insurance
              against future mishaps.

              > What are you seeing wrong with the
              > postconf output? The check_sender_access is there and points to the
              > right file.

              I prefer to put my RBLs at the end of smtpd_recipient_restrictions and
              exempt anything I need before it (also in smtpd_recipient_restrictions).
              I don't change the other smtpd_*_restrictions from their defaults, but
              if I did, I'd try to use them only for obvious rejections. This is a
              matter of taste. I typically use this configuration:

              smtpd_recipient_restrictions =
              reject_non_fqdn_sender
              reject_unlisted_sender
              reject_unknown_sender_domain
              reject_unknown_recipient_domain
              reject_unlisted_recipient
              permit_mynetworks
              permit_sasl_authenticated
              reject_unauth_destination
              check_helo_access pcre:/etc/postfix/helo
              check_sender_access hash:/etc/postfix/sender
              reject_rbl_client rbl1.example.org
              reject_rbl_client rbl2.example.net

              The check_*_access files are custom, and currently contain only
              rejections. You may need to put yours before the permit_* statements, if
              you truly need a whitelist. If your problem user is actually an
              authenticated user that is being blocked by an RBL, you no longer need a
              whitelist with the above configuration, as this is handled by placing
              permit_sasl_authenticated before the RBLs.

              Also note: This configuration assumes that smtpd_delay_reject = yes,
              which is normally the Postfix default (I don't know what the case is
              with OS X).
            • mouss
              ... well, you have the choice between 1- complain to the vendor (you should anyway do this to help improving their package) 2- try to fix what you can. This
              Message 6 of 17 , Apr 30, 2007
                Dennis Putnam wrote:
                >
                >

                well, you have the choice between

                1- complain to the vendor (you should anyway do this to help improving
                their package)

                2- try to fix what you can. This means you need to understand how the
                stuff works and find workarounds. one way is to write a "post-fix"
                procedure that fixes what the update has broken.

                3- stop using the gui, and configure postfix to use a config directory
                that won't be modified by later updates.

                4- use another system...
              • Adam Jacob Muller
                ... Unfortunately, this is highly unlikely to get him anywhere. Apple is rather intransigent, their way is the right way and if your way doesn t fit into their
                Message 7 of 17 , Apr 30, 2007
                  On Apr 30, 2007, at 4:23 PM, mouss wrote:

                  > Dennis Putnam wrote:
                  >>
                  >>
                  >
                  > well, you have the choice between
                  >
                  > 1- complain to the vendor (you should anyway do this to help
                  > improving their package)

                  Unfortunately, this is highly unlikely to get him anywhere. Apple is
                  rather intransigent, their way is the right way and if your way
                  doesn't fit into their preconceived notions they assume you are wrong
                  and should change your notions, in this case, why would you want to
                  relay mail for people on spam blacklists, they are obviously up to no
                  good (PBL be damned)! :P

                  >
                  > 2- try to fix what you can. This means you need to understand how
                  > the stuff works and find workarounds. one way is to write a "post-
                  > fix" procedure that fixes what the update has broken.
                  >
                  > 3- stop using the gui, and configure postfix to use a config
                  > directory that won't be modified by later updates.
                  >

                  Good idea if you can't follow #4

                  > 4- use another system...
                  >

                  I'm actually curious as to why your using OSX to run postfix in the
                  first place, it's nice enough to configure postfix just to get some
                  outbound mail running, but beyond that, get a real mail server....

                  - Adam
                • Dennis Putnam
                  ... I thought I did but it is only as good as the people that follow the procedure. ... I took your advice and modified (best I could as it appears you are
                  Message 8 of 17 , May 1, 2007
                    On Apr 30, 2007, at 2:15 PM, Jorey Bump wrote:

                    > Dennis Putnam wrote:
                    >
                    > You'll need a good backup or version control system for insurance
                    > against future mishaps.

                    I thought I did but it is only as good as the people that follow the
                    procedure.

                    >
                    > I prefer to put my RBLs at the end of smtpd_recipient_restrictions
                    > and exempt anything I need before it (also in
                    > smtpd_recipient_restrictions). I don't change the other
                    > smtpd_*_restrictions from their defaults, but if I did, I'd try to
                    > use them only for obvious rejections. This is a matter of taste. I
                    > typically use this configuration:
                    >
                    > smtpd_recipient_restrictions =
                    > reject_non_fqdn_sender
                    > reject_unlisted_sender
                    > reject_unknown_sender_domain
                    > reject_unknown_recipient_domain
                    > reject_unlisted_recipient
                    > permit_mynetworks
                    > permit_sasl_authenticated
                    > reject_unauth_destination
                    > check_helo_access pcre:/etc/postfix/helo
                    > check_sender_access hash:/etc/postfix/sender
                    > reject_rbl_client rbl1.example.org
                    > reject_rbl_client rbl2.example.net
                    >
                    > The check_*_access files are custom, and currently contain only
                    > rejections. You may need to put yours before the permit_*
                    > statements, if you truly need a whitelist. If your problem user is
                    > actually an authenticated user that is being blocked by an RBL, you
                    > no longer need a whitelist with the above configuration, as this is
                    > handled by placing permit_sasl_authenticated before the RBLs.

                    I took your advice and modified (best I could as it appears you are
                    using v 2.3, I think mine is 2.1) my main.cf to match. Unfortunately
                    the 'check_sender_access' is still not working. My problem user is
                    not an authenticated one, it is just one that happens to have an ISP
                    that is too arrogant to accept and act on spam reports. Perhaps the
                    problem is versioning. Here is a new 'postconf -n' and thanks again
                    for your help.

                    alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
                    command_directory = /usr/sbin
                    config_directory = /etc/postfix
                    content_filter = smtp-amavis:[127.0.0.1]:10024
                    daemon_directory = /usr/libexec/postfix
                    debug_peer_level = 2
                    enable_server_options = yes
                    html_directory = no
                    inet_interfaces = all
                    mail_owner = postfix
                    mailbox_size_limit = 0
                    mailbox_transport = cyrus
                    mailq_path = /usr/bin/mailq
                    manpage_directory = /usr/share/man
                    message_size_limit = 26214400
                    mydestination = $myhostname,localhost.
                    $mydomain,localhost,xserveoda.aimaudit.com,mail.aimaudit.com,aimaudit.co
                    m
                    mydomain = aimaudit.com
                    mydomain_fallback = localhost
                    myhostname = xserveoda.aimaudit.com
                    mynetworks =
                    127.0.0.1/32,66.255.181.64/28,72.158.55.128/27,70.158.194.0/24,192.168.0
                    .0/24
                    mynetworks_style = host
                    newaliases_path = /usr/bin/newaliases
                    owner_request_special = no
                    queue_directory = /private/var/spool/postfix
                    readme_directory = /usr/share/doc/postfix
                    recipient_delimiter = +
                    sample_directory = /usr/share/doc/postfix/examples
                    sendmail_path = /usr/sbin/sendmail
                    setgid_group = postdrop
                    smtpd_client_restrictions = reject_non_fqdn_sender
                    reject_unknown_sender_domain check_sender_access hash:/etc/postfix/
                    sender_whitelist permit_mynetworks
                    permit_sasl_authenticated reject_unauth_destination
                    reject_rbl_client bl.spamcop.net reject_rbl_client
                    dnsbl.sorbs.net reject_rbl_client cbl.abuseat.org
                    reject_rbl_client dnsbl.njabl.org check_client_access hash:/etc/
                    postfix/smtpdreject
                    smtpd_helo_required = yes
                    smtpd_helo_restrictions = reject_unknown_client
                    smtpd_pw_server_security_options = gssapi,login
                    smtpd_recipient_restrictions =
                    permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,pe
                    rmit
                    smtpd_sasl_auth_enable = yes
                    smtpd_tls_key_file =
                    smtpd_use_pw_server = yes
                    unknown_local_recipient_reject_code = 550


                    >
                    > Also note: This configuration assumes that smtpd_delay_reject =
                    > yes, which is normally the Postfix default (I don't know what the
                    > case is with OS X).
                    >

                    It is the same. Thanks.
                  • mouss
                    ... now show a log line for the reject.
                    Message 9 of 17 , May 1, 2007
                      Dennis Putnam wrote:
                      >
                      > I took your advice and modified (best I could as it appears you are
                      > using v 2.3, I think mine is 2.1) my main.cf to match. Unfortunately
                      > the 'check_sender_access' is still not working. My problem user is not
                      > an authenticated one, it is just one that happens to have an ISP that
                      > is too arrogant to accept and act on spam reports. Perhaps the problem
                      > is versioning. Here is a new 'postconf -n' and thanks again for your
                      > help.

                      now show a log line for the reject.
                    • Jorey Bump
                      ... You are still using smtpd_client_restrictions, though. Note that my example uses smtpd_recipient_restrictions. All you should need to do now ... You might
                      Message 10 of 17 , May 1, 2007
                        Dennis Putnam wrote:
                        >
                        > On Apr 30, 2007, at 2:15 PM, Jorey Bump wrote:
                        >>
                        >> I prefer to put my RBLs at the end of smtpd_recipient_restrictions and
                        >> exempt anything I need before it (also in
                        >> smtpd_recipient_restrictions). I don't change the other
                        >> smtpd_*_restrictions from their defaults, but if I did, I'd try to use
                        >> them only for obvious rejections. This is a matter of taste. I
                        >> typically use this configuration:
                        >>
                        >> smtpd_recipient_restrictions =
                        >> reject_non_fqdn_sender
                        >> reject_unlisted_sender
                        >> reject_unknown_sender_domain
                        >> reject_unknown_recipient_domain
                        >> reject_unlisted_recipient
                        >> permit_mynetworks
                        >> permit_sasl_authenticated
                        >> reject_unauth_destination
                        >> check_helo_access pcre:/etc/postfix/helo
                        >> check_sender_access hash:/etc/postfix/sender
                        >> reject_rbl_client rbl1.example.org
                        >> reject_rbl_client rbl2.example.net
                        >>
                        >
                        > I took your advice and modified (best I could as it appears you are
                        > using v 2.3, I think mine is 2.1) my main.cf to match. Unfortunately the
                        > 'check_sender_access' is still not working.

                        You are still using smtpd_client_restrictions, though. Note that my
                        example uses smtpd_recipient_restrictions. All you should need to do now
                        is change this to smtpd_recipient_restrictions:

                        > smtpd_client_restrictions = reject_non_fqdn_sender
                        > reject_unknown_sender_domain check_sender_access
                        > hash:/etc/postfix/sender_whitelist permit_mynetworks
                        > permit_sasl_authenticated reject_unauth_destination
                        > reject_rbl_client bl.spamcop.net reject_rbl_client
                        > dnsbl.sorbs.net reject_rbl_client cbl.abuseat.org
                        > reject_rbl_client dnsbl.njabl.org check_client_access
                        > hash:/etc/postfix/smtpdreject

                        And simply delete or comment out this line:

                        > smtpd_recipient_restrictions =
                        > permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,permit

                        You might still have a bit of tweaking to do, but this should give you a
                        working configuration. Be especially careful with what you put in your
                        whitelist. Rejections are easy to manage, but whitelisting can allow
                        unauthorized relaying if done improperly.
                      • Dennis Putnam
                        ... Doh! How dumb was that? ... This creates new problems. I thought I understood what these parameters did from the documentation but clearly I am not
                        Message 11 of 17 , May 1, 2007
                          On May 1, 2007, at 8:44 AM, Jorey Bump wrote:
                          >
                          >
                          > You are still using smtpd_client_restrictions, though. Note that my
                          > example uses smtpd_recipient_restrictions.

                          Doh! How dumb was that?

                          > All you should need to do now is change this to
                          > smtpd_recipient_restrictions:
                          >
                          > And simply delete or comment out this line:
                          >
                          >> smtpd_recipient_restrictions =
                          >> permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
                          >> ,permit

                          This creates new problems. I thought I understood what these
                          parameters did from the documentation but clearly I am not
                          understanding the docs at all. If I remove 'permit_mynetworks' then
                          all outgoing mail gets a relay denied error. If I remove
                          'reject_unauth_destination' I get this:

                          May 1 08:58:20 xserveoda postfix/smtpd[4921]: fatal: parameter
                          "smtpd_recipient_restrictions": specify at least one working instance
                          of: check_relay_domains, reject_unauth_destination, reject, defer or
                          defer_if_permit

                          I guess removing the sasl statement is the only one that doesn't seem
                          to cause a problem. However, my problem user is still a problem.

                          May 1 08:54:35 xserveoda postfix/smtpd[4785]: NOQUEUE: reject: RCPT
                          from imf24aec.mail.bellsouth.net[205.152.59.72]: 554 Service
                          unavailable; Client host [205.152.59.72] blocked using
                          dnsbl.sorbs.net; Spam Received Recently See: http://www.sorbs.net/
                          lookup.shtml?205.152.59.72 / Escalated Listing (Spam or Spam Support)
                          See: http://www.sorbs.net/lookup.shtml?205.152.59.72;
                          from=<dap@...> to=<dennis.putnam@...>
                          proto=ESMTP helo=<imf24aec.mail.bellsouth.net>

                          Here's a new 'postconf -n':

                          alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
                          command_directory = /usr/sbin
                          config_directory = /etc/postfix
                          content_filter = smtp-amavis:[127.0.0.1]:10024
                          daemon_directory = /usr/libexec/postfix
                          debug_peer_level = 2
                          enable_server_options = yes
                          html_directory = no
                          inet_interfaces = all
                          mail_owner = postfix
                          mailbox_size_limit = 0
                          mailbox_transport = cyrus
                          mailq_path = /usr/bin/mailq
                          manpage_directory = /usr/share/man
                          message_size_limit = 26214400
                          mydestination = $myhostname,localhost.
                          $mydomain,localhost,xserveoda.aimaudit.com,mail.aimaudit.com,aimaudit.co
                          m
                          mydomain = aimaudit.com
                          mydomain_fallback = localhost
                          myhostname = xserveoda.aimaudit.com
                          mynetworks =
                          127.0.0.1/32,66.255.181.64/28,72.158.55.128/27,70.158.194.0/24,192.168.0
                          .0/24
                          mynetworks_style = host
                          newaliases_path = /usr/bin/newaliases
                          owner_request_special = no
                          queue_directory = /private/var/spool/postfix
                          readme_directory = /usr/share/doc/postfix
                          recipient_delimiter = +
                          sample_directory = /usr/share/doc/postfix/examples
                          sendmail_path = /usr/sbin/sendmail
                          setgid_group = postdrop
                          smtpd_helo_required = yes
                          smtpd_helo_restrictions = reject_unknown_client
                          smtpd_pw_server_security_options = gssapi,login
                          smtpd_recipient_restrictions = reject_non_fqdn_sender
                          reject_unknown_sender_domain check_sender_access hash:/etc/postfix/
                          sender_whitelist permit_mynetworks
                          reject_unauth_destination reject_rbl_client
                          bl.spamcop.net reject_rbl_client dnsbl.sorbs.net
                          reject_rbl_client cbl.abuseat.org reject_rbl_client
                          dnsbl.njabl.org check_client_access hash:/etc/postfix/smtpdreject
                          smtpd_sasl_auth_enable = yes
                          smtpd_tls_key_file =
                          smtpd_use_pw_server = yes
                          unknown_local_recipient_reject_code = 550


                          >
                          > You might still have a bit of tweaking to do, but this should give
                          > you a working configuration. Be especially careful with what you
                          > put in your whitelist. Rejections are easy to manage, but
                          > whitelisting can allow unauthorized relaying if done improperly.
                          >

                          Could you elaborate a little on this? As long as I don't use
                          wildcards in my white list, am I not safe? Also, just as a refresher,
                          once again here is my current sender_whitelist file:

                          # This is a list of senders that will be accepted even if the server has
                          # been blacklisted.
                          #
                          # REMEMBER to run 'make' after changes
                          #
                          dap1@... permit_auth_destination
                        • Jorey Bump
                          ... Then don t do that. :) ... I m not sure why you re removing permit_sasl_authenticated, but if you don t need it, no harm done. ... It appears your
                          Message 12 of 17 , May 1, 2007
                            Dennis Putnam wrote:
                            > On May 1, 2007, at 8:44 AM, Jorey Bump wrote:
                            >>
                            >> And simply delete or comment out this line:
                            >>
                            >>> smtpd_recipient_restrictions =
                            >>> permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,permit
                            >>>
                            >
                            > This creates new problems. I thought I understood what these parameters
                            > did from the documentation but clearly I am not understanding the docs
                            > at all. If I remove 'permit_mynetworks' then all outgoing mail gets a
                            > relay denied error. If I remove 'reject_unauth_destination' I get this:
                            >
                            > May 1 08:58:20 xserveoda postfix/smtpd[4921]: fatal: parameter
                            > "smtpd_recipient_restrictions": specify at least one working instance
                            > of: check_relay_domains, reject_unauth_destination, reject, defer or
                            > defer_if_permit

                            Then don't do that. :)

                            > I guess removing the sasl statement is the only one that doesn't seem to
                            > cause a problem. However, my problem user is still a problem.

                            I'm not sure why you're removing permit_sasl_authenticated, but if you
                            don't need it, no harm done.

                            > May 1 08:54:35 xserveoda postfix/smtpd[4785]: NOQUEUE: reject: RCPT
                            > from imf24aec.mail.bellsouth.net[205.152.59.72]: 554 Service
                            > unavailable; Client host [205.152.59.72] blocked using dnsbl.sorbs.net;
                            > Spam Received Recently See:
                            > http://www.sorbs.net/lookup.shtml?205.152.59.72 / Escalated Listing
                            > (Spam or Spam Support) See:
                            > http://www.sorbs.net/lookup.shtml?205.152.59.72;
                            > from=<dap@...> to=<dennis.putnam@...>
                            > proto=ESMTP helo=<imf24aec.mail.bellsouth.net>

                            It appears your whitelist is not being consulted. Be sure to issue a
                            'postfix reload' after editing main.cf.

                            > Here's a new 'postconf -n':
                            > smtpd_recipient_restrictions = reject_non_fqdn_sender
                            > reject_unknown_sender_domain check_sender_access
                            > hash:/etc/postfix/sender_whitelist permit_mynetworks
                            > reject_unauth_destination reject_rbl_client bl.spamcop.net
                            > reject_rbl_client dnsbl.sorbs.net reject_rbl_client
                            > cbl.abuseat.org reject_rbl_client dnsbl.njabl.org
                            > check_client_access hash:/etc/postfix/smtpdreject

                            Okay, looks good.

                            > smtpd_sasl_auth_enable = yes
                            > smtpd_tls_key_file =
                            > smtpd_use_pw_server = yes

                            Put permit_sasl_authenticated back before permit_mynetworks in
                            smtpd_recipient_restrictions, if you are using authentication for
                            submission via port 25.

                            >> You might still have a bit of tweaking to do, but this should give you
                            >> a working configuration. Be especially careful with what you put in
                            >> your whitelist. Rejections are easy to manage, but whitelisting can
                            >> allow unauthorized relaying if done improperly.
                            >
                            > Could you elaborate a little on this? As long as I don't use wildcards
                            > in my white list, am I not safe? Also, just as a refresher, once again
                            > here is my current sender_whitelist file:
                            >
                            > # This is a list of senders that will be accepted even if the server has
                            > # been blacklisted.
                            > #
                            > # REMEMBER to run 'make' after changes
                            > #
                            > dap1@... permit_auth_destination

                            This looks fine. Be sure to run 'postmap sender_whitelist' in
                            /etc/postfix, and check your log to be sure there are no associated errors.

                            I've duplicated your configuration (easy, since you've nearly duplicated
                            mine), and it works for me (my residential IP is in one of the RBLs, and
                            I can now send from my home computer using the same format you're
                            using). At this point, you'll need to check your logs for clues, but
                            I'll save you some searching:

                            dap@... != dap1@...

                            If you want to keep things simple, use this in sender_whitelist:

                            bellsouth.net permit_auth_destination

                            That's safe enough, but it means that anyone can bypass the RBL check by
                            forging the envelope sender address as being from bellsouth.net. Not a
                            big deal, here, but an example why I avoid whitelists for lower
                            maintenance solutions. If you're trying to send mail to your server from
                            a dynamic residential IP *without authentication*, then this is as
                            appropriate a solution as any other.

                            Note that you'll have to put your map *after* reject_unauth_destination
                            if you use the bellsouth.net address for outgoing mail (in which case,
                            you should really use their mail server, instead).
                          • Dennis Putnam
                            ... I thought that was what you suggested I do. ... I do/did. Why would the white list not be consulted? ... Except it doesn t work. :-) ... It seems to be
                            Message 13 of 17 , May 1, 2007
                              On May 1, 2007, at 10:06 AM, Jorey Bump wrote:
                              >
                              >
                              > Then don't do that. :)

                              :-)


                              >
                              > I'm not sure why you're removing permit_sasl_authenticated, but if
                              > you don't need it, no harm done.

                              I thought that was what you suggested I do.


                              >
                              > It appears your whitelist is not being consulted. Be sure to issue
                              > a 'postfix reload' after editing main.cf.

                              I do/did. Why would the white list not be consulted?

                              >
                              > Okay, looks good.

                              Except it doesn't work. :-)

                              >
                              > Put permit_sasl_authenticated back before permit_mynetworks in
                              > smtpd_recipient_restrictions, if you are using authentication for
                              > submission via port 25.

                              It seems to be working without it but I will. In any case this is not
                              effecting the white list is it?

                              >
                              > This looks fine. Be sure to run 'postmap sender_whitelist' in /etc/
                              > postfix, and check your log to be sure there are no associated errors.

                              Done.

                              >
                              > I've duplicated your configuration (easy, since you've nearly
                              > duplicated mine), and it works for me (my residential IP is in one
                              > of the RBLs, and I can now send from my home computer using the
                              > same format you're using). At this point, you'll need to check your
                              > logs for clues, but I'll save you some searching:
                              >
                              > dap@... != dap1@...

                              I missed that detail. I didn't think it used the FROM field since
                              that is easily spoofed. The difference is whether the mail originated
                              on a Linux box or Windows box. The bad news is that when I add that
                              to my white list it still doesn't work.

                              >
                              > If you want to keep things simple, use this in sender_whitelist:
                              >
                              > bellsouth.net permit_auth_destination
                              >
                              > That's safe enough, but it means that anyone can bypass the RBL
                              > check by forging the envelope sender address as being from
                              > bellsouth.net. Not a big deal, here, but an example why I avoid
                              > whitelists for lower maintenance solutions. If you're trying to
                              > send mail to your server from a dynamic residential IP *without
                              > authentication*, then this is as appropriate a solution as any other.

                              I don't really want to open it to all but I might have to try that
                              just to see if anything can get through. Will that also work if the
                              hostname is home.bellsouth.net? Actually I need to get this working
                              not just for this user but for others as well. I want to make sure it
                              all works and I understand it before adding more users. These
                              otherwise legitimate ISPs that refuse to take responsibility for spam
                              originating on their networks drive me nuts. I have things pretty
                              tight so we get very little spam leaking through but there are a few
                              legitimate sources that don't.

                              >
                              > Note that you'll have to put your map *after*
                              > reject_unauth_destination if you use the bellsouth.net address for
                              > outgoing mail (in which case, you should really use their mail
                              > server, instead).
                              >

                              Now I'm confused (as usual). If I send something to
                              dap1@... it will be rejected? Outgoing mail cannot go to
                              'bellsouth.net' as that does not resolve to an smtp server. I thought
                              postfix looked up the MX record for that address instead.
                            • Jorey Bump
                              ... No, I meant for you to change the smtpd_client_restrictions entry that you provided to smtpd_recipient_restrictions and remove the redundant
                              Message 14 of 17 , May 1, 2007
                                Dennis Putnam wrote:
                                >
                                > On May 1, 2007, at 10:06 AM, Jorey Bump wrote:
                                >>
                                >> I'm not sure why you're removing permit_sasl_authenticated, but if you
                                >> don't need it, no harm done.
                                >
                                > I thought that was what you suggested I do.

                                No, I meant for you to change the "smtpd_client_restrictions" entry that
                                you provided to "smtpd_recipient_restrictions" and remove the redundant
                                smtpd_recipient_restrictions from your configuration.

                                >> It appears your whitelist is not being consulted. Be sure to issue a
                                >> 'postfix reload' after editing main.cf.
                                >
                                > I do/did. Why would the white list not be consulted?

                                It was. The address was wrong.

                                >> Put permit_sasl_authenticated back before permit_mynetworks in
                                >> smtpd_recipient_restrictions, if you are using authentication for
                                >> submission via port 25.
                                >
                                > It seems to be working without it but I will. In any case this is not
                                > effecting the white list is it?

                                No.

                                >> dap@... != dap1@...
                                >
                                > I missed that detail. I didn't think it used the FROM field since that
                                > is easily spoofed. The difference is whether the mail originated on a
                                > Linux box or Windows box. The bad news is that when I add that to my
                                > white list it still doesn't work.

                                To be clear, it's using the address provided during MAIL FROM (not the
                                From: header), and you're right, that's easily spoofed. But if you want
                                to use check_sender_access, that's what we're talking about, the
                                envelope sender.

                                >> If you want to keep things simple, use this in sender_whitelist:
                                >>
                                >> bellsouth.net permit_auth_destination

                                > I don't really want to open it to all but I might have to try that just
                                > to see if anything can get through. Will that also work if the hostname
                                > is home.bellsouth.net?

                                Refer to Email Address Patterns in:

                                man 5 access

                                or:

                                http://www.postfix.org/access.5.html

                                > Actually I need to get this working not just for
                                > this user but for others as well. I want to make sure it all works and I
                                > understand it before adding more users. These otherwise legitimate ISPs
                                > that refuse to take responsibility for spam originating on their
                                > networks drive me nuts. I have things pretty tight so we get very little
                                > spam leaking through but there are a few legitimate sources that don't.

                                Well, I sympathize, but this may be a user issue. They need to complain
                                to the ISP or switch. Kudos for trying to solve their problem, but you
                                may be taking on a maintenance headache. Of course, you could move your
                                RBLs to a scoring system via a policy server or SpamAssassin if they are
                                causing you too many problems. Using RBLs isn't required, so I guess you
                                do bear some of the responsibility here.

                                >> Note that you'll have to put your map *after*
                                >> reject_unauth_destination if you use the bellsouth.net address for
                                >> outgoing mail (in which case, you should really use their mail server,
                                >> instead).
                                >>
                                >
                                > Now I'm confused (as usual). If I send something to dap1@...
                                > it will be rejected? Outgoing mail cannot go to 'bellsouth.net' as that
                                > does not resolve to an smtp server. I thought postfix looked up the MX
                                > record for that address instead.

                                I meant you must do this if you plan to use the bellsouth.net address as
                                your sender address for outgoing mail. Outgoing mail *to* bellsouth.net
                                is not affected by this configuration.
                              Your message has been successfully submitted and would be delivered to recipients shortly.