I ran a test similar to the one in original report with spfmilter running under gdb. I set a breakpoint and investigated the ld->peer_info structure contents at the moment when SPF_policy_main() is about to get called from lib_do_check (spfmilter.c:1776).
Comparison of the structure contents between the call on first MAIL FROM (which will get rejected) and the last MAIL FROM (i.e. the incorrectly accepted one), reveals that there is a difference in the value of the structure's "spf_rlevel" member. Namely, "spf_rlevel == 1" on the first MAIL FROM, and "spf_rlevel == 9" just before the last one. My strong suspicion is that libspf treats it as reaching some maximum (=10?) recursion level and fails back to accepting the sender. I don't yet know whether not resetting the structure correctly is libspf's fault, or spfmilter's fault. I may have a closer look today or during the weekend, but it may make more sense for someone who knows the API better to jump in at this point. -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]