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

Re: remote smtp auth clients - header rewrite question

Expand Messages
  • Noel Jones
    ... Don t bother. The postfix REPLACE action does not support newlines in headers regardless of the map type used. The only possible workaround is to add
    Message 1 of 21 , Nov 29, 2008
    • 0 Attachment
      john mickler wrote:
      >
      > As for the newline insertion mentioned on the website, I'm wondering
      > if using a pcre instead of standard regex would allow this. I'm going
      > to translate and give it a try.

      Don't bother. The postfix REPLACE action does not support
      newlines in headers regardless of the map type used.

      The only possible "workaround" is to add code to postfix
      supporting multi-line header insertion.

      --
      Noel Jones
    • Dan Langille
      ... My error. I have contacted the author.
      Message 2 of 21 , Nov 29, 2008
      • 0 Attachment
        Sahil Tandon wrote:
        > Dan Langille <dan@...> wrote:
        >
        >> Sahil Tandon wrote:
        >>> john mickler <micklerman@...> wrote:
        >>>
        >>>> I have a question pertaining to message headers on outbound mail from
        >>>> remote smtp auth'd clients. I have been asked to adjust our mail systems to
        >>>> "anonymize" said remote clients. Using mail sent from an Iphone as an example,
        >>>> the headers on the receiving end show:
        >>>>
        >>>> Received: from [10.176.149.227] (unknown [32.136.180.43])
        >>>> (using TLSv1 with cipher AES128-SHA (128/128 bits))
        >>>> (No client certificate requested)
        >>>> by smtp.ourcompany.com (Postfix) with ESMTPSA id 593E0BA56
        >>>> for <mrsmith@...>; Sat, 29 Nov 2008 15:20:06 -0500 (EST)
        >>>>
        >>>>
        >>>> The desired outcome is to have the above adjusted to something similar
        >>>> to:
        >>>>
        >>>> Received: from remote-client.ourcompany.com
        >>>> (remote-client.ourcompany.com [RECEIVING.INTERFACE.IP.HERE])
        >>>> (using TLSv1 with cipher AES128-SHA (128/128 bits))
        >>>> (No client certificate requested)
        >>>> by smtp.ourcompany.com (Postfix) with ESMTPSA id 593E0BA56
        >>>> for <mrsmith@...>; Sat, 29 Nov 2008 15:20:06 -0500 (EST)
        >>>>
        >>>> I have attempted to mess around with header_checks assuming that this
        >>>> is where the REWRITE would go, but it doesn't seem like I'm getting
        >>>> anywhere.
        >>> You need REPLACE, not REWRITE.
        >>>
        >>> See http://riseuplabs.org/privacy/postfix/; ignore the patch section and
        >>> scroll down to "Postfix 2.3 and later". Copy and modify as necessary to
        >>> meet your needs.
        >>>
        >> offlist reply...
        >>
        >> At the above URL, I see "becareful". I think you want "be careful".
        >
        > I certainly do, but it's not my web site. :-)
        >

        My error. I have contacted the author.
      • Victor Duchovni
        ... It should work if the newline is part of a ${n} sub-pattern match: # ${3} matches Newline + folding white-space /^(Received): (.*?)( n[ t x20])(.*)$/ ${1}:
        Message 3 of 21 , Nov 29, 2008
        • 0 Attachment
          On Sat, Nov 29, 2008 at 10:24:25PM -0600, Noel Jones wrote:

          > john mickler wrote:
          > >
          > >As for the newline insertion mentioned on the website, I'm wondering
          > >if using a pcre instead of standard regex would allow this. I'm going
          > >to translate and give it a try.
          >
          > Don't bother. The postfix REPLACE action does not support
          > newlines in headers regardless of the map type used.
          >
          > The only possible "workaround" is to add code to postfix
          > supporting multi-line header insertion.

          It should work if the newline is part of a ${n} sub-pattern match:

          # ${3} matches Newline + folding white-space
          /^(Received): (.*?)(\n[\t\x20])(.*)$/
          ${1}: ${2}${3}(my comment)${3}${4}

          With test.pcre containing the above, "postmap -q" yields:

          $ postmap -q "$(printf "Received: %s\n\t%s\n" abc def)" pcre:test.pcre
          Received: abc
          (my comment)
          def

          showing the insertion of an additional line into the header. What is not
          possible is the insertion of a literal newline in the Postfix replacement
          text in indexed file, regexp table or policy service lookups.

          --
          Viktor.

          Disclaimer: off-list followups get on-list replies or get ignored.
          Please do not ignore the "Reply-To" header.

          To unsubscribe from the postfix-users list, visit
          http://www.postfix.org/lists.html or click the link below:
          <mailto:majordomo@...?body=unsubscribe%20postfix-users>

          If my response solves your problem, the best way to thank me is to not
          send an "it worked, thanks" follow-up. If you must respond, please put
          "It worked, thanks" in the "Subject" so I can delete these quickly.
        • Wietse Venema
          ... That will likely remain impossible, because preserving newlines in config files means having to put additional checks throughout Postfix for all the cases
          Message 4 of 21 , Nov 30, 2008
          • 0 Attachment
            Victor Duchovni:
            > On Sat, Nov 29, 2008 at 10:24:25PM -0600, Noel Jones wrote:
            >
            > > john mickler wrote:
            > > >
            > > >As for the newline insertion mentioned on the website, I'm wondering
            > > >if using a pcre instead of standard regex would allow this. I'm going
            > > >to translate and give it a try.
            > >
            > > Don't bother. The postfix REPLACE action does not support
            > > newlines in headers regardless of the map type used.
            > >
            > > The only possible "workaround" is to add code to postfix
            > > supporting multi-line header insertion.
            >
            > It should work if the newline is part of a ${n} sub-pattern match:
            >
            > # ${3} matches Newline + folding white-space
            > /^(Received): (.*?)(\n[\t\x20])(.*)$/
            > ${1}: ${2}${3}(my comment)${3}${4}
            >
            > With test.pcre containing the above, "postmap -q" yields:
            >
            > $ postmap -q "$(printf "Received: %s\n\t%s\n" abc def)" pcre:test.pcre
            > Received: abc
            > (my comment)
            > def
            >
            > showing the insertion of an additional line into the header. What is not
            > possible is the insertion of a literal newline in the Postfix replacement
            > text in indexed file, regexp table or policy service lookups.

            That will likely remain impossible, because preserving newlines in
            config files means having to put additional checks throughout
            Postfix for all the cases where newlines would cause trouble.
            Every map lookup would have to be scrutinized, and when adding
            new code, someone would almost certainly overlook the possibility
            of unexpected newlines and introduce bugs.

            Wietse
          • john mickler
            On Sun, Nov 30, 2008 at 12:18 AM, Victor Duchovni ... The pcre example above indeed passes the newline through as mentioned. Here s an adjusted expression to
            Message 5 of 21 , Nov 30, 2008
            • 0 Attachment
              On Sun, Nov 30, 2008 at 12:18 AM, Victor Duchovni
              <Victor.Duchovni@...> wrote:
              > It should work if the newline is part of a ${n} sub-pattern match:
              >
              > # ${3} matches Newline + folding white-space
              > /^(Received): (.*?)(\n[\t\x20])(.*)$/
              > ${1}: ${2}${3}(my comment)${3}${4}
              >
              > With test.pcre containing the above, "postmap -q" yields:
              >
              > $ postmap -q "$(printf "Received: %s\n\t%s\n" abc def)" pcre:test.pcre
              > Received: abc
              > (my comment)
              > def
              >
              > showing the insertion of an additional line into the header. What is not
              > possible is the insertion of a literal newline in the Postfix replacement
              > text in indexed file, regexp table or policy service lookups.

              The pcre example above indeed passes the newline through as mentioned.
              Here's an adjusted expression to fit my situation, as well as an
              example header after the replacement:

              main.cf:
              header_checks = /usr/local/etc/postfix/maps/header_checks.pcre

              header_checks.pcre:
              /^(Received): (.*?)(\n[\t\x20])(.*)$/ REPLACE ${1}: from smtp-auth
              (smtp-auth.mycompany.com [55.55.55.55]${3}${4}


              resulting replaced header-

              Received: from smtp-auth (smtp-auth.mycompany.com [55.55.55.55]
              (using TLSv1 with cipher AES128-SHA (128/128 bits))
              (No client certificate requested)
              (Authenticated sender: mrsmith@...)
              by smtp.mycompany.com (Postfix) with ESMTPSA id EA8E9B879
              for <mrssmith@...>; Sun, 30 Nov 2008 11:58:51
              -0500 (EST)



              The beauty is that all other header information besides the actual
              remote host is kept intact - in my eyes making this a perfect solution
              for my situation.

              Thanks Victor, and thanks to everyone else for their input.
            • mouss
              ... but the lack of beauty is the invalid HELO smtp-auth . why not use smtp-auth.mycompany.com instead?
              Message 6 of 21 , Nov 30, 2008
              • 0 Attachment
                john mickler a écrit :
                > The pcre example above indeed passes the newline through as mentioned.
                > Here's an adjusted expression to fit my situation, as well as an
                > example header after the replacement:
                >
                > main.cf:
                > header_checks = /usr/local/etc/postfix/maps/header_checks.pcre
                >
                > header_checks.pcre:
                > /^(Received): (.*?)(\n[\t\x20])(.*)$/ REPLACE ${1}: from smtp-auth
                > (smtp-auth.mycompany.com [55.55.55.55]${3}${4}
                >
                >
                > resulting replaced header-
                >
                > Received: from smtp-auth (smtp-auth.mycompany.com [55.55.55.55]
                > (using TLSv1 with cipher AES128-SHA (128/128 bits))
                > (No client certificate requested)
                > (Authenticated sender: mrsmith@...)
                > by smtp.mycompany.com (Postfix) with ESMTPSA id EA8E9B879
                > for <mrssmith@...>; Sun, 30 Nov 2008 11:58:51
                > -0500 (EST)
                >
                >
                >
                > The beauty is that all other header information besides the actual
                > remote host is kept intact - in my eyes making this a perfect solution
                > for my situation.

                but the lack of beauty is the invalid HELO "smtp-auth". why not use
                "smtp-auth.mycompany.com" instead?

                >
                > Thanks Victor, and thanks to everyone else for their input.
              • Victor Duchovni
                ... I would recommend an RFC1918 address, e.g. 10.0.0.1. You could even include the first 3 octets of the real IP as the last 3 octets of the 10/8 address.
                Message 7 of 21 , Nov 30, 2008
                • 0 Attachment
                  On Sun, Nov 30, 2008 at 12:18:45PM -0500, john mickler wrote:

                  > /^(Received): (.*?)(\n[\t\x20])(.*)$/ REPLACE ${1}: from smtp-auth
                  > (smtp-auth.mycompany.com [55.55.55.55]${3}${4}
                  >
                  >
                  > resulting replaced header-
                  >
                  > Received: from smtp-auth (smtp-auth.mycompany.com [55.55.55.55]
                  > (using TLSv1 with cipher AES128-SHA (128/128 bits))
                  > (No client certificate requested)
                  > (Authenticated sender: mrsmith@...)
                  > by smtp.mycompany.com (Postfix) with ESMTPSA id EA8E9B879
                  > for <mrssmith@...>; Sun, 30 Nov 2008 11:58:51 -0500 (EST)

                  I would recommend an RFC1918 address, e.g. 10.0.0.1. You could even include
                  the first 3 octets of the real IP as the last 3 octets of the 10/8 address.
                  That way, you don't lose all information, although of course the full
                  addresss is still in your logs for the queue-id in question.

                  --
                  Viktor.

                  Disclaimer: off-list followups get on-list replies or get ignored.
                  Please do not ignore the "Reply-To" header.

                  To unsubscribe from the postfix-users list, visit
                  http://www.postfix.org/lists.html or click the link below:
                  <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                  If my response solves your problem, the best way to thank me is to not
                  send an "it worked, thanks" follow-up. If you must respond, please put
                  "It worked, thanks" in the "Subject" so I can delete these quickly.
                • john mickler
                  ... Good point - map adjusted. Thanks :)
                  Message 8 of 21 , Nov 30, 2008
                  • 0 Attachment
                    On Sun, Nov 30, 2008 at 12:22 PM, mouss <mouss@...> wrote:
                    > john mickler a écrit :
                    >> The pcre example above indeed passes the newline through as mentioned.
                    >> Here's an adjusted expression to fit my situation, as well as an
                    >> example header after the replacement:
                    >>
                    >> main.cf:
                    >> header_checks = /usr/local/etc/postfix/maps/header_checks.pcre
                    >>
                    >> header_checks.pcre:
                    >> /^(Received): (.*?)(\n[\t\x20])(.*)$/ REPLACE ${1}: from smtp-auth
                    >> (smtp-auth.mycompany.com [55.55.55.55]${3}${4}
                    >>
                    >>
                    >> resulting replaced header-
                    >>
                    >> Received: from smtp-auth (smtp-auth.mycompany.com [55.55.55.55]
                    >> (using TLSv1 with cipher AES128-SHA (128/128 bits))
                    >> (No client certificate requested)
                    >> (Authenticated sender: mrsmith@...)
                    >> by smtp.mycompany.com (Postfix) with ESMTPSA id EA8E9B879
                    >> for <mrssmith@...>; Sun, 30 Nov 2008 11:58:51
                    >> -0500 (EST)
                    >>
                    >>
                    >>
                    >> The beauty is that all other header information besides the actual
                    >> remote host is kept intact - in my eyes making this a perfect solution
                    >> for my situation.
                    >
                    > but the lack of beauty is the invalid HELO "smtp-auth". why not use
                    > "smtp-auth.mycompany.com" instead?
                    >

                    Good point - map adjusted. Thanks :)
                  • Dan Langille
                    ... Following one from John s success, I m failing. One difference between John s setup and mine is my header_checks directive. It was defined in master.cf:
                    Message 9 of 21 , Nov 30, 2008
                    • 0 Attachment
                      john mickler wrote:
                      > On Sun, Nov 30, 2008 at 12:18 AM, Victor Duchovni
                      > <Victor.Duchovni@...> wrote:
                      >> It should work if the newline is part of a ${n} sub-pattern match:
                      >>
                      >> # ${3} matches Newline + folding white-space
                      >> /^(Received): (.*?)(\n[\t\x20])(.*)$/
                      >> ${1}: ${2}${3}(my comment)${3}${4}
                      >>
                      >> With test.pcre containing the above, "postmap -q" yields:
                      >>
                      >> $ postmap -q "$(printf "Received: %s\n\t%s\n" abc def)" pcre:test.pcre
                      >> Received: abc
                      >> (my comment)
                      >> def
                      >>
                      >> showing the insertion of an additional line into the header. What is not
                      >> possible is the insertion of a literal newline in the Postfix replacement
                      >> text in indexed file, regexp table or policy service lookups.
                      >
                      > The pcre example above indeed passes the newline through as mentioned.
                      > Here's an adjusted expression to fit my situation, as well as an
                      > example header after the replacement:
                      >
                      > main.cf:
                      > header_checks = /usr/local/etc/postfix/maps/header_checks.pcre
                      >
                      > header_checks.pcre:
                      > /^(Received): (.*?)(\n[\t\x20])(.*)$/ REPLACE ${1}: from smtp-auth
                      > (smtp-auth.mycompany.com [55.55.55.55]${3}${4}
                      >
                      >
                      > resulting replaced header-
                      >
                      > Received: from smtp-auth (smtp-auth.mycompany.com [55.55.55.55]
                      > (using TLSv1 with cipher AES128-SHA (128/128 bits))
                      > (No client certificate requested)
                      > (Authenticated sender: mrsmith@...)
                      > by smtp.mycompany.com (Postfix) with ESMTPSA id EA8E9B879
                      > for <mrssmith@...>; Sun, 30 Nov 2008 11:58:51
                      > -0500 (EST)
                      >
                      >
                      >
                      > The beauty is that all other header information besides the actual
                      > remote host is kept intact - in my eyes making this a perfect solution
                      > for my situation.
                      >
                      > Thanks Victor, and thanks to everyone else for their input.

                      Following one from John's success, I'm failing. One difference between
                      John's setup and mine is my header_checks directive. It was defined in
                      master.cf:

                      -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth

                      I know I'm putting this directive into the direct Postfix daemon becuase
                      the remove of the following directive, from within the same declaration,
                      affects the email headers:

                      -o smtpd_sasl_authenticated_header=yes


                      I had to move this header_checks directive into main.cf to get the
                      REPLACE working.

                      The expression I'm using does the following:
                      - replaces the authenticated user
                      - replaces the host/ip address of the origin host
                      - retains the original spacing/newlines

                      /^Received: from (.* \([-._[:alnum:]]+
                      \[[.[:digit:]]{7,15}\]\))(.*)\(Authenticated sender: ([^)]+)\)(.*)(by
                      nyi\.unixathome\.org) \(([^)]+)\) with (E?SMTPS?A?) id
                      ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-auth.unixathome.org
                      (smtp-auth.unixathome.org [10.4.7.7])$2(Authenticated sender:
                      hidden)$4$5 ($6) with $7 id $8 $9

                      Thanks.
                    • mouss
                      ... did you add that to an smtpd service? see below. ... you can do it in master.cf: submission ... smtpd -o smtpd_sasl_authenticated_header=yes -o
                      Message 10 of 21 , Nov 30, 2008
                      • 0 Attachment
                        Dan Langille a écrit :
                        > Following one from John's success, I'm failing. One difference between
                        > John's setup and mine is my header_checks directive. It was defined in
                        > master.cf:
                        >
                        > -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth
                        >

                        did you add that to an smtpd service? see below.

                        > I know I'm putting this directive into the direct Postfix daemon becuase
                        > the remove of the following directive, from within the same declaration,
                        > affects the email headers:
                        >
                        > -o smtpd_sasl_authenticated_header=yes
                        >
                        >
                        > I had to move this header_checks directive into main.cf to get the
                        > REPLACE working.
                        >

                        you can do it in master.cf:

                        submission ... smtpd
                        -o smtpd_sasl_authenticated_header=yes
                        -o cleanup_service_name=cleanmsa
                        ...

                        cleanmsa .... cleanup
                        -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth



                        > The expression I'm using does the following:
                        > - replaces the authenticated user
                        > - replaces the host/ip address of the origin host
                        > - retains the original spacing/newlines
                        >
                        > /^Received: from (.* \([-._[:alnum:]]+
                        > \[[.[:digit:]]{7,15}\]\))(.*)\(Authenticated sender: ([^)]+)\)(.*)(by
                        > nyi\.unixathome\.org) \(([^)]+)\) with (E?SMTPS?A?) id
                        > ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-auth.unixathome.org
                        > (smtp-auth.unixathome.org [10.4.7.7])$2(Authenticated sender:
                        > hidden)$4$5 ($6) with $7 id $8 $9
                        >
                      • Dan Langille
                        ... I tried it like this: 10.0.0.1:smtps inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions
                        Message 11 of 21 , Nov 30, 2008
                        • 0 Attachment
                          On Nov 30, 2008, at 4:13 PM, mouss wrote:

                          > Dan Langille a écrit :
                          >> Following one from John's success, I'm failing. One difference
                          >> between
                          >> John's setup and mine is my header_checks directive. It was
                          >> defined in
                          >> master.cf:
                          >>
                          >> -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth
                          >>
                          >
                          > did you add that to an smtpd service? see below.
                          >
                          >> I know I'm putting this directive into the direct Postfix daemon
                          >> becuase
                          >> the remove of the following directive, from within the same
                          >> declaration,
                          >> affects the email headers:
                          >>
                          >> -o smtpd_sasl_authenticated_header=yes
                          >>
                          >>
                          >> I had to move this header_checks directive into main.cf to get the
                          >> REPLACE working.
                          >>
                          >
                          > you can do it in master.cf:
                          >
                          > submission ... smtpd
                          > -o smtpd_sasl_authenticated_header=yes
                          > -o cleanup_service_name=cleanmsa
                          > ...
                          >
                          > cleanmsa .... cleanup
                          > -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth

                          I tried it like this:

                          10.0.0.1:smtps inet n - n - - smtpd
                          -o smtpd_sasl_auth_enable=yes
                          -o
                          smtpd_recipient_restrictions
                          =permit_sasl_authenticated,reject_unauth_desti
                          -o smtpd_sasl_type=dovecot
                          -o smtpd_sasl_path=private/auth
                          -o smtpd_sasl_authenticated_header=yes
                          -o smtpd_tls_security_level=encrypt
                          -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth
                          -o smtpd_tls_wrappermode=yes
                          -o smtpd_tls_cert_file=/usr/local/etc/CERTS/nyi.example.org
                          -o smtpd_tls_key_file=/usr/local/etc/CERTS/nyi.example.org.
                          -o smtpd_client_restrictions=$smtps_client_restrictions
                          -o smtpd_helo_restrictions=$smtps_helo_restrictions
                          -o smtpd_sender_restrictions=$smtps_sender_restrictions

                          >

                          >
                          >
                          >
                          >> The expression I'm using does the following:
                          >> - replaces the authenticated user
                          >> - replaces the host/ip address of the origin host
                          >> - retains the original spacing/newlines
                          >>
                          >> /^Received: from (.* \([-._[:alnum:]]+
                          >> \[[.[:digit:]]{7,15}\]\))(.*)\(Authenticated sender: ([^)]+)\)(.*)(by
                          >> nyi\.unixathome\.org) \(([^)]+)\) with (E?SMTPS?A?) id
                          >> ([A-F[:digit:]]+)(.*)/ REPLACE Received: from smtp-
                          >> auth.unixathome.org
                          >> (smtp-auth.unixathome.org [10.4.7.7])$2(Authenticated sender:
                          >> hidden)$4$5 ($6) with $7 id $8 $9
                          >>

                          --
                          Dan Langille
                          http://langille.org/
                        • Victor Duchovni
                          ... Did you see header_checks documented as a supported parameter in http://www.postfix.org/smtpd.8.html (rhetorical question, the answer is no). A closer look
                          Message 12 of 21 , Nov 30, 2008
                          • 0 Attachment
                            On Sun, Nov 30, 2008 at 06:40:18PM -0500, Dan Langille wrote:

                            > I tried it like this:
                            >
                            > 10.0.0.1:smtps inet n - n - - smtpd
                            > -o smtpd_sasl_auth_enable=yes
                            > -o
                            > smtpd_recipient_restrictions
                            > =permit_sasl_authenticated,reject_unauth_desti
                            > -o smtpd_sasl_type=dovecot
                            > -o smtpd_sasl_path=private/auth
                            > -o smtpd_sasl_authenticated_header=yes
                            > -o smtpd_tls_security_level=encrypt
                            > -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth
                            > -o smtpd_tls_wrappermode=yes
                            > -o smtpd_tls_cert_file=/usr/local/etc/CERTS/nyi.example.org
                            > -o smtpd_tls_key_file=/usr/local/etc/CERTS/nyi.example.org.
                            > -o smtpd_client_restrictions=$smtps_client_restrictions
                            > -o smtpd_helo_restrictions=$smtps_helo_restrictions
                            > -o smtpd_sender_restrictions=$smtps_sender_restrictions

                            Did you see header_checks documented as a supported parameter in
                            http://www.postfix.org/smtpd.8.html (rhetorical question, the answer
                            is no). A closer look at the documentation shows this ia feature of
                            the cleanup service:

                            <http://www.postfix.org/BUILTIN_FILTER_README.html#what>

                            --
                            Viktor.

                            Disclaimer: off-list followups get on-list replies or get ignored.
                            Please do not ignore the "Reply-To" header.

                            To unsubscribe from the postfix-users list, visit
                            http://www.postfix.org/lists.html or click the link below:
                            <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                            If my response solves your problem, the best way to thank me is to not
                            send an "it worked, thanks" follow-up. If you must respond, please put
                            "It worked, thanks" in the "Subject" so I can delete these quickly.
                          • Dan Langille
                            ... My ignorance is no secret, nor hidden. My error was pointed out to me on IRC. Mentioning here was in the interest of passing out trials and errors. I do
                            Message 13 of 21 , Dec 1, 2008
                            • 0 Attachment
                              On Dec 1, 2008, at 12:17 AM, Victor Duchovni wrote:

                              > On Sun, Nov 30, 2008 at 06:40:18PM -0500, Dan Langille wrote:
                              >
                              >> I tried it like this:
                              >>
                              >> 10.0.0.1:smtps inet n - n - - smtpd
                              >> -o smtpd_sasl_auth_enable=yes
                              >> -o
                              >> smtpd_recipient_restrictions
                              >> =permit_sasl_authenticated,reject_unauth_desti
                              >> -o smtpd_sasl_type=dovecot
                              >> -o smtpd_sasl_path=private/auth
                              >> -o smtpd_sasl_authenticated_header=yes
                              >> -o smtpd_tls_security_level=encrypt
                              >> -o header_checks=pcre:/usr/local/etc/postfix/obscure_smtp_auth
                              >> -o smtpd_tls_wrappermode=yes
                              >> -o smtpd_tls_cert_file=/usr/local/etc/CERTS/nyi.example.org
                              >> -o smtpd_tls_key_file=/usr/local/etc/CERTS/nyi.example.org.
                              >> -o smtpd_client_restrictions=$smtps_client_restrictions
                              >> -o smtpd_helo_restrictions=$smtps_helo_restrictions
                              >> -o smtpd_sender_restrictions=$smtps_sender_restrictions
                              >
                              > Did you see header_checks documented as a supported parameter in
                              > http://www.postfix.org/smtpd.8.html (rhetorical question, the answer
                              > is no). A closer look at the documentation shows this ia feature of
                              > the cleanup service:
                              >
                              > <http://www.postfix.org/BUILTIN_FILTER_README.html#what>


                              My ignorance is no secret, nor hidden. My error was pointed out to
                              me on IRC. Mentioning here was in the interest of passing out trials
                              and errors.

                              I do appreciate the pointer though. So much reading, so many demands.

                              Wietse: we must get you up to BSDCan again... I owe you more beer. :)

                              Thank you

                              --
                              Dan Langille
                              http://langille.org/
                            • Victor Duchovni
                              ... There is not much joy in catching you with your docs unread, but there is some hope that in the future you or others will know where to look. The point is
                              Message 14 of 21 , Dec 1, 2008
                              • 0 Attachment
                                On Mon, Dec 01, 2008 at 09:35:18PM -0500, Dan Langille wrote:

                                > >Did you see header_checks documented as a supported parameter in
                                > >http://www.postfix.org/smtpd.8.html (rhetorical question, the answer
                                > >is no). A closer look at the documentation shows this ia feature of
                                > >the cleanup service:
                                > >
                                > > <http://www.postfix.org/BUILTIN_FILTER_README.html#what>
                                >
                                >
                                > My ignorance is no secret, nor hidden. My error was pointed out to
                                > me on IRC. Mentioning here was in the interest of passing out trials
                                > and errors.
                                >
                                > I do appreciate the pointer though. So much reading, so many demands.

                                There is not much joy in catching you with your docs unread, but there
                                is some hope that in the future you or others will know where to look.

                                The point is that "-o parameter=value" will only work for services that
                                are documented to implement that parameter, and for that you need to
                                check the documentation of the service in question, and also understand
                                (see OVERVIEW.html, for example) which services are responsible for
                                which parts of work done by Postfix.

                                When you step out of main.cf and into the world of master.cf tweaks,
                                you need much more detailed knowledge/research of Postfix internals...

                                --
                                Viktor.

                                Disclaimer: off-list followups get on-list replies or get ignored.
                                Please do not ignore the "Reply-To" header.

                                To unsubscribe from the postfix-users list, visit
                                http://www.postfix.org/lists.html or click the link below:
                                <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                                If my response solves your problem, the best way to thank me is to not
                                send an "it worked, thanks" follow-up. If you must respond, please put
                                "It worked, thanks" in the "Subject" so I can delete these quickly.
                              • Dan Langille
                                ... That is much appreciated. -- Dan Langille http://langille.org/
                                Message 15 of 21 , Dec 2, 2008
                                • 0 Attachment
                                  On Dec 1, 2008, at 11:11 PM, Victor Duchovni wrote:

                                  > On Mon, Dec 01, 2008 at 09:35:18PM -0500, Dan Langille wrote:
                                  >
                                  >>> Did you see header_checks documented as a supported parameter in
                                  >>> http://www.postfix.org/smtpd.8.html (rhetorical question, the answer
                                  >>> is no). A closer look at the documentation shows this ia feature of
                                  >>> the cleanup service:
                                  >>>
                                  >>> <http://www.postfix.org/BUILTIN_FILTER_README.html#what>
                                  >>
                                  >>
                                  >> My ignorance is no secret, nor hidden. My error was pointed out to
                                  >> me on IRC. Mentioning here was in the interest of passing out trials
                                  >> and errors.
                                  >>
                                  >> I do appreciate the pointer though. So much reading, so many
                                  >> demands.
                                  >
                                  > There is not much joy in catching you with your docs unread, but there
                                  > is some hope that in the future you or others will know where to look.

                                  That is much appreciated.

                                  --
                                  Dan Langille
                                  http://langille.org/
                                Your message has been successfully submitted and would be delivered to recipients shortly.