From: Tony E. <to...@he...> - 2007-11-13 10:36:57
|
Hi list, Running dkim-filter 2.4.0.Beta4 on my test machine purely for verification. This is with Postfix 2.4.6, Postfix milter_protocol = 2, libmilter version 8.14.1 on Fedora FC6. Whilst 2.3.2 does an ok job, all (?) versions of 2.4.0 are giving "Nov 13 11:06:02 tru dkim-filter[12998]: Sendmail DKIM Filter: st_optionneg[-1240769648]: xxfi_negotiate returned 1 (protocol options=0x17f, actions=0x3f)" in the dkim-filter log. Googled, searched the docs, done strings on the binary. It would seem that libmilter is responsible, but I can't find out if this is a Postfix or a dkim-filter barf. Can someone please tell me? Preferably also what I can try to eliminate it ;) Best, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl |
From: Murray S. K. <ms...@se...> - 2007-11-13 17:18:03
|
On Tue, 13 Nov 2007, Tony Earnshaw wrote: > Whilst 2.3.2 does an ok job, all (?) versions of 2.4.0 are giving "Nov > 13 11:06:02 tru dkim-filter[12998]: Sendmail DKIM Filter: > st_optionneg[-1240769648]: xxfi_negotiate returned 1 (protocol > options=0x17f, actions=0x3f)" in the dkim-filter log. Someone expert at the Postfix milter implementation will have to help us out here. mlfi_negotiate() is the dkim-filter side of what libmilter is referring to as "xxfi_negotiate". I'll return 1 (SMFIS_REJECT) from that function if the MTA doesn't offer dkim-filter all of the actions it requires, namely SMFIF_ADDHDRS (the ability to add headers), SMFIF_CHGHDRS (the ability to change/remove headers) and SMFIF_SETSYMLIST (the ability to request specific macros/symbols from the MTA). Perhaps one of these is not being offered by Postfix. In that case, I might be able to make the latter two optional depending on configuration, but it really does need at least SMFIF_ADDHDRS (but I'm pretty sure Postfix has that already). The log entry you cited indicates "0x17f" for options. That's all of the following: SMFIF_SETSYMLIST 0x100 SMFIF_CHGFROM 0x040 SMFIF_QUARANTINE 0x020 SMFIF_CHGHDRS 0x010 SMFIF_DELRCPT 0x008 SMFIF_ADDRCPT 0x004 SMFIF_CHGBODY 0x002 SMFIF_ADDHDRS 0x001 ...which obviously contains the set mlfi_negotiate() wants, so I'm pretty sure we get past that step. The actions it offers, 0x3f, means: SMFIP_NOHDRS 0x20 SMFIP_NOBODY 0x10 SMFIP_NORCPT 0x08 SMFIP_NOMAIL 0x04 SMFIP_NOHELO 0x02 SMFIP_NOCONNECT 0x01 mlfi_negotiate() has a larger set of options that it wants, but it settles for the intersection of what it wants and what it's offered. There's no error in the fact that Postfix isn't giving it everything. I'll also return SMFIS_REJECT from there if in my attempt to build the macro list I want, the list of macros overflows available buffer space, or the request for the macro list from the MTA returns an error. Based on what you've pasted, this is more likely the cause (though the "why?" part isn't evident). If you want to take a crack at it yourself, load up dkim-filter inside gdb and set a breakpoint at mlfi_negotiate(). When a connection arrives and trips that breakpoint, print the value of f0. Then step forward until you see it "return SMFIS_REJECT;" from someplace and note which line number it was. Those two things together will give me some hints about what to do or suggest next. -MSK |
From: Tony E. <to...@he...> - 2007-11-13 17:32:53
|
Murray S. Kucherawy skrev, on 13-11-2007 18:17: > On Tue, 13 Nov 2007, Tony Earnshaw wrote: >> Whilst 2.3.2 does an ok job, all (?) versions of 2.4.0 are giving "Nov >> 13 11:06:02 tru dkim-filter[12998]: Sendmail DKIM Filter: >> st_optionneg[-1240769648]: xxfi_negotiate returned 1 (protocol >> options=0x17f, actions=0x3f)" in the dkim-filter log. > > Someone expert at the Postfix milter implementation will have to help us > out here. > > mlfi_negotiate() is the dkim-filter side of what libmilter is referring to > as "xxfi_negotiate". I'll return 1 (SMFIS_REJECT) from that function if > the MTA doesn't offer dkim-filter all of the actions it requires, namely > SMFIF_ADDHDRS (the ability to add headers), SMFIF_CHGHDRS (the ability to > change/remove headers) and SMFIF_SETSYMLIST (the ability to request > specific macros/symbols from the MTA). Perhaps one of these is not being > offered by Postfix. In that case, I might be able to make the latter two > optional depending on configuration, but it really does need at least > SMFIF_ADDHDRS (but I'm pretty sure Postfix has that already). > > The log entry you cited indicates "0x17f" for options. That's all of the > following: > > SMFIF_SETSYMLIST 0x100 > SMFIF_CHGFROM 0x040 > SMFIF_QUARANTINE 0x020 > SMFIF_CHGHDRS 0x010 > SMFIF_DELRCPT 0x008 > SMFIF_ADDRCPT 0x004 > SMFIF_CHGBODY 0x002 > SMFIF_ADDHDRS 0x001 > > ...which obviously contains the set mlfi_negotiate() wants, so I'm pretty > sure we get past that step. > > The actions it offers, 0x3f, means: > > SMFIP_NOHDRS 0x20 > SMFIP_NOBODY 0x10 > SMFIP_NORCPT 0x08 > SMFIP_NOMAIL 0x04 > SMFIP_NOHELO 0x02 > SMFIP_NOCONNECT 0x01 > > mlfi_negotiate() has a larger set of options that it wants, but it settles > for the intersection of what it wants and what it's offered. There's no > error in the fact that Postfix isn't giving it everything. > > I'll also return SMFIS_REJECT from there if in my attempt to build the > macro list I want, the list of macros overflows available buffer space, or > the request for the macro list from the MTA returns an error. Based on > what you've pasted, this is more likely the cause (though the "why?" part > isn't evident). > > If you want to take a crack at it yourself, load up dkim-filter inside gdb > and set a breakpoint at mlfi_negotiate(). When a connection arrives and > trips that breakpoint, print the value of f0. Then step forward until you > see it "return SMFIS_REJECT;" from someplace and note which line number it > was. Those two things together will give me some hints about what to do > or suggest next. Thanks Murray; before attacking this with gdb, I'll post this on the Postfix list, in the hope that WV or NJ can identify this. If not, I'm "from the ground off" with 2.4.0 again, as Dutch people write. Hope one of them can, I'll post back. Best, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl |