http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4828
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Status Whiteboard| |Needs 2 votes for 3.1 branch
Target Milestone|Undefined |3.1.2
------- Additional Comments From [EMAIL PROTECTED] 2006-04-08 15:46 -------
As far as I can tell there are no circumstances in which any of the options to
dccifd, other than the "header" option which we always send, would be correct
for SpamAssassin to use. A fixed number of rcvd-next would not work in the face
of variable length paths through internal relays taken by different emails. So
the only way of ensuring correct values passed to dccifd is to use values from
the Received header that SpamAssassin figures out, as in this patch.
Committed to trunk revision 392533.
I'm leaving this open retargeted to 3.1.2 because I'm concerned about the
possible effect of many SpamAssassin installations that are reporting to DCC
servers each with different helo and client values based on their first Received
headers, making that information useless for the clearinghouse checksum.
Comments and/or votes, please?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
