https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #19 from Giovanni Bajo <[email protected]> 2010-05-27 06:37:26 EDT --- (In reply to comment #18) > It appears the headers of the message checked at SMTP time are not identical > to the sample. Something breaking headers there? I think I found what it is going on. As specified in the bug description, we are running SpamAssassin through Postfix + spamass-milter. Spamass-milter adds a custom Received header to the message: http://cvs.savannah.gnu.org/viewvc/spamass-milt/spamass-milter.cpp?revision=1.91&root=spamass-milt&view=markup line 1003: assassin->output((string) "Received: from "+macro_s+" ("+macro__+")\r\n\t"+ by "+macro_j+"("+macro_v+"/"+macro_Z+") with "+macro_r+" id "+macro_i+";\r\n\t"+ macro_b+"\r\n\t"+ "(envelope-from "+assassin->from()+")\r\n"); This is done because when the milter is invoked, Postfix has not yet added its last Received header (to be fully compatible with sendmail milter protocol). But: the standard configuration of Postfix does NOT propagate some of the above macros (substitution strings) needed by the milter to correctly generate the header. Specifically, the "_" (underscore) macro, which contains the client IP address and reverse hostname, was missing. Thus, the received line seen by SpamAssassin (but not available in the headers because generated on the fly by the milter) was something like: Received: from nohelo (unknown) by trinity.develer.com (Postfix/) with SMTP id unknown This was the line probably causing the UNPARSABLE_RELAY report. At this point, I suspect that SpamAssassin was simply moving over to the next Received from header, and thus matching the original dialup <-> gmail header; and since it did not recognized "ESMTPA" as an authenticated delivery, it started triggering the PBL/DUL rules. The fix (mutuated from Debian) is to change the milter configuration in postfix main.cf by adding this line: milter_connect_macros = j {daemon_name} v {if_name} _ This tells postfix to also define the "_" macro when invoking the milter; the resulting Received header is then parsed correctly by SpamAssassin. BTW: the fix to match ESMTPA vs ESMPT for google header still appears a correct fix to me, though not the main bug here. Thanks everybody! -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
