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

Understanding Client Restrictions

Expand Messages
  • Drew Tomlinson
    I m finding the following in my mail log: Jun 4 08:55:11 blacklamb postfix/smtpd[95132]: NOQUEUE: reject: RCPT from outmail008.snc1.tfbnw.net[69.63.178.167]:
    Message 1 of 9 , Jun 4, 2010
      I'm finding the following in my mail log:

      Jun 4 08:55:11 blacklamb postfix/smtpd[95132]: NOQUEUE: reject: RCPT
      from outmail008.snc1.tfbnw.net[69.63.178.167]: 554 5.7.1 Service unavailable;
      Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked - see
      http://www.spamcop.net/bl.shtml?69.63.178.167;
      from=<notification+o=6pg=ze@...>
      to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>

      OK, I get it. Facebook email is being blocked because servers it uses
      are on a SpamCop blacklist. How can I allow mail from servers
      identifying themselves as<anything>.facebook.com before blacklist
      processing?

      Here is the relevant section of my main.cf file:

      smtpd_client_restrictions =
      check_client_access hash:/usr/local/etc/postfix/client_access,
      reject_unauth_pipelining,
      reject_rbl_client dnsbl.njabl.org,
      reject_rbl_client bl.spamcop.net,
      reject_rbl_client zen.spamhaus.org,
      reject_rbl_client spam.dnsbl.sorbs.net,
      reject_rbl_client web.dnsbl.sorbs.net,
      reject_rbl_client smtp.dnsbl.sorbs.net,
      reject_rbl_client dsn.rfc-ignorant.org

      And here is the content of my ./client_access file:

      facebookmail.com PERMIT
      facebook.com PERMIT

      I have used the postmap command to create client_access.db and issued
      'postfix reload' to ensure changes take effect. However mail is still
      blocked.

      What am I missing?

      Thanks,

      Drew
    • Noel Jones
      ... You re using check_client_access, so postfix looks up the client information; in this case outmail008.snc1.tfbnw.net and 69.63.178.167, neither of which
      Message 2 of 9 , Jun 4, 2010
        On 6/4/2010 6:29 PM, Drew Tomlinson wrote:
        > I'm finding the following in my mail log:
        >
        > Jun 4 08:55:11 blacklamb postfix/smtpd[95132]: NOQUEUE: reject: RCPT
        > from outmail008.snc1.tfbnw.net[69.63.178.167]: 554 5.7.1 Service
        > unavailable;
        > Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked - see
        > http://www.spamcop.net/bl.shtml?69.63.178.167;
        > from=<notification+o=6pg=ze@...>
        > to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
        >
        > OK, I get it. Facebook email is being blocked because servers it uses
        > are on a SpamCop blacklist. How can I allow mail from servers
        > identifying themselves as<anything>.facebook.com before blacklist
        > processing?
        >
        > Here is the relevant section of my main.cf file:
        >
        > smtpd_client_restrictions =
        > check_client_access hash:/usr/local/etc/postfix/client_access,
        > reject_unauth_pipelining,
        > reject_rbl_client dnsbl.njabl.org,
        > reject_rbl_client bl.spamcop.net,
        > reject_rbl_client zen.spamhaus.org,
        > reject_rbl_client spam.dnsbl.sorbs.net,
        > reject_rbl_client web.dnsbl.sorbs.net,
        > reject_rbl_client smtp.dnsbl.sorbs.net,
        > reject_rbl_client dsn.rfc-ignorant.org
        >
        > And here is the content of my ./client_access file:
        >
        > facebookmail.com PERMIT
        > facebook.com PERMIT
        >
        > I have used the postmap command to create client_access.db and issued
        > 'postfix reload' to ensure changes take effect. However mail is still
        > blocked.
        >
        > What am I missing?

        You're using check_client_access, so postfix looks up the
        client information; in this case outmail008.snc1.tfbnw.net and
        69.63.178.167, neither of which are found in your access
        table. See man 5 access "search order" to see how postfix
        searches for subparts.

        facebookmail.com is part of the sender address, facebook.com
        is part of the HELO hostname.

        Probably the easiest solution is to add
        tfbnw.net OK
        to your access table.
      • Jeroen Geilman
        ... That is where it comes from; this is what check_client_access checks. ... You may want to put facebook in check_helo_access instead; however, this opens
        Message 3 of 9 , Jun 4, 2010
          On 06/05/2010 01:29 AM, Drew Tomlinson wrote:
          > I'm finding the following in my mail log:
          >
          > Jun 4 08:55:11 blacklamb postfix/smtpd[95132]: NOQUEUE: reject:
          > RCPT from outmail008.snc1.tfbnw.net[69.63.178.167]:

          That is where it comes from; this is what check_client_access checks.


          > 554 5.7.1 Service unavailable;
          > Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked - see
          > http://www.spamcop.net/bl.shtml?69.63.178.167;
          > from=<notification+o=6pg=ze@...>
          > to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
          > OK, I get it. Facebook email is being blocked because servers it uses
          > are on a SpamCop blacklist. How can I allow mail from servers
          > identifying themselves as<anything>.facebook.com before blacklist
          > processing?

          You may want to put facebook in check_helo_access instead; however, this
          opens you up to all sorts of spam unless you also require proper
          forward+reverse DNS for MXen.

          Put in the prelevant reject_*_helo and reject_non-fqdn_* restrictions so
          HELOs will be worth checking; then implement check_helo_access for your
          facebook issue.

          J.
        • Noel Jones
          ... I would avoid using check_helo_access for any kind of whitelisting since it s easily and frequently forged. Use check_helo_access for whitelisting only as
          Message 4 of 9 , Jun 4, 2010
            On 6/4/2010 6:59 PM, Jeroen Geilman wrote:
            >> 554 5.7.1 Service unavailable;
            >> Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked - see
            >> http://www.spamcop.net/bl.shtml?69.63.178.167;
            >> from=<notification+o=6pg=ze@...>
            >> to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
            >> OK, I get it. Facebook email is being blocked because servers it uses
            >> are on a SpamCop blacklist. How can I allow mail from servers
            >> identifying themselves as<anything>.facebook.com before blacklist
            >> processing?
            >
            > You may want to put facebook in check_helo_access instead; however, this
            > opens you up to all sorts of spam unless you also require proper
            > forward+reverse DNS for MXen.
            >
            > Put in the prelevant reject_*_helo and reject_non-fqdn_* restrictions so
            > HELOs will be worth checking; then implement check_helo_access for your
            > facebook issue.
            >

            I would avoid using check_helo_access for any kind of
            whitelisting since it's easily and frequently forged. Use
            check_helo_access for whitelisting only as a last resort.

            A far better choice is to whitelist by the client name or IP
            block.
          • Jeroen Geilman
            ... I agree completely, however, this is what he asked for; and I don t recognise the client hostname as being in any way related to facebook. If the client
            Message 5 of 9 , Jun 4, 2010
              > On 6/4/2010 6:59 PM, Jeroen Geilman wrote:
              >>> 554 5.7.1 Service unavailable;
              >>> Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked - see
              >>> http://www.spamcop.net/bl.shtml?69.63.178.167;
              >>> from=<notification+o=6pg=ze@...>
              >>> to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
              >>> OK, I get it. Facebook email is being blocked because servers it uses
              >>> are on a SpamCop blacklist. How can I allow mail from servers
              >>> identifying themselves as<anything>.facebook.com before blacklist
              >>> processing?
              >>
              >> You may want to put facebook in check_helo_access instead; however, this
              >> opens you up to all sorts of spam unless you also require proper
              >> forward+reverse DNS for MXen.
              >>
              >> Put in the prelevant reject_*_helo and reject_non-fqdn_* restrictions so
              >> HELOs will be worth checking; then implement check_helo_access for your
              >> facebook issue.
              >>
              >
              > I would avoid using check_helo_access for any kind of whitelisting
              > since it's easily and frequently forged. Use check_helo_access for
              > whitelisting only as a last resort.
              >
              > A far better choice is to whitelist by the client name or IP block.

              I agree completely, however, this is what he asked for; and I don't
              recognise the client hostname as being in any way related to facebook.

              If the client hostname is not dependable, that would not be useful to
              check for.

              J.
            • Noel Jones
              ... You have to do 30 seconds of research... $ host -t txt facebookmail.com facebookmail.com descriptive text v=spf1 ip4:69.63.178.128/25 ip4:69.63.184.0/25
              Message 6 of 9 , Jun 4, 2010
                On 6/4/2010 7:12 PM, Jeroen Geilman wrote:
                >> On 6/4/2010 6:59 PM, Jeroen Geilman wrote:
                >>>> 554 5.7.1 Service unavailable;
                >>>> Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked - see
                >>>> http://www.spamcop.net/bl.shtml?69.63.178.167;
                >>>> from=<notification+o=6pg=ze@...>
                >>>> to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
                >>>> OK, I get it. Facebook email is being blocked because servers it uses
                >>>> are on a SpamCop blacklist. How can I allow mail from servers
                >>>> identifying themselves as<anything>.facebook.com before blacklist
                >>>> processing?
                >>>
                >>> You may want to put facebook in check_helo_access instead; however, this
                >>> opens you up to all sorts of spam unless you also require proper
                >>> forward+reverse DNS for MXen.
                >>>
                >>> Put in the prelevant reject_*_helo and reject_non-fqdn_* restrictions so
                >>> HELOs will be worth checking; then implement check_helo_access for your
                >>> facebook issue.
                >>>
                >>
                >> I would avoid using check_helo_access for any kind of whitelisting
                >> since it's easily and frequently forged. Use check_helo_access for
                >> whitelisting only as a last resort.
                >>
                >> A far better choice is to whitelist by the client name or IP block.
                >
                > I agree completely, however, this is what he asked for; and I don't
                > recognise the client hostname as being in any way related to facebook.
                >
                > If the client hostname is not dependable, that would not be useful to
                > check for.
                >
                > J.
                >


                You have to do 30 seconds of research...

                $ host -t txt facebookmail.com
                facebookmail.com descriptive text "v=spf1 ip4:69.63.178.128/25
                ip4:69.63.184.0/25 ip4:66.220.144.128/25 -all"

                Looks as if the client in question is listed as a valid source IP.


                $ whois tfbnw.net
                ...
                (all kinds of facebook contact info)
                ...
                (facebook name servers)
                ...

                Looks as if the client hostname is owned by facebook.

                Whitelisting by client hostname is the right choice. Always
                exhaust other possibilities before using a HELO based whitelist.


                -- Noel Jones
              • Jeroen Geilman
                ... Ah.. I never thought of using the SPF records, good point. ... Again, I completely agree. However, it was what the OP asked for: a way to whitelist by how
                Message 7 of 9 , Jun 4, 2010
                  > On 6/4/2010 7:12 PM, Jeroen Geilman wrote:
                  >>> On 6/4/2010 6:59 PM, Jeroen Geilman wrote:
                  >>>>> 554 5.7.1 Service unavailable;
                  >>>>> Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked
                  >>>>> - see
                  >>>>> http://www.spamcop.net/bl.shtml?69.63.178.167;
                  >>>>> from=<notification+o=6pg=ze@...>
                  >>>>> to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
                  >>>>> OK, I get it. Facebook email is being blocked because servers it uses
                  >>>>> are on a SpamCop blacklist. How can I allow mail from servers
                  >>>>> identifying themselves as<anything>.facebook.com before blacklist
                  >>>>> processing?
                  >>>>
                  >>>> You may want to put facebook in check_helo_access instead; however,
                  >>>> this
                  >>>> opens you up to all sorts of spam unless you also require proper
                  >>>> forward+reverse DNS for MXen.
                  >>>>
                  >>>> Put in the prelevant reject_*_helo and reject_non-fqdn_*
                  >>>> restrictions so
                  >>>> HELOs will be worth checking; then implement check_helo_access for
                  >>>> your
                  >>>> facebook issue.
                  >>>>
                  >>>
                  >>> I would avoid using check_helo_access for any kind of whitelisting
                  >>> since it's easily and frequently forged. Use check_helo_access for
                  >>> whitelisting only as a last resort.
                  >>>
                  >>> A far better choice is to whitelist by the client name or IP block.
                  >>
                  >> I agree completely, however, this is what he asked for; and I don't
                  >> recognise the client hostname as being in any way related to facebook.
                  >>
                  >> If the client hostname is not dependable, that would not be useful to
                  >> check for.
                  >>
                  >> J.
                  >>
                  >
                  >
                  > You have to do 30 seconds of research...
                  >
                  > $ host -t txt facebookmail.com
                  > facebookmail.com descriptive text "v=spf1 ip4:69.63.178.128/25
                  > ip4:69.63.184.0/25 ip4:66.220.144.128/25 -all"
                  >
                  > Looks as if the client in question is listed as a valid source IP.

                  Ah.. I never thought of using the SPF records, good point.
                  >
                  >
                  > $ whois tfbnw.net
                  > ...
                  > (all kinds of facebook contact info)
                  > ...
                  > (facebook name servers)
                  > ...
                  >
                  > Looks as if the client hostname is owned by facebook.
                  >
                  > Whitelisting by client hostname is the right choice. Always exhaust
                  > other possibilities before using a HELO based whitelist.

                  Again, I completely agree.

                  However, it was what the OP asked for: a way to whitelist by "how
                  facebook identifies itself".

                  I am not judging whether this is a good or a bad idea, even though my
                  own opinion is that it should be used as a last resort, if at all.

                  J.
                • Noel Jones
                  ... Answering questions is good, but it s better to offer sound advice. ie. when your 5 year old asks where the hammer is, find out why he wants it. -- Noel
                  Message 8 of 9 , Jun 4, 2010
                    On 6/4/2010 8:10 PM, Jeroen Geilman wrote:
                    >> On 6/4/2010 7:12 PM, Jeroen Geilman wrote:
                    >>>> On 6/4/2010 6:59 PM, Jeroen Geilman wrote:
                    >>>>>> 554 5.7.1 Service unavailable;
                    >>>>>> Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked
                    >>>>>> - see
                    >>>>>> http://www.spamcop.net/bl.shtml?69.63.178.167;
                    >>>>>> from=<notification+o=6pg=ze@...>
                    >>>>>> to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
                    >>>>>> OK, I get it. Facebook email is being blocked because servers it uses
                    >>>>>> are on a SpamCop blacklist. How can I allow mail from servers
                    >>>>>> identifying themselves as<anything>.facebook.com before blacklist
                    >>>>>> processing?
                    >>>>>
                    >>>>> You may want to put facebook in check_helo_access instead; however,
                    >>>>> this
                    >>>>> opens you up to all sorts of spam unless you also require proper
                    >>>>> forward+reverse DNS for MXen.
                    >>>>>
                    >>>>> Put in the prelevant reject_*_helo and reject_non-fqdn_*
                    >>>>> restrictions so
                    >>>>> HELOs will be worth checking; then implement check_helo_access for
                    >>>>> your
                    >>>>> facebook issue.
                    >>>>>
                    >>>>
                    >>>> I would avoid using check_helo_access for any kind of whitelisting
                    >>>> since it's easily and frequently forged. Use check_helo_access for
                    >>>> whitelisting only as a last resort.
                    >>>>
                    >>>> A far better choice is to whitelist by the client name or IP block.
                    >>>
                    >>> I agree completely, however, this is what he asked for; and I don't
                    >>> recognise the client hostname as being in any way related to facebook.
                    >>>
                    >>> If the client hostname is not dependable, that would not be useful to
                    >>> check for.
                    >>>
                    >>> J.
                    >>>
                    >>
                    >>
                    >> You have to do 30 seconds of research...
                    >>
                    >> $ host -t txt facebookmail.com
                    >> facebookmail.com descriptive text "v=spf1 ip4:69.63.178.128/25
                    >> ip4:69.63.184.0/25 ip4:66.220.144.128/25 -all"
                    >>
                    >> Looks as if the client in question is listed as a valid source IP.
                    >
                    > Ah.. I never thought of using the SPF records, good point.
                    >>
                    >>
                    >> $ whois tfbnw.net
                    >> ...
                    >> (all kinds of facebook contact info)
                    >> ...
                    >> (facebook name servers)
                    >> ...
                    >>
                    >> Looks as if the client hostname is owned by facebook.
                    >>
                    >> Whitelisting by client hostname is the right choice. Always exhaust
                    >> other possibilities before using a HELO based whitelist.
                    >
                    > Again, I completely agree.
                    >
                    > However, it was what the OP asked for: a way to whitelist by "how
                    > facebook identifies itself".
                    >
                    > I am not judging whether this is a good or a bad idea, even though my
                    > own opinion is that it should be used as a last resort, if at all.
                    >
                    > J.
                    >


                    Answering questions is good, but it's better to offer sound
                    advice. ie. when your 5 year old asks where the hammer is,
                    find out why he wants it.


                    -- Noel Jones
                  • Drew Tomlinson
                    ... Thank you both for the excellent advice and best practices suggestions. I will try this out and see if it solves my issue. Thanks, Drew
                    Message 9 of 9 , Jun 5, 2010
                      On 6/4/2010 6:24 PM, Noel Jones wrote:
                      > On 6/4/2010 8:10 PM, Jeroen Geilman wrote:
                      >>> On 6/4/2010 7:12 PM, Jeroen Geilman wrote:
                      >>>>> On 6/4/2010 6:59 PM, Jeroen Geilman wrote:
                      >>>>>>> 554 5.7.1 Service unavailable;
                      >>>>>>> Client host [69.63.178.167] blocked using bl.spamcop.net; Blocked
                      >>>>>>> - see
                      >>>>>>> http://www.spamcop.net/bl.shtml?69.63.178.167;
                      >>>>>>> from=<notification+o=6pg=ze@...>
                      >>>>>>> to=<drew@...> proto=ESMTP helo=<mx-out.facebook.com>
                      >>>>>>> OK, I get it. Facebook email is being blocked because servers it
                      >>>>>>> uses
                      >>>>>>> are on a SpamCop blacklist. How can I allow mail from servers
                      >>>>>>> identifying themselves as<anything>.facebook.com before blacklist
                      >>>>>>> processing?
                      >>>>>>
                      >>>>>> You may want to put facebook in check_helo_access instead; however,
                      >>>>>> this
                      >>>>>> opens you up to all sorts of spam unless you also require proper
                      >>>>>> forward+reverse DNS for MXen.
                      >>>>>>
                      >>>>>> Put in the prelevant reject_*_helo and reject_non-fqdn_*
                      >>>>>> restrictions so
                      >>>>>> HELOs will be worth checking; then implement check_helo_access for
                      >>>>>> your
                      >>>>>> facebook issue.
                      >>>>>>
                      >>>>>
                      >>>>> I would avoid using check_helo_access for any kind of whitelisting
                      >>>>> since it's easily and frequently forged. Use check_helo_access for
                      >>>>> whitelisting only as a last resort.
                      >>>>>
                      >>>>> A far better choice is to whitelist by the client name or IP block.
                      >>>>
                      >>>> I agree completely, however, this is what he asked for; and I don't
                      >>>> recognise the client hostname as being in any way related to facebook.
                      >>>>
                      >>>> If the client hostname is not dependable, that would not be useful to
                      >>>> check for.
                      >>>>
                      >>>> J.
                      >>>>
                      >>>
                      >>>
                      >>> You have to do 30 seconds of research...
                      >>>
                      >>> $ host -t txt facebookmail.com
                      >>> facebookmail.com descriptive text "v=spf1 ip4:69.63.178.128/25
                      >>> ip4:69.63.184.0/25 ip4:66.220.144.128/25 -all"
                      >>>
                      >>> Looks as if the client in question is listed as a valid source IP.
                      >>
                      >> Ah.. I never thought of using the SPF records, good point.
                      >>>
                      >>>
                      >>> $ whois tfbnw.net
                      >>> ...
                      >>> (all kinds of facebook contact info)
                      >>> ...
                      >>> (facebook name servers)
                      >>> ...
                      >>>
                      >>> Looks as if the client hostname is owned by facebook.
                      >>>
                      >>> Whitelisting by client hostname is the right choice. Always exhaust
                      >>> other possibilities before using a HELO based whitelist.

                      Thank you both for the excellent advice and best practices suggestions.
                      I will try this out and see if it solves my issue.

                      Thanks,

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