rcvd_nxt and IP checksum

Sidney Markowitz sidney@sidney.com
Mon Apr 10 06:21:54 UTC 2006


On 4/10/06 5:02 PM, Vernon Schryver wrote:
> However, either I misunderstand or you are mistaken about the bogosity
> of client IP addresses based on the first Received header.

Thanks for clearing up a number of misunderstandings that I had. I
apologize that it caused some of the questions I asked not to make
sense, but you managed to include enough details in your answer anyway
to set me straight. I've only just looked at SpamAssassin's DCC plugin
in response to a bug report and apparently did not look at all of it
carefully enough.

My mail goes through one or more of my ISP machines before it gets to
me, so I'm not used to thinking of the very first Received header as
being the correct one, or even that skipping a fixed number of headers
could work. I didn't know about your MX and MXDCC options, and thought
that the only way to get an accurate result would be to use
SpamAssassin's determination of the correct Received header that is
based on similar configuration options.

> There is another change that is more important.
> SpamAssass when running as a daemon should
> periodically check to see if dccifd has been started.

Ok, that does seem important enough to try to include in our next point
release if it needs to be done. I need to check if our current version
performs the check for the daemon in the root process or in the more
short-lived child processes. If I make that change I can also have
SpamAssassin supply the client ip address to dccproc with -a and supply
the client ip address and hostname, and the HELO string to dccifd.

I don't see how to specify client hostname and the HELO string to
dccproc. Is it the case that the only way to get the right values to
dccproc is to have MX and MXDCC options configured properly in the main
DCC whitelist file? If the only user of DCC on a system is SpamAssassin,
I think it would be more reliable to only have to have SpamAssassin's
configuration for that to be correct, rather than requiring the
configurations to match up. From what I see, I would have to include
something in our documentation about making how to make sure that DCC's
MX and MXDCC options are consistent with SpamAssassin's trusted_networks
and internal_networks configuration settings.

  Sidney Markowitz
  http://www.sidney.com




More information about the DCC mailing list

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