Bug#475130: Some more info..
On Mon, May 05, 2008 at 11:56:51AM -0700, Mike Markley wrote: If this header is actually being eaten by the smfi_chgheader() then it is a bug in the Postfix Milter implementation. Could be. I guess that one way to verify this theory is to write a very basic milter which would just try to reproduce this bug. If that one also causes such behavior, then it would be the ideal thing to submit to postfix maintainers as a bug report. Unfortunately I know very little about milter APIs. -- 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]
Bug#475130: Some more info..
On Sat, May 03, 2008 at 07:39:17PM -0700, Mike Markley wrote: It seems more likely to me that the Received header is somehow being suppressed (it should be inserted by the host that's running spfmilter, right?) No. It is removing the most recent Received header which is _already_ in the received message (i.e. the header added by the MTA which directly preceded the problematic one on the message's path). I still don't understand how spfmilter could be causing this, so I plan to take it to postfix-users or similar. Based on the spfmilter package version, I'm guessing you're running etch, and therefore Postfix 2.3.8; can you confirm that? My guess would be that the API does not work like spfmilter assumes it does. I don't know where the bug lies, though. Yes, I am using etch, postfix 2.3.8-2 -- 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]
Bug#475130: Some more info..
On Mon, May 05, 2008 at 03:21:50PM +0100, Marcin Owsiany [EMAIL PROTECTED] wrote: My guess would be that the API does not work like spfmilter assumes it does. I don't know where the bug lies, though. Yes, I am using etch, postfix 2.3.8-2 My understanding from talking to other Postfix folks is that the Milter API in Postfix 2.3.x is rather immature. The API documentation reflects exactly what spfmilter is attempting to do: https://www.milter.org/developers/api/smfi_chgheader There are only two lines of code making this call, the first used when there are more than 10 Received-SPF headers and the second when there are Received-SPF headers purporting to be from the local host: smfi_chgheader( ctx, HEADER_NAME, i, (char*) 0 ); and smfi_chgheader( ctx, HEADER_NAME, cd-del_header_list[i], (char*) 0 ); Which is why I mentioned HEADER_NAME: #define HEADER_NAME Received-SPF If this header is actually being eaten by the smfi_chgheader() then it is a bug in the Postfix Milter implementation. The code for deleting this header should only be triggered if there's an existing Received-SPF: header. You can check for yourself; smfi_chgheader() is called at no other times :). -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475130: Some more info..
It seems more likely to me that the Received header is somehow being suppressed (it should be inserted by the host that's running spfmilter, right?) I still don't understand how spfmilter could be causing this, so I plan to take it to postfix-users or similar. Based on the spfmilter package version, I'm guessing you're running etch, and therefore Postfix 2.3.8; can you confirm that? -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475130: Some more info..
Yes, I do get the spoofed header warnings with the problematic messages. And
no, I did not change the HEADER_NAME macro in source code :-)
Here are the config snippets:
main.cf:
---
smtpd_milters =
inet:127.0.0.1:12345,
# unix:/var/run/dkim-filter/dkim-filter.sock,
unix:/var/run/clamav/clamav-milter.ctl
milter_default_action = accept
---
/etc/default/spfmilter:
---
DAEMON_OPTS=-l a:master.debian.org
NO_MACROS_CHECK=1
SOCKET=inet:[EMAIL PROTECTED] # listen just on loopback on port 12345
---
If you'd like to see complete configs, I can send them to you privately.
The only other non-standard thing I can think of is libspf0, patched for
#392927 and #464029 (interdiff attached), but I don't think this matters.
--
Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
diff -u libspf-0.999-1.0.0-p3/debian/changelog libspf-0.999-1.0.0-p3/debian/changelog
--- libspf-0.999-1.0.0-p3/debian/changelog
+++ libspf-0.999-1.0.0-p3/debian/changelog
@@ -1,3 +1,10 @@
+libspf (0.999-1.0.0-p3-3.0.sl.1) unstable; urgency=low
+
+ * Patched to avoid #392927
+ * Patched to avoid #464029
+
+ -- Marcin Owsiany [EMAIL PROTECTED] Thu, 13 Mar 2008 13:41:00 +
+
libspf (0.999-1.0.0-p3-3) unstable; urgency=low
* Fixed debian/rules file syntax (closes: #353857)
only in patch2:
unchanged:
--- libspf-0.999-1.0.0-p3.orig/src/libspf/main.c
+++ libspf-0.999-1.0.0-p3/src/libspf/main.c
@@ -1683,7 +1683,8 @@
xfree(p-from);
}
- if (p-spf_rlevel 0)
+ if ((p-spf_rlevel 0)
+ (p-current_domain != p-original_domain))
{
xfree(p-current_domain);
}
@@ -1830,6 +1831,11 @@
xvprintf(local-part: [%s]; domain: [%s]; sender: [%s]\n,
p-local_part, p-current_domain, p-from);
+ /*
+ * We need to reset this, otherwise we'll hit the recursion limit after N rejected MAIL FROMs.
+ */
+ p-spf_rlevel = 0;
+
return(SPF_TRUE);
}
only in patch2:
unchanged:
