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

Re: reject_unknown_reverse_client_hostname safe?

Expand Messages
  • Patrick Lists
    On 05/07/2013 02:02 PM, Vincent Lefevre wrote: [snip] ... It does not matter who sends the email. The sending MTA host should have a proper PTR (yes for the IP
    Message 1 of 67 , May 7, 2013
    • 0 Attachment
      On 05/07/2013 02:02 PM, Vincent Lefevre wrote:
      [snip]
      > A PTR is not associated with a host, but with an IP address. That's
      > important because mail may be sent from different IP addresses,
      > depending on the recipient or other factors. And it seems that
      > some users forget to set up a PTR for all their IPv6 addresses.
      > This apparently includes Debian's mailing-list server.

      It does not matter who sends the email. The sending MTA host should have
      a proper PTR (yes for the IP address). Forgetting to set a PTR is not an
      excuse. Would you accept it if a gas station forgot to label their fuel
      properly causing possible damage to your car's engine? If Debian's
      mailing-list server does not have a PTR set then they should fix that.
      You can probably file a bug somewhere or poke some Debian infra person
      on irc. And if they are not totally clueless then their mail admin
      should see a bunch of bounces in their logs due to the absence of a PTR
      which hopefully rings a bell.

      >> and you can ignore this but you also need to understand the the
      >> rules from which machines i and many others accept mail are not up
      >> to you
      >
      > I agree, but I repeat that I cannot change the config of other
      > users. From what I can see in my mail archive, it is *not* safe
      > to blindly reject mail from IPs without a valid PTR. At least
      > currently.

      So you basically accept that a mail admin of another system is clueless
      or lazy? Please don't let them get away with that, even if it could be
      legitimate email. They should do a proper job. For years it has been
      working great for my domains. Up to a point where the relation between
      spam attempts and legitimate email is more than 100:1 and yet at best 1
      or 2 spam emails get through per week which are then grabbed by other
      anti-spam measures (spamhaus, dspam). It's up to you but all this time I
      have had so little trouble from it that I strongly recommend it.
      Together with Stan's dynamic host list it should reject a ton of spam
      attempts.

      Regards,
      Patrick
    • Stan Hoeppner
      ... permits always come before rejects . Thus whitelist type entries should always be at the top of the restrictions list. As you are using
      Message 67 of 67 , May 14, 2013
      • 0 Attachment
        On 5/14/2013 11:45 AM, Steve Jenkins wrote:
        > On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 <rob0@...> wrote:
        >
        >> On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote:
        >>> smtpd_recipient_restrictions =
        >>> reject_invalid_helo_hostname,
        >>> warn_if_reject reject_non_fqdn_helo_hostname,
        >>> reject_unknown_reverse_client_hostname,
        >>> warn_if_reject reject_unknown_helo_hostname,
        >>> check_reverse_client_hostname_access
        >> pcre:/etc/postfix/fqrdns.pcre,
        >>> check_helo_access hash:/etc/postfix/helo_access,
        >>> check_sender_access hash:/etc/postfix/sender_access,
        >>> reject_rbl_client zen.spamhaus.org,
        >>> reject_rhsbl_client dbl.spamhaus.org,
        >>> reject_rhsbl_sender dbl.spamhaus.org,
        >>> reject_rhsbl_helo dbl.spamhaus.org,
        >>> permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
        >>> permit
        >>
        >> The last two lines are no-op. If you have anything you want to be
        >> subjected to the list.dnswl.org whitelist, put it after the
        >> permit_dnswl_client. If not, there is no point in querying it.
        >
        >
        > Excellent point. If the next step is going to "permit" anyway, then no use
        > in the extra query. I've moved the dnswl.org line up so that it's just
        > above the three "local" check_* lines.

        "permits" always come before "rejects". Thus whitelist type entries
        should always be at the top of the restrictions list. As you are using
        (client|helo|sender|recipient) sections any whitelisting in
        smtpd_recipient_restrictions should typically be at the very top.

        permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3]
        ^^^^^^ ^^^^

        This shows you are explicitly permitting anything/everything listed in
        the dnswl. Are you sure that is what you want? I use...

        permit_dnswl_client list.dnswl.org=127.0.[2..14].[2..3]

        which does not explicitly permit email marketing providers nor any IP
        with trustworthiness score of 1. A score of 1 is equivalent to a
        SpamAssassin score of -1, which does not merit a direct shot to the
        queue. That would typically require an SA score of -5. I want these
        clients to go through all of my other restrictions before allowing their
        payload into my queue.

        Also worth noting, there are currently only 14 categories (3rd octet of
        a reply), so specifying 255 is not necessary, and possibly problematic.
        Hypothetically, if dnswl decided one day to create categories 16,
        political campaigns, and 17, religious newsletters, you are currently
        setup to automatically permit such clients.

        Remember, the sole purpose of whitelisting is to bypass all of your
        other spam checks and get the mail into your queue unmolested. IMO, not
        every IP listed by dnswl is deserving of this honor, not even close to
        all of them.

        See section "Return codes" at: http://www.dnswl.org/tech

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