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

Re: To all of You who use: reject_non_fqdn_hostname and reject_unknown_hostname

Expand Messages
  • Tony Earnshaw
    fr den 01.09.2006 Klokka 10:19 (+0200) skreiv o2 - Marcin Wasilewski: [...] ... Do that, but use a whitelist for genuine maverick non-fq clients (idiot Windows
    Message 1 of 8 , Sep 1, 2006
      fr den 01.09.2006 Klokka 10:19 (+0200) skreiv o2 - Marcin Wasilewski:

      [...]

      > Actually I use:
      > smtpd_helo_restrictions =
      > permit_mynetworks
      > check_helo_access hash:/etc/postfix/db/helo_access
      > reject_invalid_hostname
      >
      > and I would like to enable
      > reject_non_fqdn_hostname

      Do that, but use a whitelist for genuine maverick non-fq clients (idiot
      Windows and non-savvy Unix mailadmins). Keep a good eye on what's being
      rejected (logs or Mail Delivery System mail to postmaster).

      > reject_unknown_hostname

      Don't do that in any event. Too much genuine mail will be lost.

      > but I wonder how many false-positives it gives..

      Both give false positives, but reject_unknown_hostname gives far and
      away most.

      > and one more question: I saw in doc that I could use: warn_if_reject, but
      > how to correctly place it in my config to see how these two rules above will
      > be hit.

      smtpd_helo_restrictions =
      warn_if_reject reject_unknown_hostname
      etc.

      Actually, that's what we do, which is why I write that using
      reject_unknown_hostname gives too many FPs (pflogsumm daily report).

      --Tonni

      --
      Tony Earnshaw
      reservebergenser
    • Sandy Drobic
      ... Good advice here. You could to have a look at your own previous logs and write a little script to grep for accepted mails, the client-name and if the mail
      Message 2 of 8 , Sep 1, 2006
        Tony Earnshaw wrote:
        > fr den 01.09.2006 Klokka 10:19 (+0200) skreiv o2 - Marcin Wasilewski:
        >
        > [...]
        >
        >> Actually I use:
        >> smtpd_helo_restrictions =
        >> permit_mynetworks
        >> check_helo_access hash:/etc/postfix/db/helo_access
        >> reject_invalid_hostname
        >>
        >> and I would like to enable
        >> reject_non_fqdn_hostname
        >
        > Do that, but use a whitelist for genuine maverick non-fq clients (idiot
        > Windows and non-savvy Unix mailadmins). Keep a good eye on what's being
        > rejected (logs or Mail Delivery System mail to postmaster).
        >
        >> reject_unknown_hostname
        >
        > Don't do that in any event. Too much genuine mail will be lost.
        >
        >> but I wonder how many false-positives it gives..
        >
        > Both give false positives, but reject_unknown_hostname gives far and
        > away most.

        Good advice here. You could to have a look at your own previous logs and
        write a little script to grep for accepted mails, the client-name and if
        the mail was spam or not.
        That would tell you for your exact situation how many false positives you
        would have to endure.
        From my own experience I can tell you that the size of the company will
        not mean the mail system was set up in a sensible way.

        Sandy
      • Blake Hudson
        ... I would suggest using reject_invalid_hostname, but be sure to place it after the permit_mynetworks check. Otherwise you will see false positives with
        Message 3 of 8 , Sep 1, 2006
          o2 - Marcin Wasilewski wrote:
          > Hello,
          >
          > I have a question to all of You who use: reject_non_fqdn_hostname and
          > reject_unknown_hostname.
          > I get lot of SPAM messages and almost all of them are from host which
          > in my mail.log are UNKNOWN, ie:
          > connect from unknown[222.181.95.54]
          > Sep 1 10:03:42 mymailhost postfix/smtpd[22196]: NOQUEUE: reject: RCPT
          > from unknown[222.181.95.54]: 550 <ukaszd@mydomainname>: Recipient
          > address rejected: User unknown; from=<abelpmoreira@...>
          > to=<ukaszd@mydomainname> proto=ESMTP helo=<LENOVO-OEM>
          >
          > Actually I use:
          > smtpd_helo_restrictions =
          > permit_mynetworks
          > check_helo_access hash:/etc/postfix/db/helo_access
          > reject_invalid_hostname
          >
          > and I would like to enable
          > reject_non_fqdn_hostname
          > reject_unknown_hostname
          >
          > but I wonder how many false-positives it gives..
          >
          > and one more question: I saw in doc that I could use: warn_if_reject,
          > but how to correctly place it in my config to see how these two rules
          > above will be hit.
          >
          > Best regards
          > Marcin



          I would suggest using reject_invalid_hostname, but be sure to place it
          after the permit_mynetworks check. Otherwise you will see false
          positives with clients that provide hostnames with just the PC name.

          I have to agree with Rene that reject_unknown_hostname provides too many
          false positives for some environments. You can test for your uses by
          using the warn_if_reject. To use warn_if_reject, your helo restrictions
          would look like this:

          smtpd_helo_restrictions =
          permit_mynetworks
          check_helo_access hash:/etc/postfix/db/helo_access
          reject_invalid_hostname
          warn_if_reject reject_unknown_hostname


          -Blake
        • mouss
          ... - you can use reject_non_fqdn_hostname, and either say Standards are standards , or check your logs and see if you need to whitelist some few silly
          Message 4 of 8 , Sep 1, 2006
            o2 - Marcin Wasilewski wrote:
            > Hello,
            >
            > I have a question to all of You who use: reject_non_fqdn_hostname and
            > reject_unknown_hostname.
            > I get lot of SPAM messages and almost all of them are from host which
            > in my mail.log are UNKNOWN, ie:
            > connect from unknown[222.181.95.54]
            > Sep 1 10:03:42 mymailhost postfix/smtpd[22196]: NOQUEUE: reject: RCPT
            > from unknown[222.181.95.54]: 550 <ukaszd@mydomainname>: Recipient
            > address rejected: User unknown; from=<abelpmoreira@...>
            > to=<ukaszd@mydomainname> proto=ESMTP helo=<LENOVO-OEM>
            >
            > Actually I use:
            > smtpd_helo_restrictions =
            > permit_mynetworks
            > check_helo_access hash:/etc/postfix/db/helo_access
            > reject_invalid_hostname
            >
            > and I would like to enable
            > reject_non_fqdn_hostname
            > reject_unknown_hostname
            >
            > but I wonder how many false-positives it gives..

            - you can use reject_non_fqdn_hostname, and either say "Standards are
            standards", or check your logs and see if you need to whitelist some few
            silly winboxes that use their netbios name. whether you can tell their
            admini to fix their systems is a different matter (do they have an admin:-)

            - reject_unknown_hostname is a different thing, because it uses DNS. and
            here, you'll get more FPS:
            * DNS misconfiguration seems common
            * DNS suboptimal-configuration (abuse of CNAME and other redirections
            that may result in timeouts) are also common
            * your own dns system may have problems
            * ...

            so I would not recommend this today, unless you take the time to check
            your logs and adjust your config.
            >
            > and one more question: I saw in doc that I could use: warn_if_reject,
            > but how to correctly place it in my config to see how these two rules
            > above will be hit.

            you can place it before a check to modify the action

            smtpd_recipient_restrictions =
            ...
            warn_if_reject
            reject_unknown_hostname
            ...

            will not reject the "unknown hostname", but only generates a warning in
            your logs.
          • postfix@bitfreak.org
            ... ... DNS in its current form has absolutely zero integrity, so basing a trust model on it (reject_unknown_hostname and the like) is foolhardy. I do
            Message 5 of 8 , Sep 2, 2006
              o2 - Marcin Wasilewski wrote:
              > Hello,
              >
              > I have a question to all of You who use: reject_non_fqdn_hostname and
              <...>
              > I would like to enable
              > reject_non_fqdn_hostname
              > reject_unknown_hostname
              >
              > but I wonder how many false-positives it gives..

              DNS in its current form has absolutely zero integrity, so basing a trust
              model on it (reject_unknown_hostname and the like) is foolhardy. I do
              use reject_non_fqdn_hostname with excellent results: it and
              reject_invalid_helo_hostname currently account for 45-60% of the
              messages blocked pre-queue and I've yet to get a false positive that
              wasn't due to someone not reading the fine MUA setup instructions. You
              do have to put in workarounds for the usual broken mail clients;
              however, SASL authentication and/or using the submission port makes that
              easy.
            • /dev/rob0
              ... It s easy in any case. Simply use those restrictions after the ones to permit relaying. -- Offlist mail to this address is discarded unless /dev/rob0 or
              Message 6 of 8 , Sep 2, 2006
                On Saturday 02 September 2006 02:22, postfix@... wrote:
                > I do use reject_non_fqdn_hostname with excellent results: it and
                > reject_invalid_helo_hostname currently account for 45-60% of the
                > messages blocked pre-queue and I've yet to get a false positive that
                > wasn't due to someone not reading the fine MUA setup instructions.
                > You do have to put in workarounds for the usual broken mail clients;
                > however, SASL authentication and/or using the submission port makes
                > that easy.

                It's easy in any case. Simply use those restrictions after the ones to
                permit relaying.
                --
                Offlist mail to this address is discarded unless
                "/dev/rob0" or "not-spam" is in Subject: header
              Your message has been successfully submitted and would be delivered to recipients shortly.