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

Re: reject_rbl_client syntax problem: fatal: RBL reply error: missing "]" character

Expand Messages
  • martijn.list
    ... rfc5782 says: There is no widely used convention for mapping sublist names to bits or values, beyond the convention that all A values SHOULD
    Message 1 of 6 , Dec 12, 2012
    • 0 Attachment
      On 12/12/2012 01:00 PM, Stan Hoeppner wrote:
      > On 12/11/2012 2:03 AM, martijn.list wrote:
      >
      >> I guess in practice hardly no one will use it in this form but since I'm
      >> working on a web gui on which users can enter some RBL syntax I had to
      >> check what formats are accepted or not.
      >
      > Then you need to read the RFC here:
      > http://tools.ietf.org/html/rfc5782
      >
      > For startes, only 127/8 is allowed in DNSxL replies. 127.0.0.1 is NOT
      > allowed. You may also want to put a help box on the screen with the
      > Posttfix documentation for reject_rbl_client, or a more average person
      > digestible version of it. I assume this is a control panel for paying
      > customers, who are usually not the most technical types.

      <nitpick mode>

      rfc5782 says:

      There is no widely used convention for mapping sublist names to bits
      or values, beyond the convention that all A values SHOULD be in the
      127.0.0.0/8 range to prevent unwanted network traffic if the value is
      erroneously used as an IP address.

      A should is not a must and a convention is a convention :)

      </nitpick mode>

      Anyway whether or not using anything other than 127/8 is beside the point.

      According to http://www.postfix.org/postconf.5.html#reject_rbl_client

      reject_rbl_client rbl_domain=d.d.d.d

      is a valid syntax. This was what I tested, nothing more nothing less.
      The Postfix main config parser didn't like the first "d" to be placed
      within square brackets even though the documentation says this should be
      possible, again whether or not you should do this is beside the (my)
      point. Wietse created a patch for this a few days back (12/10/2012).

      Using anything other than 127/8 is discouraged and probably never tested
      by anyone. However the implementation was not in line with the
      documentation or vice versa :)

      Kind regards,

      Martijn Brinkers

      --
      DJIGZO email encryption
    Your message has been successfully submitted and would be delivered to recipients shortly.