rcvd_nxt and IP checksum

Sidney Markowitz sidney@sidney.com
Sun Apr 9 23:45:14 UTC 2006

I recently noticed that SpamAssassin has been sending to dccifd with null
client and HELO, and no rcvd_next option. That causes dccifd to use the first
Received header to get its values, which makes no sense. I have fixed that in
the current developer build of SpamAssassin to explicitly pass through the
client and HELO values that SpamAssassin already reliably figures out.

While doing this, I noticed that changing client and HELO, or leaving them null
and including one or more option rcvd_next, changed the IP checksum but made no
difference to Body, Fuz1, or Fuz2, therefore no difference to the spam
detection. That makes sense, because the vast majority of queries to DCC must
be using completely bogus client and HELO values that are based on the first
Receive header.

Is my analysis of this correct? Do you (the DCC developers) make any use of
client and HELO? Is this change I made in SpamAssassin going to have any actual
effect, and if so, is there a good reason to put it in our upcoming point
release instead of leaving it for the next major release?


 Sidney Markowitz
 One of the SpamAssassin developers

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.