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

Are my basic definitions wrong? ip blocks in hash for check_sender_access

Expand Messages
  • Robert Lopez
    My understanding of client and sender are these: Client: An application used to send, receive e-mail messages. Sender: The from or sender name in the header
    Message 1 of 7 , Oct 1, 2009
      My understanding of client and sender are these:
      Client: An application used to send, receive e-mail messages.
      Sender: The from or sender "name" in the header that shows who (is
      claimed to have) sent the email.

      The context of the use that has me concerned are these:
      smtpd_client_restrictions and smtpd_sender_restrictions

      I currently have these lines in main.cf:

      check_client_access=hash:/etc/postfix/access
      smtpd_client_restrictions =
      permit_mynetworks
      hash:/etc/postfix/whitelist
      reject_rbl_client zen.spamhaus.org
      reject_rbl_client bl.spamcop.net
      reject_rbl_client dnsbl.njabl.org
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
      reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13
      permit

      smtpd_sender_restrictions =
      check_sender_access hash:/etc/postfix/greylist
      check_sender_access hash:/etc/postfix/sender_access
      permit_mynetworks
      reject_unknown_sender_domain

      To me the content of the sender_access hash makes sense if it contains
      terms such as
      lucky13@... DISCARD

      Does it also work correctly if that same files also has terms such as
      64.94.244 DISCARD
      where the intent is to block any of
      64.94.244.xxx
      ?

      Right now that ip address example shown above (64.94.244) is in the
      sender_access file (and the sender_access.db) but the log file shows
      events such as this:

      Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: hold: header
      Received: from av7.experience.com (unknown [64.94.244.50])??by
      mgxx.cnm.edu (Postfix) with SMTP id 596A81FFCD??for <glevee@...>;
      Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
      from=<no_reply@...> to=<xxxxx@...> proto=SMTP
      helo=<av7.experience.com>

      Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
      id=<27390832.651.1254095751632.JavaMail.root@...>

      Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: warning:
      header Subject: eRecruiting Saved Search - Abq-Lots from
      unknown[64.94.244.50]; from=<no_reply@...>
      to=<xxxxx@...> proto=SMTP helo=<av7.experience.com>

      Sep 27 7:56:22 mgxx MailScanner[9931]: Requeue: 596A81FFCD.2D1A1 to C98C42016A

      Sep 27 17:56:22 mgxx postfix/qmgr[24665]: C98C42016A:
      from=<no_reply@...>, size=33955, nrcpt=1 (queue active)

      Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
      to=<glevee@...>, orig_to=<glevee@...>,
      relay=tvimail.cnm.edu[198.133.181.119]:25, delay=5.7,
      delays=5.6/0/0/0.03, dsn=2.5.0, status=sent (250 2.5.0 Ok.) Sep 27
      17:56:22 mg05 postfix/qmgr[24665]: C98C42016A: removed

      Based upon my understanding of the definitions of the terms I have
      always been uncertain about putting ip blocks in the same file. I have
      been told it has been working practice at this college for years
      before I got here. I need to be certain we are doing the right things.

      --
      Robert Lopez
      Unix Systems Administrator
      Central New Mexico Community College (CNM)
      525 Buena Vista SE
      Albuquerque, New Mexico 87106
    • Brian Evans - Postfix List
      ... Indeed. ... This is depreciated syntax equivalent to check_client_access hash:/etc/postfix/whitelist ... You are explicitly asking postfix to check a
      Message 2 of 7 , Oct 1, 2009
        Robert Lopez wrote:
        > My understanding of client and sender are these:
        > Client: An application used to send, receive e-mail messages.
        > Sender: The from or sender "name" in the header that shows who (is
        > claimed to have) sent the email.
        >
        >

        Indeed.
        > The context of the use that has me concerned are these:
        > smtpd_client_restrictions and smtpd_sender_restrictions
        >
        > I currently have these lines in main.cf:
        >
        > check_client_access=hash:/etc/postfix/access
        > smtpd_client_restrictions =
        > permit_mynetworks
        > hash:/etc/postfix/whitelist
        >
        This is depreciated syntax equivalent to "check_client_access
        hash:/etc/postfix/whitelist"
        > reject_rbl_client zen.spamhaus.org
        > reject_rbl_client bl.spamcop.net
        > reject_rbl_client dnsbl.njabl.org
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
        > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13
        > permit
        >
        > smtpd_sender_restrictions =
        > check_sender_access hash:/etc/postfix/greylist
        > check_sender_access hash:/etc/postfix/sender_access
        > permit_mynetworks
        > reject_unknown_sender_domain
        >
        > To me the content of the sender_access hash makes sense if it contains
        > terms such as
        > lucky13@... DISCARD
        >
        > Does it also work correctly if that same files also has terms such as
        > 64.94.244 DISCARD
        > where the intent is to block any of
        > 64.94.244.xxx
        > ?
        >
        > Right now that ip address example shown above (64.94.244) is in the
        > sender_access file (and the sender_access.db) but the log file shows
        > events such as this:
        >

        You are explicitly asking postfix to check a sender for the file
        hash:/etc/postfix/sender_access.
        This will never match an IP.
        > Based upon my understanding of the definitions of the terms I have
        > always been uncertain about putting ip blocks in the same file. I have
        > been told it has been working practice at this college for years
        > before I got here. I need to be certain we are doing the right things
        You may put check_client_access to point to the same map in order to
        check for an IP.
        This is discouraged as that map may be abused in the future. People love
        putting all their eggs in one basket.
        Abuse can occur if placed in recipient restriction before
        reject_unauth_destination with an OK result.
        The check_client_access can be placed in sender_restrictions if you like.
      • Robert Lopez
        On Thu, Oct 1, 2009 at 11:02 AM, Brian Evans - Postfix List ... ... Brian which line is depreciated syntax? ... ... ...check a sender for the
        Message 3 of 7 , Oct 1, 2009
          On Thu, Oct 1, 2009 at 11:02 AM, Brian Evans - Postfix List
          <grknight@...> wrote:
          > Robert Lopez wrote:
          <snip>
          >> check_client_access=hash:/etc/postfix/access
          >> smtpd_client_restrictions =
          >>       permit_mynetworks
          >>       hash:/etc/postfix/whitelist
          >>
          > This is depreciated syntax equivalent to "check_client_access
          > hash:/etc/postfix/whitelist"

          Brian which line is depreciated syntax?

          >>       reject_rbl_client zen.spamhaus.org
          >>       reject_rbl_client bl.spamcop.net
          >>       reject_rbl_client dnsbl.njabl.org
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
          >>       reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13
          >>         permit
          >>
          >> smtpd_sender_restrictions =
          >>       check_sender_access hash:/etc/postfix/greylist
          >>       check_sender_access hash:/etc/postfix/sender_access
          >>       permit_mynetworks
          >>       reject_unknown_sender_domain
          <snip>
          >> Right now that ip address example shown above (64.94.244) is in the
          >> sender_access file (and the sender_access.db) but the log file shows
          >> events such as this:
          >>
          >
          > You  are explicitly asking postfix to check a sender for the file
          > hash:/etc/postfix/sender_access.


          "...check a sender for the file..."
          Are you confirming postfix looks only for a sender-name found in the
          Reply-To: in the /etc/postfix/sender_access file?


          > This will never match an IP.

          Thank you for confirming that point.

          >> Based upon my understanding of the definitions of the terms I have
          >> always been uncertain about putting ip blocks in the same file. I have
          >> been told it has been working practice at this college for years
          >> before I got here. I need to be certain we are doing the right things
          > You may put check_client_access to point to the same map in order to
          > check for an IP.
          > This is discouraged as that map may be abused in the future. People love
          > putting all their eggs in one basket.
          > Abuse can occur if placed in recipient restriction before
          > reject_unauth_destination with an OK result.
          > The check_client_access can be placed in sender_restrictions if you like.
          >

          I am not clear who you suggest may do the abuse, but I understand your
          point is it is best to use separate files, each for a single purpose.

          So is this the implementation you would suggest...
          check_client_access=hash:/etc/postfix/access_domain
          check_client_access=hash:/etc/postfix/access_ip

          where the access_domain file has domain names and the access_ip file
          has ip addresses?

          This (from http://www.postfix.org/postconf.5.html) suggests a single
          file can have multiple uses:
          "check_client_access type:table
          Search the specified access database for the client hostname,
          parent domains, client IP address, or networks obtained by stripping
          least significant octets. See the access(5) manual page for details."
          --
          Robert Lopez
          Unix Systems Administrator
          Central New Mexico Community College (CNM)
          525 Buena Vista SE
          Albuquerque, New Mexico 87106
        • /dev/rob0
          ... In the context of check_client_access it means the IP address and/or forward-confirmed reverse DNS name of the client application which connects to
          Message 4 of 7 , Oct 1, 2009
            On Thursday 01 October 2009 11:47:47 Robert Lopez wrote:
            > My understanding of client and sender are these:
            > Client: An application used to send, receive e-mail messages.

            In the context of check_client_access it means the IP address and/or
            forward-confirmed reverse DNS name of the client application which
            connects to smtpd(8) to send mail.

            > Sender: The from or sender "name" in the header that shows who
            > (is claimed to have) sent the email.

            Header is irrelevant. Sender (for check_sender_access) is the address
            used in the SMTP "MAIL FROM:" command. This message, for example, is
            purportedly from me, but if you look at the header which your Postfix
            added, you'll see it was not:
            Return-Path: <owner-postfix-users@...>

            Oops, I see that you're probably reading the list from gmail, not
            from your own Postfix, but likewise, the gmail MTA probably prepends
            the Return-Path: header too.

            > The context of the use that has me concerned are these:
            > smtpd_client_restrictions and smtpd_sender_restrictions
            >
            > I currently have these lines in main.cf:
            >
            > check_client_access=hash:/etc/postfix/access

            Irrelevant, ignored. This is an example of why the list welcome
            message asks for "postconf -n" and not lines from main.cf.
            check_client_access is a restriction that can be used in any of the
            various smtpd_*_restrictions stages. It does nothing where you put
            that.

            See http://www.postfix.org/SMTPD_ACCESS_README.html for an overview
            of how access(5) restrictions work.

            > smtpd_client_restrictions =

            It's often recommended for simplicity to keep restrictions in a
            single stage, and that stage would have to be
            smtpd_recipient_restrictions, because that is where mandatory relay
            control occurs.

            When so doing, one must be careful about whitelisting. The README
            aforementioned contains a warning. Whitelisting entries can be done
            safely either after reject_unauth_destination, or using a
            permit_auth_destination lookup result (rather than "OK" or permit.)

            > permit_mynetworks
            > hash:/etc/postfix/whitelist

            Don't do this. You seem to be following some outdated tutorial. I see
            that Brian has beat me to this explanation, so I'll leave it at what
            he had to say about it.

            > reject_rbl_client zen.spamhaus.org
            > reject_rbl_client bl.spamcop.net
            > reject_rbl_client dnsbl.njabl.org
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4

            Yikes. That DNSBL doesn't have a very solid reputation. I do hope you
            know what you're doing! You should only use DNSBLs with which you are
            familiar. (Personally, I do not use reject_rbl_client bl.spamcop.net
            either, but many sites probably do.)

            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
            > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13
            > permit
            >
            > smtpd_sender_restrictions =
            > check_sender_access hash:/etc/postfix/greylist
            > check_sender_access hash:/etc/postfix/sender_access

            Two hash: maps doing the same type of lookup at the same point in
            your restrictions does not make sense. I would either consolidate
            these, or (more likely, given your confusion) reconsider the lookup
            types.

            > permit_mynetworks
            > reject_unknown_sender_domain

            I would reverse these. There's no point in accepting mail from your
            users when these conditions exist:
            1. No other site will accept it from you
            2. You have no way to send a bounce to the sender
            YMMV. If your DNS is fragile, a sender domain lookup might fail on
            occasion, and you might prefer not to get calls from your confused
            and/or upset users.

            (To be precise, "permit_mynetworks" at the end of
            smtpd_sender_restrictions is meaningless, since the default is to
            permit anyway. It makes sense the way you have it; I just disagree.)

            > To me the content of the sender_access hash makes sense if it
            > contains terms such as
            > lucky13@... DISCARD

            That's an email address, such as might be used as a sender address.
            BTW, check_sender_access is not generally a very safe or useful tool
            to use against spam. Most spam sender addresses are forged, and many
            of those are real sender addresses: the "joe job". See
            http://en.wikipedia.org/wiki/Joe_job - I don't like to help spammers
            destroy the usability of email.

            Also, DISCARD is a strange choice. Why not REJECT?

            > Does it also work correctly if that same files also has terms
            > such as
            > 64.94.244 DISCARD
            > where the intent is to block any of
            > 64.94.244.xxx
            > ?

            Seems to be confusion of your basic definitions, as per $SUBJECT. :)

            > Right now that ip address example shown above (64.94.244) is in
            > the sender_access file (and the sender_access.db) but the log
            > file shows events such as this:
            >
            > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: hold: header
            > Received: from av7.experience.com (unknown [64.94.244.50])??by
            > mgxx.cnm.edu (Postfix) with SMTP id 596A81FFCD??for <glevee@...>;
            > Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
            > from=<no_reply@...> to=<xxxxx@...> proto=SMTP
            > helo=<av7.experience.com>

            A check_sender_access lookup only looked up "no_reply@..."
            and "experience.com" in that example.

            BTW the use of MailScanner with Postfix is not recommended and will
            not be supported on this list. It uses direct access to the Postfix
            queue, an undocumented and unsupported interface. There are other
            content filter choices which do it properly; my recommendation is
            amavisd-new.

            > Based upon my understanding of the definitions of the terms I
            > have always been uncertain about putting ip blocks in the same
            > file. I have been told it has been working practice at this
            > college for years before I got here. I need to be certain we are
            > doing the right things.

            Perhaps the person who told you that would work (had been working)
            was wrong. See access.5.html , "EMAIL ADDRESS PATTERNS", to see what
            is looked up for check_sender_access.
            --
            Offlist mail to this address is discarded unless
            "/dev/rob0" or "not-spam" is in Subject: header
          • mouss
            ... No. the client is the IP node. so it s either the IP of the reverse DNS of the host that is trying to send mail. regarding reverse dns, if it is not
            Message 5 of 7 , Oct 1, 2009
              Robert Lopez wrote:
              > My understanding of client and sender are these:
              > Client: An application used to send, receive e-mail messages.

              No. the client is the IP node. so it's either the IP of the reverse DNS
              of the host that is trying to send mail. regarding reverse dns, if it is
              not "confirmed", then it is "unknown". a name is confirmed if

              IP -> name -> IP

              returns the original IP.

              > Sender: The from or sender "name" in the header that shows who (is
              > claimed to have) sent the email.
              >

              The sender in smtp is the address in the MAIL FROM command. This is
              generally the address you seee in the Return-Path header, but this not
              guaranteed (depends on the MTA). in "simple" cases, this also the
              address that people use as From: or Reply-To: in their mailers, but
              anybody can set whatever headers they want.

              > The context of the use that has me concerned are these:
              > smtpd_client_restrictions and smtpd_sender_restrictions
              >
              > I currently have these lines in main.cf:
              >
              > check_client_access=hash:/etc/postfix/access
              > smtpd_client_restrictions =
              > permit_mynetworks
              > hash:/etc/postfix/whitelist

              it is recommended to put the right check_foo_access, instead of relying
              of the old implicit mode. here
              check_client_access hash:/etc/postfix/whitelist


              > reject_rbl_client zen.spamhaus.org
              > reject_rbl_client bl.spamcop.net
              > reject_rbl_client dnsbl.njabl.org
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
              > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13

              it depends on your site, but in general, five-ten is way too aggressive.

              > permit
              >
              > smtpd_sender_restrictions =
              > check_sender_access hash:/etc/postfix/greylist
              > check_sender_access hash:/etc/postfix/sender_access
              > permit_mynetworks
              > reject_unknown_sender_domain
              >
              > To me the content of the sender_access hash makes sense if it contains
              > terms such as
              > lucky13@... DISCARD
              >

              avoid DISCARD. use REJECT instead.

              > Does it also work correctly if that same files also has terms such as
              > 64.94.244 DISCARD

              no. check_sender_access applies to a sender address, which is something
              like joe@....

              > where the intent is to block any of
              > 64.94.244.xxx
              > ?

              for this, use check_client_access.

              check_client_access hash:/etc/postfix/access_client

              >
              > Right now that ip address example shown above (64.94.244) is in the
              > sender_access file (and the sender_access.db) but the log file shows
              > events such as this:
              >
              > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: hold: header
              > Received: from av7.experience.com (unknown [64.94.244.50])??by
              > mgxx.cnm.edu (Postfix) with SMTP id 596A81FFCD??for <glevee@...>;
              > Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
              > from=<no_reply@...> to=<xxxxx@...> proto=SMTP
              > helo=<av7.experience.com>
              >
              > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
              > id=<27390832.651.1254095751632.JavaMail.root@...>
              >
              > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: warning:
              > header Subject: eRecruiting Saved Search - Abq-Lots from
              > unknown[64.94.244.50]; from=<no_reply@...>
              > to=<xxxxx@...> proto=SMTP helo=<av7.experience.com>
              >
              > Sep 27 7:56:22 mgxx MailScanner[9931]: Requeue: 596A81FFCD.2D1A1 to C98C42016A
              >
              > Sep 27 17:56:22 mgxx postfix/qmgr[24665]: C98C42016A:
              > from=<no_reply@...>, size=33955, nrcpt=1 (queue active)
              >
              > Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
              > to=<glevee@...>, orig_to=<glevee@...>,
              > relay=tvimail.cnm.edu[198.133.181.119]:25, delay=5.7,
              > delays=5.6/0/0/0.03, dsn=2.5.0, status=sent (250 2.5.0 Ok.) Sep 27
              > 17:56:22 mg05 postfix/qmgr[24665]: C98C42016A: removed
              >
              > Based upon my understanding of the definitions of the terms I have
              > always been uncertain about putting ip blocks in the same file. I have
              > been told it has been working practice at this college for years
              > before I got here. I need to be certain we are doing the right things.
              >

              whatever they were doing, use different checks for different goals.
              while you can use a single file for both check_sender_access and
              check_client_access, this is ugly at best.

              note that you can put a check_sender_access under
              smtpd_client_restrictions and a check_client_access under
              smtpd_sender_restrictions. which brings you back to what Rob said: it
              may be a good idea to put all your anti-spam checks under a single
              smtpd_foo_restrictions.
            • Stan Hoeppner
              ... In the context of Postfix client restrictions, the _client_ is the remote SMTP server that is sending email to your Postfix server. It is defined as a
              Message 6 of 7 , Oct 1, 2009
                Robert Lopez put forth on 10/1/2009 11:47 AM:
                > My understanding of client and sender are these:
                > Client: An application used to send, receive e-mail messages.

                In the context of Postfix client restrictions, the _client_ is the
                remote SMTP server that is sending email to your Postfix server. It is
                defined as a client because it is initiating a connection to your
                server. (When your Postfix connects to a remote MTA to deliver mail,
                your Postfix is the _client_). Thus, any client restrictions you
                implement are going to scrutinize the IP address and dns parameters
                (mainly FQrDNS name) of the machine connecting to yours. In short, any
                machine connecting to your Postfix to deliver email is called a _client_.

                Don't feel bad for misunderstanding this "client server" thing. Many IT
                folks suffer the same confusion when dealing with real MTAs for the
                first time (and I don't mean M$ Exchange ;)). Myself included.

                --
                Stan


                > The context of the use that has me concerned are these:
                > smtpd_client_restrictions and smtpd_sender_restrictions
                >
                > I currently have these lines in main.cf:
                >
                > check_client_access=hash:/etc/postfix/access
                > smtpd_client_restrictions =
                > permit_mynetworks
                > hash:/etc/postfix/whitelist
                > reject_rbl_client zen.spamhaus.org
                > reject_rbl_client bl.spamcop.net
                > reject_rbl_client dnsbl.njabl.org
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.5
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.6
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.7
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.8
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.9
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.10
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.11
                > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.13
                > permit
                >
                > smtpd_sender_restrictions =
                > check_sender_access hash:/etc/postfix/greylist
                > check_sender_access hash:/etc/postfix/sender_access
                > permit_mynetworks
                > reject_unknown_sender_domain
                >
                > To me the content of the sender_access hash makes sense if it contains
                > terms such as
                > lucky13@... DISCARD
                >
                > Does it also work correctly if that same files also has terms such as
                > 64.94.244 DISCARD
                > where the intent is to block any of
                > 64.94.244.xxx
                > ?
                >
                > Right now that ip address example shown above (64.94.244) is in the
                > sender_access file (and the sender_access.db) but the log file shows
                > events such as this:
                >
                > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: hold: header
                > Received: from av7.experience.com (unknown [64.94.244.50])??by
                > mgxx.cnm.edu (Postfix) with SMTP id 596A81FFCD??for <glevee@...>;
                > Sun, 27 Sep 2009 17:56:16 -0600 (MDT) from unknown[64.94.244.50];
                > from=<no_reply@...> to=<xxxxx@...> proto=SMTP
                > helo=<av7.experience.com>
                >
                > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: message-
                > id=<27390832.651.1254095751632.JavaMail.root@...>
                >
                > Sep 27 17:56:19 mgxx postfix/cleanup[22432]: 596A81FFCD: warning:
                > header Subject: eRecruiting Saved Search - Abq-Lots from
                > unknown[64.94.244.50]; from=<no_reply@...>
                > to=<xxxxx@...> proto=SMTP helo=<av7.experience.com>
                >
                > Sep 27 7:56:22 mgxx MailScanner[9931]: Requeue: 596A81FFCD.2D1A1 to C98C42016A
                >
                > Sep 27 17:56:22 mgxx postfix/qmgr[24665]: C98C42016A:
                > from=<no_reply@...>, size=33955, nrcpt=1 (queue active)
                >
                > Sep 27 17:56:22 mgxx postfix/smtp[23167]: C98C42016A:
                > to=<glevee@...>, orig_to=<glevee@...>,
                > relay=tvimail.cnm.edu[198.133.181.119]:25, delay=5.7,
                > delays=5.6/0/0/0.03, dsn=2.5.0, status=sent (250 2.5.0 Ok.) Sep 27
                > 17:56:22 mg05 postfix/qmgr[24665]: C98C42016A: removed
                >
                > Based upon my understanding of the definitions of the terms I have
                > always been uncertain about putting ip blocks in the same file. I have
                > been told it has been working practice at this college for years
                > before I got here. I need to be certain we are doing the right things.
                >
              • Robert Lopez
                Thank you everyone for the excellent information. ... Old hardware running email gateways needed to be retired and replaced. I was to keep the same
                Message 7 of 7 , Oct 2, 2009
                  Thank you everyone for the excellent information.

                  > Don't do this. You seem to be following some outdated tutorial.

                  Old hardware running email gateways needed to be retired and replaced.
                  I was to keep the same functionality as was on the servers when I
                  arrived on this job. So, between not having prior knowledge about or
                  experience with any of the software (postfix, etc.), and being told to
                  minimize the performance changes to the systems I thought the safest
                  path was to just copy the master.cf and the main.cf. I ran into the
                  problem that I also had to replace created here "glue scripts" with
                  MailScanner. That forced me to make some changes, some which I
                  obviously did not fully understand. So, I appreciate the corrections.

                  > > reject_rbl_client blackholes.five-ten-sg.com=127.0.0.4
                  > Yikes. That DNSBL doesn't have a very solid reputation.

                  I know. I know. I know. And I understand why. I am a member of a team
                  in which I am the junior member and the senior members all have an
                  attachment to five-ten because it stops so much spam. I do have to
                  deal with the over aggressive effects on a weekly basics. I loose on
                  this point.

                  > Also, DISCARD is a strange choice. Why not REJECT?

                  I am told there is a logging difference and a program written here is
                  looking at log files for those events. I will revisit this point.

                  >> I currently have these lines in main.cf:
                  >>
                  >> check_client_access=hash:/etc/postfix/access
                  > Irrelevant, ignored.
                  > This is an example of why the list welcome message asks for "postconf -n" and not lines from main.cf.

                  root:/var/log# postconf -n
                  alias_database = hash:/etc/aliases
                  alias_maps = hash:/etc/aliases
                  append_dot_mydomain = yes
                  biff = no
                  bounce_size_limit = 1
                  config_directory = /etc/postfix
                  default_process_limit = 400
                  header_checks = regexp:/etc/postfix/header_checks
                  inet_interfaces = all
                  mailbox_size_limit = 0
                  masquerade_domains = $mydomain, cnm.edu, nmvc.org, nmvirtualcollege.org
                  max_use = 100
                  message_size_limit = 16777216
                  mydestination = $myhostname, $mydomain, localhost.localdomain,
                  cnm.edu, mail.cnm.edu, mg01.cnm.edu, mg02.cnm.edu, mg03.cnm.edu,
                  mg04.cnm.edu, mg05.cnm.edu, nmvc.org, mail.nmvc.org, mg01.nmvc.org,
                  mg02.nmvc.org, mg03.nmvc.org, mg04.nmvc.org, mg05.nmvc.org,
                  nmvirtualcollege.org, mail.nmvirtualcollege.org,
                  mg01.nmvirtualcollege.org, mg02.nmvirtualcollege.org,
                  mg03.nmvirtualcollege.org, mg04.nmvirtualcollege.org,
                  mg05.nmvirtualcollege.org, nmln.net, ideal-nm.org, ideal-nm.net,
                  idealnm.org, idealnm.net
                  myhostname = mg05.cnm.edu
                  mynetworks = 198.133.182.0/24, 198.133.181.0/24, 198.133.180.0/24,
                  172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8, 127.0.0.0/8
                  [::ffff:127.0.0.0]/104 [::1]/128
                  myorigin = /etc/mailname
                  notify_classes = resource,software
                  readme_directory = no
                  recipient_delimiter = +
                  relay_domains = $mydestination
                  relayhost =
                  smtp_host_lookup = dns, native
                  smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
                  smtpd_banner = cnm.edu
                  smtpd_client_restrictions = permit_mynetworks
                  hash:/etc/postfix/whitelist reject_rbl_client
                  zen.spamhaus.org reject_rbl_client bl.spamcop.net reject_rbl_client
                  dnsbl.njabl.org reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.4 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.5 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.6 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.7 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.8 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.9 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.10 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.11 reject_rbl_client
                  blackholes.five-ten-sg.com=127.0.0.13 permit
                  smtpd_helo_required = yes
                  smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
                  smtpd_recipient_restrictions = check_recipient_access
                  hash:/etc/postfix/overquota reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unlisted_recipient permit_mynetworks reject_unauth_destination reject_unauth_pipeliningreject_invalid_helo_hostname
                  reject_non_fqdn_helo_hostname reject_rbl_client zen.spamhaus.org
                  smtpd_sender_restrictions = check_sender_access
                  hash:/etc/postfix/greylist check_sender_access
                  hash:/etc/postfix/sender_access permit_mynetworks
                  reject_unknown_sender_domain
                  smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
                  smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
                  smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
                  smtpd_use_tls = yes
                  virtual_alias_maps = hash:/etc/postfix/virtualaliases
                  root:/var/log#

                  > BTW the use of MailScanner with Postfix is not recommended and will not be supported on this list. It uses direct access to the Postfix queue, an undocumented and unsupported interface. There are other content filter choices which do it properly; my recommendation is amavisd-new.

                  My understanding is that "uses direct access to the Postfix queue" is
                  an old issue that is no longer the case. In any event, I do not select
                  what we use.

                  --
                  Robert Lopez
                  Unix Systems Administrator
                  Central New Mexico Community College (CNM)
                  525 Buena Vista SE
                  Albuquerque, New Mexico 87106
                Your message has been successfully submitted and would be delivered to recipients shortly.