http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4828
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From [EMAIL PROTECTED] 2006-04-10 14:27 -------
I asked about this on the DCC mailing list. I was wrong about what DCC is doing
and how we should use it. The summary of what I learned is:
The rcvd_next option is deprecated. DCC has configuration options MX and MXDCC
which are used to select the correct Received header in a similar manner to the
way SpamAssassin uses the trusted_networks configuration option. If DCC is
configured properly with MX and MXDCC it should use the same Received header as
SpamAssassin, but we can make that irrelevant by passing client ip address and
name and HELO string as in patch 3463. However, I missed the plugin's call to
dccproc which it uses if dccifd is not available. That call can be passed the
client ip address in a -a option. But dccproc needs the correct MX and MXDCC
options so it looks at the correct Received header for client hostname and HELO
string.
More importantly, I found that the DCC servers will block excessive use of
dccproc and therefore spamd should be rechecking for the availability of dccifd
regularly.
As the initial premise of this bug was wrong, I'm going to reopen this to change
it from FIXED to INVALID. See especially the first two links below for support
for my reasoning for that. The links are messages on the DCC mailing list. If we
need more changes to the plugin I'll open another bug.
http://www.rhyolite.com/pipermail/dcc/2006/003125.html
http://www.rhyolite.com/pipermail/dcc/2006/003126.html
http://www.rhyolite.com/pipermail/dcc/2006/003139.html
http://www.rhyolite.com/pipermail/dcc/2006/003140.html
http://www.rhyolite.com/pipermail/dcc/2006/003142.html
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
