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

Re: 454 instead 5xx status for "Relay access denied"

Expand Messages
  • Viktor Dukhovni
    ... Well, the hard fail is typically a good idea once one is sure the restrictions contain all the required permits. Some sites may depend on
    Message 1 of 10 , Apr 28, 2013
    • 0 Attachment
      On Sun, Apr 28, 2013 at 11:10:10PM -0500, Stan Hoeppner wrote:

      > > There is an important difference, which is why the defer variant
      > > is used as a safety net, and the use-case is precisely when the
      > > client is an MTA.
      >
      > Apparently I didn't make my point clear, which is that a hard fail isn't
      > necessary here, and that a temp fail is preferable to cover all client
      > types. I think Reindl was advocating a hard fail. I was countering his
      > argument.

      Well, the hard fail is typically a good idea once one is sure the
      restrictions contain all the required permits. Some sites may
      depend on check_client_access or check_recipient_access table
      lookups to handle cases more complex than permit_mynetworks or
      permit_auth_destination.

      The point of the safety net is to give the site some time to notice
      before lots of mail bounces.

      If you're advocating leaving the defer safety net on all the time,
      in the case of relay permissions this is arguably not entirely
      unreasonable. One could argue that legitimate MTAs that queue and
      retry mail deliveries are not easily fooled into using some other
      MTA as an unauthorized relay, and that the relay restrictions should
      not reject mail for which the receiving MTA is an MX host.

      So in that sense, this particular safety net may also be usable on
      a long-term basis. The main problem case is with ISP MTAs that
      support relaying by authorized clients, when a client is misconfigured
      to continue to use the original MTA after switching ISPs or after
      a password reset... Then the client may keep trying to send
      repeatedly.

      A soft fail is in this case a feature from the perspective of the
      misconfigured client, but may increase load at the ISP if the client
      generates enough traffic. All in all, perhaps a rather small risk,
      since clients liable to be misconfigured this way are unlikely to
      constitude a substantial fraction of the ISPs mail load.

      --
      Viktor.
    • Reindl Harald
      ... that one is a temporary and the other a permenently error? that i can hardly complain that Apple Inc. is a idiotic company by trying again and again send
      Message 2 of 10 , Apr 29, 2013
      • 0 Attachment
        Am 29.04.2013 01:52, schrieb Stan Hoeppner:
        > On 4/28/2013 9:52 AM, Reindl Harald wrote:
        >> Am 28.04.2013 14:41, schrieb Wietse Venema:
        >>> Reindl Harald:
        >>>> 454: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
        >>>> 554: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
        >>>>
        >>>> was the default changed from 2.10-devel to 2.10 final?
        >>>
        >>> defer_unauth_destination etc.. is the default safety net for
        >>> sites that haven't set smtpd_relay_restrictions
        >>
        >> ah, i remembered correct it was set by "postfix upgrade-configuration"
        >> at the bottom of "main.cf", maybe the "safety net" should be the
        >> same as "postconf -d" which is "reject_unauth_destination"?
        >
        > What practical difference do you see between these two reject codes?
        > The client in this transaction is almost certainly not an MTA. It's
        > most likely rat/malware, which typically either:

        that one is a temporary and the other a permenently error?
        that i can hardly complain that Apple Inc. is a idiotic company
        by trying again and again send mails from iPhones without
        SMTP-Auth even after a hard-error when i randomly answer
        with a soft error?

        > And BTW, reject_unknown_reverse_client_hostname would have rejected much
        > earlier. This IP returns NXDOMAIN. Why aren't you using
        > reject_unknown_reverse_client_hostname?

        because it does not matter on a machine which is not MX for any single domain
      • Reindl Harald
        ... uhm as i said: * the machine is not MX for any single domain * the machine must not accept any unauthenticated message * and so any aerror is NOT tenporary
        Message 3 of 10 , Apr 29, 2013
        • 0 Attachment
          Am 29.04.2013 06:10, schrieb Stan Hoeppner:
          > On 4/28/2013 7:33 PM, Viktor Dukhovni wrote:
          >> There is an important difference, which is why the defer variant
          >> is used as a safety net, and the use-case is precisely when the
          >> client is an MTA.
          >
          > Apparently I didn't make my point clear, which is that a hard fail isn't
          > necessary here, and that a temp fail is preferable to cover all client
          > types. I think Reindl was advocating a hard fail. I was countering his
          > argument

          uhm as i said:

          * the machine is not MX for any single domain
          * the machine must not accept any unauthenticated message
          * and so any aerror is NOT tenporary until smtp auth is used
        Your message has been successfully submitted and would be delivered to recipients shortly.