http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4828
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2006-03-17 06:16 -------
(In reply to comment #9)
> I'm still not sure about this. If it is the case that you cannot know for sure
> what 'n' will be, what sense does it make to configure a fixed number of
> rcvd_nxt options? And I don't see what other options could be used and still
> let
> dccifd to work with SpamAssassin.
Yeah, there's not much point in a static config option for rcvd_nxt. I'd be for
automatically passing a value for it if it weren't for us completely ignoring
some Qmail-like internal relays that provide no useful info.
> If we have access to the SMTP client ip address and host name and the EHLO
> string, why would it not be better to always pass them along instead of
> forcing
> dccifd to find the correct Received header and hope that it parses them
> correctly?
I've now read the current documentation
(http://www.rhyolite.com/anti-spam/dcc/dcc-tree/dccifd.html) and now have two
half clues about what you're talking about.
I think the best thing to do, given that we can't always be sure about the value
for "rcvd-nxt", is to pass "client" and "HELO" values using the values from the
first external received header. You can get them easily in the plugin via:
$permsgstatus->{relays_external}->[0]->{ip}
$permsgstatus->{relays_external}->[0]->{helo}
and an optional hostname for "client":
$permsgstatus->{relays_external}->[0]->{rdns}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
