smtpd_reject_footer and smtps

[Micah Anderson-2]

Hello,

I tried to add a smtpd_reject_footer to submission and smtps as an
option in my master.cf:

submission inet n       -       n       -       -       smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c For further help, contact the support desk
smtps     inet  n       -       n       -       -       smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c For further help, contact the support desk

the submission one took, but with smtps, I got an error:

"fatal: unexpected command-line argument: For"

why is it that this does not work for smtps?

thanks,
micah

[Noel Jones-2]

On 4/26/2018 7:14 AM, micah anderson wrote:

>
> Hello,
>
> I tried to add a smtpd_reject_footer to submission and smtps as an
> option in my master.cf:
>
> submission inet n       -       n       -       -       smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c For further help, contact the support desk
> smtps     inet  n       -       n       -       -       smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=\c For further help, contact the support desk
>
> the submission one took, but with smtps, I got an error:
>
> "fatal: unexpected command-line argument: For"
>
> why is it that this does not work for smtps?
>

Spaces are not directly supported in master.cf arguments.

If you have postfix 3.0 or newer, you can enclose the option in braces.
  -o { smtpd_reject_footer = ... }


or for any postfix version, you can reference a macro in main.cf

# main.cf
submit_reject_footer = ...

# master.cf
  -o smtpd_reject_footer=$submit_reject_footer


http://www.postfix.org/master.5.html
http://www.postfix.org/postconf.5.html



  -- Noel Jones

[Micah Anderson-2]

Noel Jones <[hidden email]> writes:

> Spaces are not directly supported in master.cf arguments.

Yes, of course... I should have realized that.

> If you have postfix 3.0 or newer, you can enclose the option in braces.
>   -o { smtpd_reject_footer = ... }

I don't have 3.0 (yet!)

> or for any postfix version, you can reference a macro in main.cf
>
> # main.cf
> submit_reject_footer = ...
>
> # master.cf
>   -o smtpd_reject_footer=$submit_reject_footer

I tried this and was told

postfix[20227]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: submit_reject_footer=\c For further help, contact support
postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in expansion request

(this is postfix 2.11)

micah

[Viktor Dukhovni]

> On Apr 26, 2018, at 2:40 PM, micah <[hidden email]> wrote:
>
> I tried this and was told
>
> postfix[20227]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: submit_reject_footer=\c For further help, contact support
> postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in expansion request
>
> (this is postfix 2.11)

Ignore the warning. So long as the parameter *is* used in master.cf, you're fine.
I don't recall when the warning code started to look for use in master.cf, so
do check that your master.cf use is syntactically correct, ...

--
        Viktor.

[Wietse Venema]

micah:

> Noel Jones <[hidden email]> writes:
>
> > Spaces are not directly supported in master.cf arguments.
>
> Yes, of course... I should have realized that.
>
> > If you have postfix 3.0 or newer, you can enclose the option in braces.
> >   -o { smtpd_reject_footer = ... }
>
> I don't have 3.0 (yet!)
>
> > or for any postfix version, you can reference a macro in main.cf
> >
> > # main.cf
> > submit_reject_footer = ...
> >
> > # master.cf
> >   -o smtpd_reject_footer=$submit_reject_footer
>
> I tried this and was told
>
> postfix[20227]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: submit_reject_footer=\c For further help, contact support

The postconf command still needs special code to look inside
submit_reject_footer, because that setting may contain things like
$localtime and $client_address that aren't main.cf parameters.

(it needs custom code for each 'type RAW' parameter).

I have added a TODO, and may fix this in the near future.

> postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in expansion request

That may be because there was no main.cf setting at the time.

        Wietse

[Micah Anderson-2]

Wietse Venema <[hidden email]> writes:

>> postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in expansion request
>
> That may be because there was no main.cf setting at the time.

I definitely have it set in main.cf:

submit_reject_footer=\c For further help, contact support.

and it is configured in master.cf:

smtps     inet  n       -       n       -       -       smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=$submit_reject_footer

and I've restarted postfix. Now every smtps transaction results in this
log entry:

postfix/smtpd[15949]: warning: unknown macro name "submit_reject_footer" in expansion request

could it be because I put the submit_reject_footer= at the end of
main.cf? Does that matter?

micah

[Wietse Venema]

micah:

> Wietse Venema <[hidden email]> writes:
>
> >> postfix/smtpd[21083]: warning: unknown macro name "submit_reject_footer" in expansion request
> >
> > That may be because there was no main.cf setting at the time.
>
> I definitely have it set in main.cf:
>
> submit_reject_footer=\c For further help, contact support.
>
> and it is configured in master.cf:
>
> smtps     inet  n       -       n       -       -       smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=$submit_reject_footer
>
> and I've restarted postfix. Now every smtps transaction results in this
> log entry:
>
> postfix/smtpd[15949]: warning: unknown macro name "submit_reject_footer" in expansion request
>
> could it be because I put the submit_reject_footer= at the end of
> main.cf? Does that matter?

The location in main.cf makes a difference if you set the same name
more than once. That is, with:

    ...stuff...
    foo = xx
    ...stuff...
    foo = yy

The last setting wins.

Meanwhile, you can set "-o {smtpd_reject_footer = text... }" in master.cf,

        Wietse

[Viktor Dukhovni]

> On Apr 27, 2018, at 6:53 AM, Wietse Venema <[hidden email]> wrote:
>
> Meanwhile, you can set "-o {smtpd_reject_footer = text... }" in master.cf,

I seem to recall that the OP is using Postfix 2.11 which does not
have that feature. :-(

As for smtpd_reject_footer it is expanded via smtpd_expand_lookup()
which contains the comment:

    /*
     * Don't query main.cf parameters, as the result of expansion could
     * reveal system-internal information in server replies.
     *
     * XXX: This said, multiple servers may be behind a single client-visible
     * name or IP address, and each may generate its own logs. Therefore, it
     * may be useful to expose the replying MTA id (myhostname) in the
     * contact footer, to identify the right logs. So while we don't expose
     * the raw configuration dictionary, we do expose "$myhostname" as
     * expanded in var_myhostname.
     *
     * Return NULL only for non-existent names.
     */

So it seems that using master.cf overrides of the generally recommended
form won't work here... :-(

--
        Viktor.

[Wietse Venema]

Viktor Dukhovni:

>
>
> > On Apr 27, 2018, at 6:53 AM, Wietse Venema <[hidden email]> wrote:
> >
> > Meanwhile, you can set "-o {smtpd_reject_footer = text... }" in master.cf,
>
> I seem to recall that the OP is using Postfix 2.11 which does not
> have that feature. :-(
>
> As for smtpd_reject_footer it is expanded via smtpd_expand_lookup()
> which contains the comment:
>
>     /*
>      * Don't query main.cf parameters, as the result of expansion could
>      * reveal system-internal information in server replies.
>      *
>      * XXX: This said, multiple servers may be behind a single client-visible
>      * name or IP address, and each may generate its own logs. Therefore, it
>      * may be useful to expose the replying MTA id (myhostname) in the
>      * contact footer, to identify the right logs. So while we don't expose
>      * the raw configuration dictionary, we do expose "$myhostname" as
>      * expanded in var_myhostname.
>      *
>      * Return NULL only for non-existent names.
>      */
>
> So it seems that using master.cf overrides of the generally recommended
> form won't work here... :-(

And it's even documented:

       Notes:

       o      NOT SUPPORTED are other attributes such as sender, recipient, or
              main.cf parameters.

This is working as intended, though perhaps not as expected.

With postscreen_reject_footer I had to make a special case when the
value contains exactly one $name and nothing else:

    if (*var_psc_rej_footer == '$'
        && mail_conf_lookup(var_psc_rej_footer + 1)) {
        tmp = mail_conf_eval_once(var_psc_rej_footer);
        myfree(var_psc_rej_footer);
        var_psc_rej_footer = mystrdup(tmp);
    }

Ditto for postscreen_expansion_filter.

Adding such cleverness to postconf could be challenging.

        Wietse

[Wietse Venema]

micah:
> smtps     inet  n       -       n       -       -       smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_footer=$submit_reject_footer

That is a documentation problem.

Specifically, the smtpd_reject_footer documentation fails to mention
that the smtpd_reject_footer value is not subject to Postfix
configuration parameter $name expansion.

- The smtpd_reject_footer parameter value contains $name instances
that need to be expanded while handling a client request, because
the value depends on the request context. Normally, Postfix
configuration parameter $name expansion happens before a program
handles a client request.

- The smtpd_reject_footer parameter value should not 'leak' main.cf
settings when Postfix responds to a client.

Other parameters with similar limitations are: forward_path,
command_execution_directory, luser_relay, smtpd_expansion_filter,
default_rbl_reply, and mailbox_command.

Some of these parameters do not expand Postfix configuration parameter
$name because the parameter value contains shell commands, and the
feature would be too difficult to use.

Only some of these parameters documented this limitation. I have
updated the remaining ones.

        Wietse