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

Re: reject_unknown_reverse_client_hostname safe?

Expand Messages
  • Vincent Lefevre
    ... There s no mail exchanger here. The machine in question (carotte.tilapin.org) just sends the mail. ... Except that the machine is just the client, not a
    Message 1 of 67 , May 6 6:05 PM
    • 0 Attachment
      On 2013-05-06 18:54:57 -0500, /dev/rob0 wrote:
      > On Mon, May 06, 2013 at 11:13:20PM +0200, Vincent Lefevre wrote:
      > > On 2013-05-06 01:10:59 -0500, Stan Hoeppner wrote:
      > > > On 5/5/2013 8:10 PM, Vincent Lefevre wrote:
      > > > > Received: from carotte.tilapin.org (unknown [95.138.72.61])
      > > > > by ioooi.vinc17.net (Postfix) with ESMTPS id EFA4959
      > > > > for <vincent@...>; Tue, 2 Oct 2012 03:15:23
      > > > > +0200 (CEST)
      > > > >
      > > > > $ host 95.138.72.61
      > > > > Host 61.72.138.95.in-addr.arpa. not found: 3(NXDOMAIN)
      > > >
      > > > ~$ host 95.138.72.61
      > > > Host 61.72.138.95.in-addr.arpa. not found: 3(NXDOMAIN)
      > > >
      > > > ~$ host carotte.tilapin.org
      > > > carotte.tilapin.org has address 5.187.106.61
      > > >
      > > > Not only is rDNS non-existent but the HELO name points to an IP
      > > > different than the client IP. It's difficult to FUBAR this more
      > > > than it is.
      > >
      > > AFAIK, there's no requirement in the RFCs that the HELO name point
      > > to the client IP, and there are good reasons to allow a mismatch, e.g.
      > > due to several machines sharing the same IP with NAT, or a machine
      > > having several interfaces (with several IPs), or a laptop that can
      > > move between various networks.
      >
      > It's not usual, and definitely not ideal, to use NAT on a mail
      > exchanger, although a load balancer (which is more common and
      > sensible) can have similar effects. Also, a laptop as you describe
      > would usually not be in the role of mail exchanger, so its HELO
      > should only matter to its MSA.

      There's no mail exchanger here. The machine in question
      (carotte.tilapin.org) just sends the mail.

      > > > > and this is from a Debian developer.
      > > >
      > snip
      > >
      > > I just meant that
      > > * his mail config is probably sane (the fact that the IP doesn't
      > > have a rDNS is not his fault, but the ISP's);
      >
      > Don't try to run a mail exchanger on a dynamic IP address or one
      > lacking FCrDNS. It's definitely his fault for doing so.

      Except that the machine is just the client, not a mail exchanger.

      > > * one can lose rather important mail (e.g. related to work).
      >
      > Yes. Reread Noel's post upthread. I was the one who originally said
      > reject_unknown_reverse_client_hostname is safe, and Noel explained
      > why: the mail you reject is also being rejected by most major
      > receivers.

      I don't think this is really true. This may depend on the country
      and the people one communicates with. If users still send mail from
      an IP without rDNS, there may be a reason...

      Moreover some major receivers may support IPv4 only for their MX,
      so that if the IPv4 address of the sender has a reverse hostname
      but not the IPv6 address, this user may not notice the problem.
      For instance, for two majors receivers in France:

      $ host -t mx free.fr
      free.fr mail is handled by 20 mx2.free.fr.
      free.fr mail is handled by 10 mx1.free.fr.
      $ host mx1.free.fr
      mx1.free.fr has address 212.27.48.7
      mx1.free.fr has address 212.27.48.6
      $ host mx2.free.fr
      mx2.free.fr has address 212.27.42.59
      mx2.free.fr has address 212.27.42.58

      $ host -t mx wanadoo.fr
      wanadoo.fr mail is handled by 10 smtp-in.orange.fr.
      $ host smtp-in.orange.fr
      smtp-in.orange.fr has address 80.12.242.9
      smtp-in.orange.fr has address 193.252.22.65

      $ host -t mx vinc17.net
      vinc17.net mail is handled by 10 ioooi.vinc17.net.
      $ host ioooi.vinc17.net
      ioooi.vinc17.net has address 92.243.22.117
      ioooi.vinc17.net has IPv6 address 2001:4b98:dc0:45:216:3eff:fe9b:eb2f

      So, the sender mentioned above would see no problems with the majors
      receivers (free.fr, wanadoo.fr), where IPv4 will be used, but if I
      configure Postfix with reject_unknown_reverse_client_hostname on my
      domain, the sender in question will see his mail rejected because
      IPv6 would be used and his IPv6 address doesn't have a reverse
      hostname.

      > Your would-be correspondent has trouble corresponding with
      > everyone. Eventually he should figure out that he can't run a mail
      > server on a dynamic IP address.
      >
      > Sure, you might choose to open your floodgates to these clients. I
      > guarantee the vast majority of them are spam zombies.

      This is what I can observe, but I was thinking about using
      reject_unknown_reverse_client_hostname-like filter with scoring.

      > > Anyway one should be able to configure *client*-side mail software
      > > without being a specialist of SMTP RFCs and things like that...
      >
      > Absolutely. You would have your MUA submit to a MSA. Your MSA would
      > not care about FCrDNS.

      I could do that since I have my own server.

      But I don't see this as a final solution since most users use a
      shared MSA and the outgoing mail server may be blacklisted more
      or less often (this is the case of my ISP, which is frequently
      blacklisted by spamcop) or not reliable (e.g. at my lab, which
      has also been blacklisted several times due to some users with
      compromised machines). And running a local MSA would yield the
      same problems as not using a MSA.

      --
      Vincent Lefèvre <vincent@...> - Web: <http://www.vinc17.net/>
      100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
      Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
    • 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 12:43 PM
      • 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.