Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

Defer in warn ACL results in tempfail despite docs

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


chris+exim at qwirx

Jan 26, 2012, 4:19 AM

Post #1 of 4 (656 views)
Permalink
Defer in warn ACL results in tempfail despite docs

Hi all,

The Exim documentation says:

"If any condition on a warn statement cannot be completed (that is, there
is some sort of defer), the log line specified by log_message is not
written After a defer, no further conditions or modifiers in the warn
statement are processed. The incident is logged, and the ACL continues to
be processed, from the next statement onwards."

<http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECID200>

It's very useful to have at least one way to execute a condition that
might defer, without deferring the message. For example, I used it to
implement our backup MX:

<http://blog.aptivate.org/2009/01/28/backup-mail-exchangers/>

However it doesn't seem to work in this case:

# check WHOIS for domains registered by Communicado Ltd
warn set acl_m_whois = ${run {/usr/bin/whois $sender_address_domain}}

defer
condition = ${if match {$acl_m_whois} {Company number: 3709008}}
message = Local blacklist of Communicado Limited's domains

(by the way, these guys are spewing spam at a rate of knots, this is a
very effective check when it works)

2012-01-26 11:13:11 H=out3-smtp.messagingengine.com [66.111.4.27]
F=<rod.......@fastmail.fm> temporarily rejected RCPT
<tom.......@aptivate.org>:
failed to expand ACL string "${run {/usr/bin/whois
$sender_address_domain}}": command timed out

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?

Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | Stop nuclear war http://www.nuclearrisk.org |

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


chris at qwirx

Jan 26, 2012, 4:18 AM

Post #2 of 4 (623 views)
Permalink
Defer in warn ACL results in tempfail despite docs [In reply to]

Hi all,

The Exim documentation says:

"If any condition on a warn statement cannot be completed (that is, there
is some sort of defer), the log line specified by log_message is not
written After a defer, no further conditions or modifiers in the warn
statement are processed. The incident is logged, and the ACL continues to
be processed, from the next statement onwards."

<http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECID200>

It's very useful to have at least one way to execute a condition that
might defer, without deferring the message. For example, I used it to
implement our backup MX:

<http://blog.aptivate.org/2009/01/28/backup-mail-exchangers/>

However it doesn't seem to work in this case:

# check WHOIS for domains registered by Communicado Ltd
warn set acl_m_whois = ${run {/usr/bin/whois $sender_address_domain}}

defer
condition = ${if match {$acl_m_whois} {Company number: 3709008}}
message = Local blacklist of Communicado Limited's domains

(by the way, these guys are spewing spam at a rate of knots, this is a
very effective check when it works)

2012-01-26 11:13:11 H=out3-smtp.messagingengine.com [66.111.4.27]
F=<rod.......@fastmail.fm> temporarily rejected RCPT
<tom.......@aptivate.org>:
failed to expand ACL string "${run {/usr/bin/whois
$sender_address_domain}}": command timed out

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?

Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\ _/_/_/_//_/___/ | Stop nuclear war http://www.nuclearrisk.org |

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

Jan 27, 2012, 6:17 PM

Post #3 of 4 (620 views)
Permalink
Re: Defer in warn ACL results in tempfail despite docs [In reply to]

On 2012-01-26 at 12:18 +0000, Chris Wilson wrote:
> # check WHOIS for domains registered by Communicado Ltd
> warn set acl_m_whois = ${run {/usr/bin/whois $sender_address_domain}}

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. Eg, "jwhois".

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.


Next: note that this is a "set" on a warn statement, not a condition on
a warn statement.

Perhaps:

warn set acl_m_donotlikethem = no
warn condition = ${if match {${run {/usr/bin/whois $sender_address_domain}}}\
{Company number: 12345}}
set acl_m_donotlikethem = yes
defer condition = $acl_m_donotlikethem
message = We do not like you

> 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?

It's tempfailing because the command isn't in a condition and didn't
complete. Probably whois rate-limiting kicked in to throttle your query
volume (assuming you're querying the public whois servers).

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


chris at qwirx

Feb 1, 2012, 1:54 AM

Post #4 of 4 (608 views)
Permalink
Re: Defer in warn ACL results in tempfail despite docs [In reply to]

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 [at] qwirx> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.