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

Re: How to block email based on domain name

Expand Messages
  • Noel Jones
    ... Yes, this is a reasonable way to do what you have described. Restrictions are processed in order, first test that returns a result wins. In this case
    Message 1 of 6 , Dec 28, 2006
    • 0 Attachment
      At 01:04 AM 12/29/2006, Jim Long wrote:
      >One could of course put these in the same file, but as I said, I'm
      >doing this as an exercise.
      >I'm trying to allow user@... as a sender, but deny all
      >other senders from example.com. I have these entries in the
      >two lists:
      >mail : 22:09:02 /usr/local/etc/postfix# grep example whitelist blacklist
      >whitelist:user@... OK
      >blacklist:example.com REJECT
      >I'm listing the whitelist first, so that specific exceptions are
      >permitted, and then general rules are denied, like so:
      >smtpd_sender_restrictions =
      > check_client_access hash:/usr/local/etc/postfix/whitelist
      > check_sender_access hash:/usr/local/etc/postfix/whitelist
      > check_client_access hash:/usr/local/etc/postfix/blacklist
      > check_sender_access hash:/usr/local/etc/postfix/blacklist
      >FWIW, the 'client' in this case has reverse DNS of ns.example.com.
      >So the blacklist would still reject that host, but I am trying
      >to get the whitelist to override, based on a whitelisted
      >sender address.
      >This seems to work, but is it the right way/best practice for
      >prioritizing a whitelist over a blacklist?

      Yes, this is a reasonable way to do what you have
      described. Restrictions are processed in order, first test that
      returns a result wins. In this case the OK comes first, which is
      what you want a whitelist to do.

      >One of my most puzzling questions relates to my smtpd_recipient_restrictions:
      >smtpd_recipient_restrictions =
      > reject_unknown_sender_domain
      > permit_mynetworks
      ># this line causes postfix to check the pop-before-smtp DB hash
      > check_client_access hash:/usr/local/etc/postfix/pop-before-smtp
      ># this line activates the access.db hash
      > check_client_access hash:/usr/local/etc/postfix/access
      > reject_unauth_destination
      > check_policy_service inet:
      ># remove next 1 line 8/16/06 jgl, logs say this is deprecated
      ># in favor of reject_unauth_destination
      ># check_relay_domains
      >## check_policy_service unix:private/policy
      ># this line will activate SORBS RBL checks
      ># reject_rbl_client dnsbl.sorbs.net
      ># this line will activate spamhaus RBL checks
      ># reject_rbl_client sbl-xbl.spamhaus.org
      >## this line will block clients with no reverse DNS
      ># reject_unknown_reverse_client_hostname
      ># this line will block clients with no reverse DNS or with improper
      ># reverse DNS
      > reject_unknown_client
      >First, I understand that those tests are run in the order listed.
      >So the first two lines mean that even my permitted networks may
      >not forge an unknown sender domain. And that's a good thing.
      >My main confusion is the check_client_access there in the smtpd_recipient
      >section. That seems more like a smtpd_sender_restriction. However,
      >the pop-before-smtp appears to work, and the pop-before-smtp docs
      >specifically say to use check_client_access in the smtpd_recipient
      >section. But I don't understand why the check on the SMTP client IP
      >is not considered a sender restriction.

      smtpd_{client, helo, sender, recipient}_restrictions define *when*
      the check is performed, corresponding to the client connection,
      HELO/EHLO, MAIL FROM, and RCPT TO commands during SMTP. Note that
      while UCE checks can be done at any of these stages, relay access
      control must be done during the RCPT TO stage, in
      smtpd_recipient_restrictions; that's why the pop-before-smtp check
      must be where it is. (a side note is that postfix by default delays
      all these checks until the RCPT TO stage via the default
      smtpd_delay_reject = yes, but relay control still must be under

      Also, each smtpd_{client, helo, sender, recipient}_restrictions
      section must resolve to OK/permit or give no result (DUNNO) for mail
      to be accepted. An OK in one section will be overruled by a REJECT
      in a later section.

      The check_{client, helo, sender, recipient}_access tables define
      *what* data is to be tested, corresponding to the client hostname/IP,
      HELO name given, envelope sender, and envelope recipient.
      So for example, a check_client_access rule will always search the
      given table for the client hostname then the IP, and
      check_sender_access will always search the table for the sender
      envelope address.

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