rcvd_nxt and IP checksum

Vernon Schryver vjs@calcite.rhyolite.com
Mon Apr 10 05:02:16 UTC 2006

> From: Sidney Markowitz 

> I recently noticed that SpamAssassin has been sending to dccifd with null
f> 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.

Why does that make no sense?   In most cases the first Received header
will have been added by the local MTA and so will contain the IP address
of the SMTP client immediately responsible for sending the message to
the local MTA.

The old rcvd_next option for dccifd and the old -r argument to dccproc
should not be used.  Instead, when you need tell dccifd or dccproc to
skip Received headers added by MX servers, internal relays, and so
forth, us MX or MXDCC lines in the main DCC whitelist file, often

>                                                          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.

Assuming SpamAssassin has reliably figured out the client IP address
and HELO values, that is a good thing.  SpamAssassin should also use
something like `dccproc -a` to give the IP address to dccproc
when dccproc is being used instead of dccifd.

Except when running inside the MTA such as a sendmail milter, SpamAssassin
can only get the HELO value from a Received header and can only get the
IP address from a trusted Received header or from some other header
added by the local MTA.  With luck, dccproc, dccifd, and SpamAssassin
should guess the same values for the SMTP client IP address.  When
dccproc and dccifd guess a HELO value, it should be the same as
SpamAssassin's guess.  I've not spent as much code on parsing for HELO
values as client IP addresses because HELO values are less useful to
DCC clients.

>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.

The Body, Fuz1, and Fuz2 checksums are of the body and including nothing
of the headers or envelope.

However, either I misunderstand or you are mistaken about the bogosity
of client IP addresses based on the first Received header.  In most
installations, the first Received header is the only header that can
be trusted and it does in fact contain the IP address of the only SMTP
client that can be accurately blamed for sending the message.  I hope
you are not suffering the old SpamCop confusion/delusion about the
possibility or practicality of parsing Received headers back to mail
senders through unknown relays.  Even the SpamCopy people seem to have
finally gotten past that bad idea and use an extra database to know
when it is safe to follow Received headers.

> 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?

I know nothing about SpamAssassin release policies, and so cannot say
when or even if you should those changes.  There is another change
that is more important.  SpamAssass when running as a daemon should
periodically check to see if dccifd has been started.  It is important
to prefer dccifd when it is running because it is both much more efficient
for DCC client system (the system running SpamAssassin) and far less
costly to the public DCC servers.  One of my big jobs is tracking down
people responsible for mail systems handling more than 100K mail messages/day
and systems behind misconfigured firewalls that block UDP port 6277.
Both trigger the DoS defenses of the public DCC servers and waste
their owner's bandwidth.

There are two ways in which SpamAssassin can be wrong about whether
dccifd is running.  One is when dccifd is started after spamed.  The
other is when dccproc notices that it has been used a lot and starts
dccifd.  SpamAssassin should check at least every 30 minutes to
see if dccifd has become available.  When I last looked at the
SpamAssassin source, that change seemed straight forward.

As for the the IP address and HELO values vs. the DCC, the HELO value
is can be used in a DCC whitelist file, often in /var/dcc/whiteclnt,
to white- or blacklist mail.  This is rare in DCC+SpamAssassin
installations.  The SMTP client IP address can also be used for white-
or blacklisting.  This is done more often in DCC+SpamAssassin
installations.  More valuable is that some versions of the DCC code
uses SMTP client IP addresses to compute DCC Reputations.  See

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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