Re: [exim] Lookups for blacklisted links within messages

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Ted Cooper
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] Lookups for blacklisted links within messages
Marc Perkel wrote:
>
> Ted Cooper wrote:
>> Steve Kemp wrote:
>>
>>> Unfortunately I don't think this would be a trivial thing to
>>> do in exim - I do it externally.
>>>
>> What do you use to get the URI out reliably? I also run most of my
>> testing externally via ${readsocket} but have no method other than using
>> SpamAssassin to get the URI out and that only gives we the raw domain names.
>>
>>
> Tell me more about readsocket. Trying to graps the concept. What do you
> have that talking to? Can you post an example?


I have a small daemon running listening on a UNIX socket that processes
the short string messages I send it and returns the result. At the
moment it's just a relatively complicated greylisting daemon. I don't do
on the fly URI checking but was hoping to start doing it outside of SA
since after demime is run, I have access to the raw parts of the email
in the spool directory. Provide the daemon with $exim_message_id and
some way to pull out the URI and it can do all the processing.

${readsocket} works almost exactly the same as ${run} except you need a
daemon running that will listen to and accept the socket connection. I
found that using ${run} was was too computationally expensive to use and
also had a really bad habit of crashing/dying with a SIGTERM from
somewhere. Even simple BASH scripts would run into this problem.

Anyway, here are some little bits of how I use it in my config. I'll
refrain from posting my daemon since it's crap. I wrote it in CLI PHP so
I could get it done quickly but the spammers have changed tack over the
last 6 months and it is no longer adequate[1].

In the acl_check_helo ACL, I have the following which asks my daemon if
this host is a stupid host - ie, they don't know how to react to DEFER
at data time (I move the defer to RCPT time for them), ran into sync
problems (control=no_enforce_sync but only taste message), or generally
misbehave (taste message once, process it and wait for review). This was
the main reason for me writing the not-quit ACL hook for exim.

accept  set acl_c_stupidhost  = \
    ${readsocket{GLSOCK}{stupid $sender_host_address $sender_helo_name}\
    {20s}{ }{SOCKERR}}
          set acl_c_shseen      = ${substr_4:$acl_c_stupidhost}
          set acl_c_gldelay     = ${if \
            eq{${substr{0}{3}{$acl_c_stupidhost}}}{YES}\
            {${eval:30 * $acl_c_shseen}}\
            {$acl_c_gldelay}}
          set acl_c_stupidhost  = ${substr_0_3:$acl_c_stupidhost}


This also sets up the tarpit delay based on how many times this host has
been stupid in the past. The value is sanity checked for each usage to
prevent timeouts and shseen part has a limit too. First line sets the
acl var to the return value from my daemon and the rest split the
information into useful variables for later. Stupid hosts also get lots
of other restrictions placed on them as these rarely end up being
legitimate mail servers.

During the rcpt stage I also have the greylisting part which is only
ever set once per connection. Line wrapped by MUA.

  warn    !hosts        = +relay_from_hosts
          !authenticated = *
          condition     = ${if eq{$acl_c_greylist}{***NOT SET***}{yes}{no}}
          set acl_c_greylist    = ${readsocket{GLSOCK}{query
$sender_host_address $sender_helo_name <$sender_address>
<$local_part@$domain>}{20s}{ }{SOCKETERROR}}
          log_message   = greylist: F=<$sender_address>
T=<$local_part@$domain> G=<$acl_c_greylist>


(deny/defer/fallback reaction ACLs here)

And in the quit and not-quit ACLs

  accept   hosts        = ! +relay_from_hosts
          !authenticated = *
          continue      = ${readsocket{GLSOCK}{quitused
$sender_host_address}{20s}{ }{SOCKETERROR}}


I hope that helps understand the ${readsocket} stuff. It pretty much
allows you code whatever complicated thing you want and use the results
in the exim ACLs.

Regards,
Ted.


[1] While killing off zombie spambots is a no brainer, spammers have
moved onto using compromised legitimate websites/servers to send spam
which pretty much bypasses the greylist effort. I wouldn't stop using
it, but I need something a little smarter and future proof now.
I'm in the process of writing a new one in C++ that will do
significantly more like tying itself into DynaStop/p0f/nmap/MX
info/reputation/history but it still has months of spare time
development before I even think about using it.

--
The Exim Manual
http://www.exim.org/docs.html
http://docs.exim.org/current/