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

Re: remote smtp auth clients - header rewrite question

Expand Messages
  • john mickler
    ... Thanks for the pointer Sahil, that regex is almost perfect for what I was looking to do. As for the newline insertion mentioned on the website, I m
    Message 1 of 21 , Nov 29, 2008
    • 0 Attachment
      On Sat, Nov 29, 2008 at 6:37 PM, Sahil Tandon <sahil@...> wrote:
      >
      > 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.

      Thanks for the pointer Sahil, that regex is almost perfect for what I
      was looking to do.

      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.
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.