Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > On 15/01/2020 13:32, Wietse Venema wrote:> Please try any OTHER stage than > connect. It might be a bug > > that exists only in the connect handler. You would help > > narrow down the search for me. > > You?re right, I just tried requesting _ for the data stage and that does > work! Thanks for checking that. I noticed that the Postfix implementation does the postfix<->milter setup while reporting the SMTP connect event. This evaluates the connect macros before the postfix<->milter setup has a chance to override them. Fix would be a some swap of some code. Wietse
Re: Is the milter API function smfi_setsymlist supported?
On 15/01/2020 13:32, Wietse Venema wrote:> Please try any OTHER stage than connect. It might be a bug > that exists only in the connect handler. You would help > narrow down the search for me. You’re right, I just tried requesting _ for the data stage and that does work! I have to take a break from this, sorry. And thanks for looking.
Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > If someone wants to try ? Make sure you have libmilter installed. > Compile and run: > > c99 -Wall nosetsymlist.c -lmilter -o nosetsymlist > ./nosetsymlist > > Enable in /etc/postfix/main.cf with: > > smtpd_milters = inet:localhost:3000 > > Then both requested macros, _ and {client_port}, are *not* available > during connect. If I request these macros in /etc/postfix/main.cf with > > milter_connect_macros = _ {client_port} > > then they *are* available and do get printed. Either smfi_setsymlist > doesn?t do anything, or ? perhaps more likely ? I?m making a mistake! > Very grateful for any hints. Please try any OTHER stage than connect. It might be a bug that exists only in the connect handler. You would help narrow down the search for me. Wietse
Re: Is the milter API function smfi_setsymlist supported?
If someone wants to try … Make sure you have libmilter installed. Compile and run: c99 -Wall nosetsymlist.c -lmilter -o nosetsymlist ./nosetsymlist Enable in /etc/postfix/main.cf with: smtpd_milters = inet:localhost:3000 Then both requested macros, _ and {client_port}, are *not* available during connect. If I request these macros in /etc/postfix/main.cf with milter_connect_macros = _ {client_port} then they *are* available and do get printed. Either smfi_setsymlist doesn’t do anything, or – perhaps more likely – I’m making a mistake! Very grateful for any hints. #include #include #include "libmilter/mfapi.h" sfsistat test_negotiate( SMFICTX *ctx, unsigned long f0, unsigned long f1, unsigned long f2, unsigned long f3, unsigned long *pf0, unsigned long *pf1, unsigned long *pf2, unsigned long *pf3 ) { *pf0 = *pf1 = *pf2 = *pf3 = 0; int status = smfi_setsymlist(ctx, SMFIM_CONNECT, "_ {client_port}"); assert(status == MI_SUCCESS); return SMFIS_CONTINUE; } sfsistat test_connect(SMFICTX *ctx, char *hostname, struct sockaddr *hostaddr) { char *_macro = smfi_getsymval(ctx, "_"); printf("_: %s\n", _macro == NULL ? "NULL" : _macro); char *cpmacro = smfi_getsymval(ctx, "{client_port}"); printf("{client_port}: %s\n", cpmacro == NULL ? "NULL" : cpmacro); return SMFIS_CONTINUE; } int main() { int connstatus = smfi_setconn("inet:3000@localhost"); assert(connstatus == MI_SUCCESS); int regstatus = smfi_register((struct smfiDesc) { .xxfi_name = "nosetsymlist", .xxfi_version = SMFI_VERSION, .xxfi_connect = test_connect, .xxfi_negotiate = test_negotiate, }); assert(regstatus == MI_SUCCESS); return smfi_main(); }
Re: Is the milter API function smfi_setsymlist supported?
On 14/01/2020 21:59, Bill Cole wrote: >> Beginning to get a little confused ... > > I can understand why. > > Is it certain that the macro you want is non-null when you're asking for it? I will post a minimal C reproducer some time later hopefully. As a summary, another quick illustration of the problem I’m seeing: • I can request macros for the connect stage in /etc/postfix/main.cf: milter_connect_macros = j _ {client_addr} {client_connections} {client_name} {client_port} {client_ptr} {daemon_addr} {daemon_name} {daemon_port} v • These macros are then all available in the connect callback of a test milter, I can print out the value of each macro. • If instead of the setting in /etc/postfix/main.cf, I request exactly the same macros in the negotiate callback of my milter with smfi_setsymlist(ctx, SMFIM_CONNECT, "j _ {client_addr} {client_connections} {client_name} {client_port} {client_ptr} {daemon_addr} {daemon_name} {daemon_port} v"); this does not have the same effect as in item 1. Only the default connect macros are available. I think anyone should be able to reproduce this easily. (Or even better: point out the basic mistake I’m making, silly me!) Cheers,
Re: Is the milter API function smfi_setsymlist supported?
On 14 Jan 2020, at 15:16, David Bürgin wrote: I have reproduced this both with an independent milter application and with the Postfix test-milter program. Are you sure MIMEDefang uses the libmilter API? Absolutely certain. It isn’t a pure Perl milter implementation? No. The core mimedefang daemon is compiled C, linked with libmilter. In this case, v8.15.2. Beginning to get a little confused ... I can understand why. Is it certain that the macro you want is non-null when you're asking for it? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > On 14/01/2020 20:48, Wietse Venema wrote: > >> test-milter confirms that smfi_setsymlist does not work: > >> > >> $ test-milter -v -p inet:3000@localhost -m connect -M > >> '{client_connections}' > >> set symbol list connect to "{client_connections}" > >> negotiate f0=1ff *pf0 = 1ff f1=1f *pf1=400 nosend=0 noreply=0 > >> misc=0 > >> test_connect localhost AF_INET (127.0.0.1:0) > >> macro: j="mail.my.org" > >> macro: v="Postfix 3.3.0" > >> macro: {daemon_addr}="127.0.0.1" > >> macro: {daemon_name}="mail.my.org" > >> test_reply 0 > > > > Couple observations. > > > > 1) Note that all this requires SMFI_VERSION > 5. Did you verify that? > > > > 2) Note that it is up to libmilter to send that macro list to > > Postfix. Did you verify that? This requires a single -v option to > > the smtpd configuration in master.cf and doing "postfix reload". > > Yes, I have an up-to-date Postfix and SMFI_VERSION > 5. > > The message > > postfix/smtpd[17351]: override SMFIM_CONNECT macro list with > "{client_connections} j _" > > does get logged, but right after that there is a line > > postfix/smtpd[17351]: event: SMFIC_CONNECT; macros: j=mail.gluet.ch > {daemon_name}=mail.gluet.ch {daemon_addr}=10.52.16.62 v=Postfix 3.3.0 > > Those are the default macros, not the ones requested. This is taking to much time. I will look into this later, maybe the wekeend. Wietse
Re: Is the milter API function smfi_setsymlist supported?
On 14/01/2020 20:31, Bill Cole wrote: > I can confirm that a milter absolutely can request and receive macros from > postfix, PROVIDED those macros are available. I use the MIMEDefang milter, > which optionally uses smfi_setsymlist() to request macros and includes > options to ask for specific arbitrary macros. On one testbed I happen to have > this set up in a debug mode which logs which macros are available to MD at > RCPT time, showing me these recently: > > Jan 14 14:01:35 bigsky mimedefang.pl[79121]: 47y0Db2FRdz3SRhl: Macros are _ > daemon_name mail_host mail_mailer j daemon_port client_port mail_addr > Jan 14 14:01:52 bigsky mimedefang.pl[79121]: 47y0Dw15yXz3SRjV: Macros are > tls_version cipher daemon_name _ j mail_mailer mail_host client_port > daemon_port cipher_bits mail_addr > Jan 14 14:02:50 bigsky mimedefang.pl[79121]: 47y0G25N4wz3SRjt: Macros are > daemon_port client_port auth_authen cipher_bits mail_addr auth_type > tls_version cipher j mail_host mail_mailer daemon_name _ > Jan 14 14:06:03 bigsky mimedefang.pl[79121]: 47y0Kl45zxz3SRsL: Macros are > tls_version cipher mail_mailer mail_host j daemon_name _ daemon_port > client_port mail_addr cipher_bits > Jan 14 14:06:36 bigsky mimedefang.pl[79121]: 47y0LN3dBLz3SRsx: Macros are > tls_version cipher _ daemon_name j mail_mailer mail_host client_port > daemon_port cipher_bits mail_addr > Jan 14 14:07:34 bigsky mimedefang.pl[79121]: 47y0MV0CwGz3SRtj: Macros are > tls_version cipher mail_mailer mail_host j _ daemon_name daemon_port > client_port mail_addr cipher_bits > Jan 14 14:13:38 bigsky mimedefang.pl[79121]: 47y0VT6hNPz3SRvm: Macros are > daemon_port client_port mail_addr mail_host mail_mailer j _ daemon_name > Jan 14 14:23:05 bigsky mimedefang.pl[79121]: 47y0jP4hxNz3SRwW: Macros are _ > daemon_name mail_mailer mail_host j client_port daemon_port mail_addr > > This is quite different from the Postfix config, which has the default value: > > bigsky:~ bill$ postconf milter_rcpt_macros > milter_rcpt_macros = i {rcpt_addr} {rcpt_host} {rcpt_mailer} > > So, whatever problem you are having with getting the macros you want is NOT > intrinsic to Postfix. Thanks Bill, I have reproduced this both with an independent milter application and with the Postfix test-milter program. Are you sure MIMEDefang uses the libmilter API? It isn’t a pure Perl milter implementation? Beginning to get a little confused ...
Re: Is the milter API function smfi_setsymlist supported?
On 14/01/2020 20:48, Wietse Venema wrote: >> test-milter confirms that smfi_setsymlist does not work: >> >> $ test-milter -v -p inet:3000@localhost -m connect -M >> '{client_connections}' >> set symbol list connect to "{client_connections}" >> negotiate f0=1ff *pf0 = 1ff f1=1f *pf1=400 nosend=0 noreply=0 misc=0 >> test_connect localhost AF_INET (127.0.0.1:0) >> macro: j="mail.my.org" >> macro: v="Postfix 3.3.0" >> macro: {daemon_addr}="127.0.0.1" >> macro: {daemon_name}="mail.my.org" >> test_reply 0 > > Couple observations. > > 1) Note that all this requires SMFI_VERSION > 5. Did you verify that? > > 2) Note that it is up to libmilter to send that macro list to > Postfix. Did you verify that? This requires a single -v option to > the smtpd configuration in master.cf and doing "postfix reload". Yes, I have an up-to-date Postfix and SMFI_VERSION > 5. The message postfix/smtpd[17351]: override SMFIM_CONNECT macro list with "{client_connections} j _" does get logged, but right after that there is a line postfix/smtpd[17351]: event: SMFIC_CONNECT; macros: j=mail.gluet.ch {daemon_name}=mail.gluet.ch {daemon_addr}=10.52.16.62 v=Postfix 3.3.0 Those are the default macros, not the ones requested.
Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > On 14/01/2020 19:39, Wietse Venema wrote: > >>>unsigned long *pf3) > >>> { > >>> if (set_macro_list) { > >>> if (verbose) > >>> printf("set symbol list %s to \"%s\"\n", > >>>macro_states[set_macro_state], set_macro_list); > >>> smfi_setsymlist(ctx, set_macro_state, set_macro_list); > >>> ... > >>> } > >> > >> the call to smfi_setsymlist is guarded by the flag set_macro_list. This > >> flag is enabled with the -M command-line option. However, that option is > >> never used, as far as I can see. Therefore, the code path is not taken. > > > > To 'use' the -M command-line option: > > > > $ make test-milter > > $ ./test-milter -m state -M macros ... > > > > Where state is one of connect, helo, mail. etc. > > Where macros is a list of macros. Example: "{rcpt_mailer} {rcpt_host}". > > Thank you, Wietse. > > test-milter confirms that smfi_setsymlist does not work: > > $ test-milter -v -p inet:3000@localhost -m connect -M > '{client_connections}' > set symbol list connect to "{client_connections}" > negotiate f0=1ff *pf0 = 1ff f1=1f *pf1=400 nosend=0 noreply=0 misc=0 > test_connect localhost AF_INET (127.0.0.1:0) > macro: j="mail.my.org" > macro: v="Postfix 3.3.0" > macro: {daemon_addr}="127.0.0.1" > macro: {daemon_name}="mail.my.org" > test_reply 0 Couple observations. 1) Note that all this requires SMFI_VERSION > 5. Did you verify that? 2) Note that it is up to libmilter to send that macro list to Postfix. Did you verify that? This requires a single -v option to the smtpd configuration in master.cf and doing "postfix reload". If libmilter sends macros, they are logged like this: while (data_len > 0 && milter8_read_data(milter, _len, MILTER8_DATA_HLONG, _type, MILTER8_DATA_STRING, buf, MILTER8_DATA_MORE) == 0) { smfim_name = str_name_code(smfim_table, mac_type); if (smfim_name == 0) { msg_warn("milter %s: ignoring unknown macro type %u", milter->m.name, (unsigned) mac_type); } else { if (msg_verbose) msg_info("override %s macro list with \"%s\"", smfim_name, STR(buf)); mac_value_ptr = MILTER8_MACRO_PTR(milter->m.macros, mac_type); myfree(*mac_value_ptr); *mac_value_ptr = mystrdup(STR(buf)); } } If libmilter does not send them, then that is the problem. Wietse
Re: Is the milter API function smfi_setsymlist supported?
On 14 Jan 2020, at 12:40, David Bürgin wrote: smfi_setsymlist would be a useful function to have, because it lets milter applications request the macros they need for operation themselves. Just recently there was a thread on this list where someone struggled to set up the required macros for a milter application. I can confirm that a milter absolutely can request and receive macros from postfix, PROVIDED those macros are available. I use the MIMEDefang milter, which optionally uses smfi_setsymlist() to request macros and includes options to ask for specific arbitrary macros. On one testbed I happen to have this set up in a debug mode which logs which macros are available to MD at RCPT time, showing me these recently: Jan 14 14:01:35 bigsky mimedefang.pl[79121]: 47y0Db2FRdz3SRhl: Macros are _ daemon_name mail_host mail_mailer j daemon_port client_port mail_addr Jan 14 14:01:52 bigsky mimedefang.pl[79121]: 47y0Dw15yXz3SRjV: Macros are tls_version cipher daemon_name _ j mail_mailer mail_host client_port daemon_port cipher_bits mail_addr Jan 14 14:02:50 bigsky mimedefang.pl[79121]: 47y0G25N4wz3SRjt: Macros are daemon_port client_port auth_authen cipher_bits mail_addr auth_type tls_version cipher j mail_host mail_mailer daemon_name _ Jan 14 14:06:03 bigsky mimedefang.pl[79121]: 47y0Kl45zxz3SRsL: Macros are tls_version cipher mail_mailer mail_host j daemon_name _ daemon_port client_port mail_addr cipher_bits Jan 14 14:06:36 bigsky mimedefang.pl[79121]: 47y0LN3dBLz3SRsx: Macros are tls_version cipher _ daemon_name j mail_mailer mail_host client_port daemon_port cipher_bits mail_addr Jan 14 14:07:34 bigsky mimedefang.pl[79121]: 47y0MV0CwGz3SRtj: Macros are tls_version cipher mail_mailer mail_host j _ daemon_name daemon_port client_port mail_addr cipher_bits Jan 14 14:13:38 bigsky mimedefang.pl[79121]: 47y0VT6hNPz3SRvm: Macros are daemon_port client_port mail_addr mail_host mail_mailer j _ daemon_name Jan 14 14:23:05 bigsky mimedefang.pl[79121]: 47y0jP4hxNz3SRwW: Macros are _ daemon_name mail_mailer mail_host j client_port daemon_port mail_addr This is quite different from the Postfix config, which has the default value: bigsky:~ bill$ postconf milter_rcpt_macros milter_rcpt_macros = i {rcpt_addr} {rcpt_host} {rcpt_mailer} So, whatever problem you are having with getting the macros you want is NOT intrinsic to Postfix. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Is the milter API function smfi_setsymlist supported?
On 14/01/2020 19:39, Wietse Venema wrote: >>>unsigned long *pf3) >>> { >>> if (set_macro_list) { >>> if (verbose) >>> printf("set symbol list %s to \"%s\"\n", >>>macro_states[set_macro_state], set_macro_list); >>> smfi_setsymlist(ctx, set_macro_state, set_macro_list); >>> ... >>> } >> >> the call to smfi_setsymlist is guarded by the flag set_macro_list. This >> flag is enabled with the -M command-line option. However, that option is >> never used, as far as I can see. Therefore, the code path is not taken. > > To 'use' the -M command-line option: > > $ make test-milter > $ ./test-milter -m state -M macros ... > > Where state is one of connect, helo, mail. etc. > Where macros is a list of macros. Example: "{rcpt_mailer} {rcpt_host}". Thank you, Wietse. test-milter confirms that smfi_setsymlist does not work: $ test-milter -v -p inet:3000@localhost -m connect -M '{client_connections}' set symbol list connect to "{client_connections}" negotiate f0=1ff *pf0 = 1ff f1=1f *pf1=400 nosend=0 noreply=0 misc=0 test_connect localhost AF_INET (127.0.0.1:0) macro: j="mail.my.org" macro: v="Postfix 3.3.0" macro: {daemon_addr}="127.0.0.1" macro: {daemon_name}="mail.my.org" test_reply 0 The {client_connections} macro is not available in connect, even though it was requested. It is a great pity if we cannot use smfi_setsymlist with Postfix, it is such a useful (and obviously underappreciated) little API.
Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > Wietse, > > On 14/01/2020 18:58, Wietse Venema wrote: > > smfi_setsymlist() is called by test_negotiate(): > > > > static sfsistat test_negotiate(SMFICTX *ctx, > >unsigned long f0, .. > >unsigned long *pf3) > > { > > if (set_macro_list) { > > if (verbose) > > printf("set symbol list %s to \"%s\"\n", > >macro_states[set_macro_state], set_macro_list); > > smfi_setsymlist(ctx, set_macro_state, set_macro_list); > > ... > > } > > the call to smfi_setsymlist is guarded by the flag set_macro_list. This > flag is enabled with the -M command-line option. However, that option is > never used, as far as I can see. Therefore, the code path is not taken. To 'use' the -M command-line option: $ make test-milter $ ./test-milter -m state -M macros ... Where state is one of connect, helo, mail. etc. Where macros is a list of macros. Example: "{rcpt_mailer} {rcpt_host}". Here is the code that sets set_macro_list: case 'm': #if SMFI_VERSION > 5 if (set_macro_state_arg) { fprintf(stderr, "too many -m options\n"); exit(1); } set_macro_state_arg = optarg; #else fprintf(stderr, "no libmilter support to specify macro list\n"); exit(1); #endif break; case 'M': #if SMFI_VERSION > 5 if (set_macro_list) { fprintf(stderr, "too many -M options\n"); exit(1); } set_macro_list = optarg; #else fprintf(stderr, "no libmilter support to specify macro list\n"); #endif break; Wietse
Re: Is the milter API function smfi_setsymlist supported?
Wietse, On 14/01/2020 18:58, Wietse Venema wrote: > smfi_setsymlist() is called by test_negotiate(): > > static sfsistat test_negotiate(SMFICTX *ctx, >unsigned long f0, >unsigned long f1, >unsigned long f2, >unsigned long f3, >unsigned long *pf0, >unsigned long *pf1, >unsigned long *pf2, >unsigned long *pf3) > { > if (set_macro_list) { > if (verbose) > printf("set symbol list %s to \"%s\"\n", >macro_states[set_macro_state], set_macro_list); > smfi_setsymlist(ctx, set_macro_state, set_macro_list); > ... > } the call to smfi_setsymlist is guarded by the flag set_macro_list. This flag is enabled with the -M command-line option. However, that option is never used, as far as I can see. Therefore, the code path is not taken.
Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > On 14/01/2020 18:22, Wietse Venema wrote: > >> In section ?What macros will Postfix send to Milters??, MILTER_README > >> says: > >> > >>> As of Sendmail 8.14.0, Milter applications can specify what macros > >>> they want to receive at different Milter protocol stages. An > >>> application-specified list takes precedence over a Postfix-specified > >>> list. > >> > >> This refers to the API function smfi_setsymlist, right? When I hook a > > > > The Milter docs say: "This function must only be called during > > xxfi_negotiate()". Thus, you cannot call it at any other time. > > (found with a Google query, because milter.org is gone). > > Yes, I?m using the API correctly, and get the MI_SUCCESS return code. > > > Postfix test code calls smfi_setsymlist during initial Milter > > connection negotiation, through the xxfi_negotiate callback in the > > smfiDesc structure. It's been ~10 years, but that code presumably > > worked. The program is included with Postfix source as > > src/milter/test_milter.c. Maybe you can play with that. > > I suspect this code doesn?t work and perhaps never did work ? in Postfix > source there is only one occurrence of smfi_setsymlist, in a code path > that is never executed. smfi_setsymlist() is called by test_negotiate(): static sfsistat test_negotiate(SMFICTX *ctx, unsigned long f0, unsigned long f1, unsigned long f2, unsigned long f3, unsigned long *pf0, unsigned long *pf1, unsigned long *pf2, unsigned long *pf3) { if (set_macro_list) { if (verbose) printf("set symbol list %s to \"%s\"\n", macro_states[set_macro_state], set_macro_list); smfi_setsymlist(ctx, set_macro_state, set_macro_list); ... } test_negotiate() is referenced in: static struct smfiDesc smfilter = { "test-milter", SMFI_VERSION, SMFIF_ADDRCPT | SMFIF_DELRCPT | SMFIF_ADDHDRS | SMFIF_CHGHDRS | SMFIF_CHGBOD Y | SMFIF_CHGFROM, test_connect, ... #if SMFI_VERSION > 5 test_negotiate, #endif }; Which is in turn referenced at the end of the test-milter main program. if (smfi_register(smfilter) == MI_FAILURE) { fprintf(stderr, "smfi_register failed\n"); exit(1); } return (smfi_main()); } I can lead the horse to the water,. but I cannot force it to drink. Wietse
Re: Is the milter API function smfi_setsymlist supported?
On 14/01/2020 18:22, Wietse Venema wrote: >> In section ?What macros will Postfix send to Milters??, MILTER_README >> says: >> >>> As of Sendmail 8.14.0, Milter applications can specify what macros >>> they want to receive at different Milter protocol stages. An >>> application-specified list takes precedence over a Postfix-specified >>> list. >> >> This refers to the API function smfi_setsymlist, right? When I hook a > > The Milter docs say: "This function must only be called during > xxfi_negotiate()". Thus, you cannot call it at any other time. > (found with a Google query, because milter.org is gone). Yes, I’m using the API correctly, and get the MI_SUCCESS return code. > Postfix test code calls smfi_setsymlist during initial Milter > connection negotiation, through the xxfi_negotiate callback in the > smfiDesc structure. It's been ~10 years, but that code presumably > worked. The program is included with Postfix source as > src/milter/test_milter.c. Maybe you can play with that. I suspect this code doesn’t work and perhaps never did work – in Postfix source there is only one occurrence of smfi_setsymlist, in a code path that is never executed. smfi_setsymlist would be a useful function to have, because it lets milter applications request the macros they need for operation themselves. Just recently there was a thread on this list where someone struggled to set up the required macros for a milter application.
Re: Is the milter API function smfi_setsymlist supported?
David B?rgin: > In section ?What macros will Postfix send to Milters??, MILTER_README > says: > > > As of Sendmail 8.14.0, Milter applications can specify what macros > > they want to receive at different Milter protocol stages. An > > application-specified list takes precedence over a Postfix-specified > > list. > > This refers to the API function smfi_setsymlist, right? When I hook a The Milter docs say: "This function must only be called during xxfi_negotiate()". Thus, you cannot call it at any other time. (found with a Google query, because milter.org is gone). Postfix test code calls smfi_setsymlist during initial Milter connection negotiation, through the xxfi_negotiate callback in the smfiDesc structure. It's been ~10 years, but that code presumably worked. The program is included with Postfix source as src/milter/test_milter.c. Maybe you can play with that. Wietse > little test milter into Postfix, requesting a few non-default macros (eg > ?{client_connections}?) with this function during negotiation, it > doesn?t have any effect. Postfix doesn?t send the macros. > > Is smfi_setsymlist supported? Did I misunderstand something? > > Thank you. >
Is the milter API function smfi_setsymlist supported?
In section ‘What macros will Postfix send to Milters?’, MILTER_README says: > As of Sendmail 8.14.0, Milter applications can specify what macros > they want to receive at different Milter protocol stages. An > application-specified list takes precedence over a Postfix-specified > list. This refers to the API function smfi_setsymlist, right? When I hook a little test milter into Postfix, requesting a few non-default macros (eg ‘{client_connections}’) with this function during negotiation, it doesn’t have any effect. Postfix doesn’t send the macros. Is smfi_setsymlist supported? Did I misunderstand something? Thank you.