-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Quinlan writes:
>[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
+1.
> - if any of Return-path:, Sender:, X-Sender:, X-Envelope-From:,
> X-Env-Sender:, or 'From ' are above the first Received: line, use
> that.
"From " can be effected by local delivery, ie. sendmail's "-owner" stuff,
as far as I know... not sure about that. But I wouldn't trust it.
> - if the first Received: line contains (envelope-from) use that
+1
> - if a trusted result is needed, punt
- -0.5: we can carry on if there's other untrusted headers.
> - if an untrusted result is acceptable (positive scoringe rules), then
> take the first line that matches one of the above
ok, +1
>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.
yep.
>> > 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)
that's very low, given the potential speed of performing rDNS lookups :(
>> 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...)
definitely! ;)
>>> - check_mx_attempts and check_mx_delay are gone
>>
>> +1.
>
>a way to handle ignored/deprecated options in Conf/Parser.pm ?
I don't think there's one there right now, but we could easily
add a handler for deprecations, since the parser gets to
- (a) list synonyms for the current option
- (b) register a code block to handle the option
- (c) inside that block, can find out what config param was
used by the user
So there'd be a code block for deprecation, which has all the deprecated
commands as synonyms, and the code block just does something like
warn "Option '$optname' is deprecated.\n";
return;
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFA+FeaQTcbUG5Y7woRAi+3AKDQO7DtM1JmwhdbNntU3pJFds5PxQCeNJai
quir+7wEbJoyXCq7jPBl0wk=
=CBMV
-----END PGP SIGNATURE-----
