[EMAIL PROTECTED] (Justin Mason) writes: > Hmm. Well, the idea is: > > 1. if the unusual headers (X-Envelope-From, Envelope-Sender, X-Sender) > are present and trustworthy, use them > 2. fall back to the RFC-2822 std, Return-Path, which is pretty much > always present
Okay, I looked a bit more closely, I missed some of that logic, thanks. How does this strike you? - if the top Received: header is fetchmail, ignore/strip it and any headers above it, I don't think we have to punt for these - if any of Return-path:, Sender:, X-Sender:, X-Envelope-From:, X-Env-Sender:, or 'From ' are above the first Received: line, use that. - if the first Received: line contains (envelope-from) use that - if a trusted result is needed, punt - if an untrusted result is acceptable (positive scoringe rules), then take the first line that matches one of the above So, store two results: one trusted (maybe undef) and one untrusted (less likely to be undef). >> I think the heuristic could probably use some work, perhaps look at >> the top Received: line to determine a priority order for headers. > how would this work? Well, I like your logic better, so I modified my thinking, however, the idea was to look at the first Received line and judging by which MTA added it, decide which header to grab. There may be cases where an MTA doesn't put its envelope-sender header above the Received: line it adds. Maybe that would still make sense. > > 2. ROUND_THE_WORLD - is this still a tflags net test? > > Yes, it may need to perform rDNS lookups. > > If the S/O is bad, this would be a good candidate to drop, as the > spammer behaviour is no longer prevalent. It's pretty good, but low hit rate: 0.060 0.1069 0.0000 1.000 0.55 0.17 ROUND_THE_WORLD 0.072 0.1144 0.0000 1.000 0.48 0.17 ROUND_THE_WORLD:bzoetekouw 0.088 0.1750 0.0000 1.000 0.50 0.17 ROUND_THE_WORLD:jm 0.049 0.1063 0.0000 1.000 0.48 0.17 ROUND_THE_WORLD:parkerm 0.004 0.0084 0.0000 1.000 0.47 0.17 ROUND_THE_WORLD:quinlan 0.237 0.2959 0.0000 1.000 0.57 0.17 ROUND_THE_WORLD:rODbegbie (wow, it barely even works for me) > oh good. I think there's other MX tests elsewhere in the code though... Yeah, I still have to rationalize that stuff a bit. > +0.5. Only if the old names remain as synonyms. > > We can now support synonyms very easily and efficiently in the Conf > code, and I think we've broken quite enough backwards compatibility in > this release. Nah. ;-) (If you insist...) >> - check_mx_attempts and check_mx_delay are gone > > +1. a way to handle ignored/deprecated options in Conf/Parser.pm ? Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
