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

Re: Postfix HELO FQDN requirement

Expand Messages
  • Robin Smidsrød
    ... I m just trying to figure out what to write in a policy document about this behaviour. A behaviour which is backed by a RFC has a lot of more weight
    Message 1 of 13 , Aug 3, 2009
    • 0 Attachment
      Wietse Venema wrote:
      > John Peach:
      >> On Mon, 03 Aug 2009 13:18:52 +0200
      >> Robin Smidsr__d <robin@...> wrote:
      >> [snip]
      >>> Willy De la Court wrote:
      >>>
      >>>
      >>> Does this mean that all of the reject rules are in fact not
      >>> RFC-conformant?
      >>>
      >>> The reason I mention reject_invalid_helo_hostname is that I'm unsure
      >>> if the IPv(4|6) address syntax is part of this rule (postfix version
      >>> 2.5.5, distributed with ubuntu 9.04).
      >>>
      >>> What about the two other reject rules? As far as I can tell, they are
      >>> both non-conformant.
      >> Your server, your rules.
      >
      > Indeed. RFCs are relevant only when parties want to interoperate.
      > Generally, there is no such desire on the receiving end of SPAM.

      I'm just trying to figure out what to write in a policy document about
      this behaviour. A behaviour which is backed by a RFC has a lot of more
      weight (conserning interoperability) than our own policies about what is
      accepted behaviour or not.

      When a legitimate server is rejected it is generally easier to say "the
      admin of that server has not set up his server correctly according to
      the standard. Make him fix it if you want to receive email from them."
      than it is to say "our policies does not allow a connection like that
      because the email is usually spam". The last one is a tempting reason
      for a customer to leave and find another service provider (because it
      rejects legitimate email). Whitelisting is (usually) a manual job, and
      anything that is manual work requires human intervention (i.e. usually
      not something you want).

      What does the reject_invalid_helo_hostname rule do with the IPv(4|6)
      HELO response? I mean, when the "domain" looks like [10.1.2.3] or [::1]?
      Does it accept or reject it? According to the RFC it should be valid.

      reject_non_fqdn_helo_hostname means that the "domain" needs to contain
      at least a dot, and otherwise conform to the DNS naming standards, am I
      correct? Will this rule short-circuit *accept* a IPv4/6 "domain", as
      defined above, or will it reject it?

      If you don't use these reject rules, will warnings (as suggested by the
      RFCs) be inserted in the Received: line (or somewhere else in the
      header)? If it is I can use this as input to a mail filter.

      Regards,
      Robin, which is trying to build a mail system which puts the choice of
      rejecting/filtering email in the hands of the end user.
    • /dev/rob0
      ... It s subjective. In my subjective experience, I have never seen a bad HELO (non-FQDN or invalid, or even valid bracketed [ip.add.re.ss]) delivering good
      Message 2 of 13 , Aug 3, 2009
      • 0 Attachment
        On Monday 03 August 2009 07:58:48 Robin Smidsrød wrote:
        > Wietse Venema wrote:
        > > John Peach:
        > >> On Mon, 03 Aug 2009 13:18:52 +0200
        > >> Robin Smidsr__d <robin@...> wrote:
        > >> [snip]
        > >>
        > >>> Willy De la Court wrote:
        > >>>
        > >>>
        > >>> Does this mean that all of the reject rules are in fact not
        > >>> RFC-conformant?
        > >>>
        > >>> The reason I mention reject_invalid_helo_hostname is that I'm unsure
        > >>> if the IPv(4|6) address syntax is part of this rule (postfix version
        > >>> 2.5.5, distributed with ubuntu 9.04).
        > >>>
        > >>> What about the two other reject rules? As far as I can tell, they are
        > >>> both non-conformant.
        > >>
        > >> Your server, your rules.
        > >
        > > Indeed. RFCs are relevant only when parties want to interoperate.
        > > Generally, there is no such desire on the receiving end of SPAM.
        >
        > I'm just trying to figure out what to write in a policy document about
        > this behaviour. A behaviour which is backed by a RFC has a lot of more
        > weight (conserning interoperability) than our own policies about what is
        > accepted behaviour or not.

        It's subjective. In my subjective experience, I have never seen a bad
        HELO (non-FQDN or invalid, or even valid bracketed [ip.add.re.ss])
        delivering good mail. (YMMV if you don't know how to separate your
        users' submission from MX. MUAs often do EHLO with the bracketed
        [ip.add.re.ss] syntax. But no real MTA does it, IME.)

        It's difficult to put your subjective experiences into a policy
        document that would allow a person who lacks knowledge of the subject
        area to make an informed decision. A lot of the "informed" part can
        only come with experience.

        > When a legitimate server is rejected it is generally easier to say "the
        > admin of that server has not set up his server correctly according to
        > the standard. Make him fix it if you want to receive email from them."
        > than it is to say "our policies does not allow a connection like that
        > because the email is usually spam". The last one is a tempting reason
        > for a customer to leave and find another service provider (because it

        Does this happen in the real world? Possibly. But what are the
        alternatives? Allow ALL the spam through, maybe doing some expensive
        content filtering which is slightly less accurate than pre-DATA checks
        (and far more prone to actual loss of mail, when users do not check
        their spam folders) -- or, block what you know to be garbage and take
        your chance with clueless customers and clueless competitors?

        But seriously, reject_non_fqdn_helo_hostname and
        reject_invalid_helo_hostname are not likely to block real MX mail.

        > rejects legitimate email). Whitelisting is (usually) a manual job, and
        > anything that is manual work requires human intervention (i.e. usually
        > not something you want).
        >
        > What does the reject_invalid_helo_hostname rule do with the IPv(4|6)
        > HELO response? I mean, when the "domain" looks like [10.1.2.3] or [::1]?
        > Does it accept or reject it? According to the RFC it should be valid.

        It IS valid. "Invalid" means "not valid under RFC standards." However,
        again, I have never known a real MTA to use that syntax, only MUAs and
        spambots. I therefore made the policy decision to reject those (after
        permit_* restrictions.)

        > reject_non_fqdn_helo_hostname means that the "domain" needs to contain
        > at least a dot, and otherwise conform to the DNS naming standards, am I
        > correct? Will this rule short-circuit *accept* a IPv4/6 "domain", as
        > defined above, or will it reject it?

        A bracketed [ip.add.re.ss] is not a non-FQDN HELO. Common ones I've
        seen include "friend", and strings which appear to be infected Windows
        PC netbios names.

        > If you don't use these reject rules, will warnings (as suggested by the
        > RFCs) be inserted in the Received: line (or somewhere else in the
        > header)? If it is I can use this as input to a mail filter.

        Received lines are constructed the same way for all accepted mail,
        augmented only by some TLS settings.

        > Regards,
        > Robin, which is trying to build a mail system which puts the
        > choice of rejecting/filtering email in the hands of the end user.

        While that sounds like a noble goal, I see lots of problems with it.
        Chief among those is the fact that end users often cannot distinguish
        spam from unwanted legitimate email. I think mail administration needs
        much MORE professionalism (paternalism, you might even say), not less.
        Good luck.
        --
        Offlist mail to this address is discarded unless
        "/dev/rob0" or "not-spam" is in Subject: header
      • Robin Smidsrød
        ... All my servers/users are either listed in mynetworks or use sasl auth, and they go before any HELO reject rule, so they should be in the clear. ... I ve
        Message 3 of 13 , Aug 4, 2009
        • 0 Attachment
          /dev/rob0 wrote:
          > On Monday 03 August 2009 07:58:48 Robin Smidsrød wrote:
          >> I'm just trying to figure out what to write in a policy document about
          >> this behaviour. A behaviour which is backed by a RFC has a lot of more
          >> weight (conserning interoperability) than our own policies about what is
          >> accepted behaviour or not.
          >
          > It's subjective. In my subjective experience, I have never seen a bad
          > HELO (non-FQDN or invalid, or even valid bracketed [ip.add.re.ss])
          > delivering good mail. (YMMV if you don't know how to separate your
          > users' submission from MX. MUAs often do EHLO with the bracketed
          > [ip.add.re.ss] syntax. But no real MTA does it, IME.)

          All my servers/users are either listed in mynetworks or use sasl auth,
          and they go before any HELO reject rule, so they should be in the clear.

          >> When a legitimate server is rejected it is generally easier to say "the
          >> admin of that server has not set up his server correctly according to
          >> the standard. Make him fix it if you want to receive email from them."
          >> than it is to say "our policies does not allow a connection like that
          >> because the email is usually spam". The last one is a tempting reason
          >> for a customer to leave and find another service provider (because it
          >
          > Does this happen in the real world? Possibly.

          I've had at least one client leave because he absolutely needs to have
          every email, because every single email he receives could be really
          important. So dealing with spam is something he just has to do. On the
          other hand I have users that don't really care one way or the other. I
          just want to be able to let the user make that choice. And rejecting
          email based on (possibly forged) helo is a system-wide policy, not a
          user-specific policy. Is it possible to make this a user-policy?

          > But what are the
          > alternatives? Allow ALL the spam through, maybe doing some expensive
          > content filtering which is slightly less accurate than pre-DATA checks
          > (and far more prone to actual loss of mail, when users do not check
          > their spam folders) -- or, block what you know to be garbage and take
          > your chance with clueless customers and clueless competitors?

          Well, my way of dealing with the problem is to actually filter the email
          (statistical filtering) and let the user decide what they want to do
          with it (quarantine, tag or reject). That way I haven't taken the choice
          away from them. Yes it costs more (in terms of resources), but it makes
          it possible to cater to those clients that really don't want mail to be
          rejected.

          >
          > But seriously, reject_non_fqdn_helo_hostname and
          > reject_invalid_helo_hostname are not likely to block real MX mail.

          Thanks for the clarifications. I've re-enabled them, ignored the
          whitelist (for now) to see how these rules actually pan out.
          reject_unknown_helo_hostname is still disabled. It was the main rule
          that required whitelisting in the first place.

          >> What does the reject_invalid_helo_hostname rule do with the IPv(4|6)
          >> HELO response? I mean, when the "domain" looks like [10.1.2.3] or [::1]?
          >> Does it accept or reject it? According to the RFC it should be valid.
          >
          > It IS valid. "Invalid" means "not valid under RFC standards." However,
          > again, I have never known a real MTA to use that syntax, only MUAs and
          > spambots. I therefore made the policy decision to reject those (after
          > permit_* restrictions.)

          Thanks for the clarification. I've re-enabled it to see if it blocks
          anything legitimate.

          >> reject_non_fqdn_helo_hostname means that the "domain" needs to contain
          >> at least a dot, and otherwise conform to the DNS naming standards, am I
          >> correct? Will this rule short-circuit *accept* a IPv4/6 "domain", as
          >> defined above, or will it reject it?
          >
          > A bracketed [ip.add.re.ss] is not a non-FQDN HELO. Common ones I've
          > seen include "friend", and strings which appear to be infected Windows
          > PC netbios names.

          Thanks again.

          > Received lines are constructed the same way for all accepted mail,
          > augmented only by some TLS settings.

          Is there any documentation for how it is constructed, or do I need to
          look in the source code?

          >> Regards,
          >> Robin, which is trying to build a mail system which puts the
          >> choice of rejecting/filtering email in the hands of the end user.
          >
          > While that sounds like a noble goal, I see lots of problems with it.
          > Chief among those is the fact that end users often cannot distinguish
          > spam from unwanted legitimate email.

          That doesn't really bother me so much. If it "feels" like spam to them
          they may classify it as such. It only influences the user himself. Of
          course, if they classify mailing lists as spam it will only fill up
          their junkmail box, which will just influence their allotted storage
          capacity (quota).

          > I think mail administration needs
          > much MORE professionalism (paternalism, you might even say), not less.

          I highly agree with you there. That is what I'm trying to build. A well
          documented, with clear policies, mail system which can cater to both of
          the user types mentioned above.

          -- Robin
        • Mikael Bak
          ... Hi Robin, It is possible to make rules user and/or domain dependant with carefully built restriction classes. If you haven t read this already, please do:
          Message 4 of 13 , Aug 4, 2009
          • 0 Attachment
            Robin Smidsrød wrote:
            >
            > I've had at least one client leave because he absolutely needs to have
            > every email, because every single email he receives could be really
            > important. So dealing with spam is something he just has to do. On the
            > other hand I have users that don't really care one way or the other. I
            > just want to be able to let the user make that choice. And rejecting
            > email based on (possibly forged) helo is a system-wide policy, not a
            > user-specific policy. Is it possible to make this a user-policy?
            >

            Hi Robin,

            It is possible to make rules user and/or domain dependant with carefully
            built restriction classes. If you haven't read this already, please do:

            http://www.postfix.org/RESTRICTION_CLASS_README.html

            The examples here are not exactly what you want, but you will get an
            idea of how you can build user / domain specific rules.

            HTH,
            Mikael
          • Robin Smidsrød
            ... Thanks for the link. It indeed explains how to make rules user-definable. Of course, to enable use of check_recipient_access in smtpd_helo_restrictions,
            Message 5 of 13 , Aug 4, 2009
            • 0 Attachment
              Mikael Bak wrote:
              > Robin Smidsrød wrote:
              >> I've had at least one client leave because he absolutely needs to have
              >> every email, because every single email he receives could be really
              >> important. So dealing with spam is something he just has to do. On the
              >> other hand I have users that don't really care one way or the other. I
              >> just want to be able to let the user make that choice. And rejecting
              >> email based on (possibly forged) helo is a system-wide policy, not a
              >> user-specific policy. Is it possible to make this a user-policy?
              >>
              > It is possible to make rules user and/or domain dependant with carefully
              > built restriction classes. If you haven't read this already, please do:
              >
              > http://www.postfix.org/RESTRICTION_CLASS_README.html

              Thanks for the link. It indeed explains how to make rules user-definable.

              Of course, to enable use of check_recipient_access in
              smtpd_helo_restrictions, smtpd_delay_reject must obviously be set to Yes
              (the default).

              -- Robin
            • Noel Jones
              ... You can also use a check_recipient_access table that returns the restrictions you want applied to that particular recipient domain or user. As long as
              Message 6 of 13 , Aug 4, 2009
              • 0 Attachment
                Robin Smidsrød wrote:
                > Mikael Bak wrote:
                >> Robin Smidsrød wrote:
                >>> I've had at least one client leave because he absolutely needs to have
                >>> every email, because every single email he receives could be really
                >>> important. So dealing with spam is something he just has to do. On the
                >>> other hand I have users that don't really care one way or the other. I
                >>> just want to be able to let the user make that choice. And rejecting
                >>> email based on (possibly forged) helo is a system-wide policy, not a
                >>> user-specific policy. Is it possible to make this a user-policy?
                >>>
                >> It is possible to make rules user and/or domain dependant with carefully
                >> built restriction classes. If you haven't read this already, please do:
                >>
                >> http://www.postfix.org/RESTRICTION_CLASS_README.html
                >
                > Thanks for the link. It indeed explains how to make rules user-definable.
                >
                > Of course, to enable use of check_recipient_access in
                > smtpd_helo_restrictions, smtpd_delay_reject must obviously be set to Yes
                > (the default).
                >
                > -- Robin
                >

                You can also use a check_recipient_access table that returns
                the restrictions you want applied to that particular recipient
                domain or user. As long as you're not doing table lookups,
                you don't need smtpd_restriction_classes.

                smtpd_recipient_restrictions =
                ...
                check_recipient_access hash:/etc/postfix/restrictions
                ...

                # /etc/postfix/restrictions
                user@... reject_non_fqdn_hostname, reject_rbl_clie...
                example.com permit_auth_destination
                ...


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