On 08/12/2005 4:53 PM, Matt Kettler wrote:
Daryl C. W. O'Shea wrote:
On 08/12/2005 3:52 PM, Matt Kettler wrote:
Technically, the "notfirsthop" is a misnomer, and a carry over from
really old
3.x reverted to the old way. Try it out.
I see you are correct. But why on earth did the devels take a giant step
backwards and do that?
I imagine the 2.6x code got changed after the 3.x code was written, but
that's just a guess.
I can see putting the "notfirsthop" code back to really do that. It is correct
and all. But I can't see why they didn't follow up and change all the rules to
"firstuntrusted".
The "notfirsthop" algorithm is completely broken for use with DUL RBLs. It can
improperly penalize dialup users who have internal servers that correctly
forward to the ISP relay SMTP server. (Think of "neighborhood co-op line share"
type setups.)
I agree. I've had problems with it myself with servers on generic
static ranges that I can't get rDNS changed for and are in SORBS' DUL.
However, I had (apparently mistakenly) thought that everyone was aware
of it because it's come up at least three times in the last couple
months. Some people referred to 'it' being a good thing over 'limited
DUL checks by the MX'.
I suspect that the lack of affected mail in the scoring corpus is the
reason why it's gone unnoticed. I'd been meaning to run tests to
compare the hits between:
-- notfirsthop and firstuntrusted
-- notfirsthop and "not private and not first hop"
to see if there would be any improvements in the scoring corpora. Of
course even the "not private and not first hop" test wouldn't help
anyone with public IP sending mail to a smart host.
Daryl
