https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5895
Sidney Markowitz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Sidney Markowitz <[email protected]> 2010-01-04 16:45:46 UTC --- I've been asked to consider this RFE for inclusion in 3.3.0, which it is already targeted for but at P5 so it would not have made the cut if not brought to our attention. The purpose of this enhancement, as I see it, is to add a config option to facilitate an ISP making use of their own heuristics for determining a sending IP address so that it can be checked against the DNSRBL rules in circumstances where the trusted_network heuristics don't do the job, for example some mail sent from a webmail interface or via some forwarding methods. My apologies to the original submitter if I didn't get that right. I have two questions for the other devs: 1) Is it too late -- Are we too frozen to consider adding this? 2) Look at finish_tests() defined in the proposed patch. The comments in Plugin.pm imply that finish_tests() is to be defined by a plugin to clean up an eval'd method that th plugin has pushed on a global array. That is how it is used in the plugins that currently define it. This patch only pushes string values from the configuration, not eval's methods, on to @EXTRA_RBL_HEADERS, so maybe finish_tests is not needed. However, there are no other plugins that use a global array in this way - Either they define such a global variable and push eval'd methods on it and then define finish_tests, or else they push the config values into a hash on $self such as the way $self->{uridnsbls} is used in URIDNSBL.pm. My question is, should this patch use $self->{dnsevalextras} (a new name I just made up) instead of @EXTRA_RBL_HEADERS, and if not, does it need to define finish_tests() to empty @EXTRA_RBL_HEADERS? I think that question 2 is more a matter of style than of substance and should not be used as a reason to reject this patch for 3.3.0, in case anyone is inclined to say that having such questions makes it too uncertain to go with at this point. I think the decision about including this should depend on whether or not it is too late to include what I think is a very safe and simple enhancement. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
