Hi Phil,
>> So why is it tempfailing the message? And is there any other way to avoid
>> a tempfail on a condition that results in a defer?
>
> Note that this is a "set" on a warn statement, not a condition on a warn
> statement... It's tempfailing because the command isn't in a condition
> and didn't complete.
Ah, I missed (or misunderstood) the word "condition" in the docs :)
I actually changed this from a condition to a "set" to help debug another
problem. It would be great to have a bit more flexibility about whether a
defer results in a tempfail. Perhaps a "defer =
fail|tempfail|decline|ignore" option on ACL verbs?
> Probably whois rate-limiting kicked in to throttle your query
> volume (assuming you're querying the public whois servers).
[...]
> You may want to investigate using a caching whois server, so that high
> volumes of mail from the same domain don't get you blacklisted at the
> whois providers.
Good idea. Although it could still happen if I get a lot of mail from
.com domains that the .com registrar blacklists me.
> Alternatively, a small daemon which listens on a socket and takes a
> domain and emits the company number if found, which can maintain
> clustered caches, etc, and avoid the fork/exec overhead of invoking
> whois directly for spam messages.
>
> An advantage of going the daemon route is that Exim's ${readsocket}
> takes a timeout parameter and you can tune the behaviour of various
> errors.
Also a good idea, although writing a socket server sounds like a lot of
work.
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chris+sig@???> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
