Re: [exim] Greylisting - using Exim new features - ratelimit…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Marc Perkel
Fecha:  
A: exim-users
Asunto: Re: [exim] Greylisting - using Exim new features - ratelimit with noupdate


Philip Hazel wrote:
> On Mon, 9 Jul 2007, Marc Perkel wrote:
>
>
>> The idea behind this is that it requires the server be touched twice in
>> the proper order to get in. Spam bots try once and not in the proper
>> order. That's how the filter works.
>>
>
> Presumably you have some kind of white listing? Otherwise, Exim as a
> sender will behave like this:
>
> 1. Try first IP
> 2. Temporary error - remember this
> 3. Try next IP
> 4. Accepted - message delivered
> 5. New message arrives
> 6. First IP hasn't reached its retry time yet
> 7. Try second IP
>
> Will that be accepted?
>
> If so, that's fine for a server sending from a single IP. What about a
> server that sends from different IPs (because it's implementing a number
> of virtual servers) but has a single set of retry data? In the above
> scenario, the second message could then be from a different IP. (There
> are servers that do this - facilities were added to Exim not very long
> ago to make it easy to do this.)
>
>

Hi Phil,

OK - if the second message were from a different IP then it would also
have to try twice. The only problem, and I don't think anyone does this,
is if the message tries the lowest numbered MX and then immediately
changed IP addresses and tries the second MX. As long as the message
uses the same IP per run through attempt it will be good.

Unlike traditional greylisting that initially delays new incoming email
until the user is learned, this system only adds a fraction of a second
to the process because the attempt at the second IP address will
succeed. So it's really a different kind of system than traditional
greylisting. I'm running a similar system now (not using Exim to do it)
and it works. But I think with these new features ( / noupdate) that I
can do it in Exim and do a better job.

What I also want to do is have several fake higher IPs that always
return defer but count as penalty events wiping out the good karma data
and making the IP start over. So if you could add a </ forget / key>
feature to ratelimit that would be great. I need a way so that one event
can reset the data for a different event being counted. The idea is that
touching the lowest MX opens the door for the next attempt. Touching the
high dummy MX records locks the door for say 5 minutes.

Also - I'll be tying this into my more long term automatic whitelisting
and blacklisting process. I have an external system that works like your
ratelimiting system but designed to store data for days and can collect
data from multiple servers. I need to update my documentation to reflect
how I'm doing things now but at this point almost all my spam filtering
is based on the behavior of the spammer rather than the content of the
message. I only use SpamAssassin on less that 1% of incoming email attempts.

Good email will always try twice. Spambots don't. So it passes 100% of
your good email and kills 90% of your spam. I do have whitelisting as
well based on sender reputation that allows some IPs to bypass the process.

Anyhow - that's what I will be testing as well as other tricks.

Tell me about this virtual server feature with shared data. What feature
is that? I've been running OpenVZ and slowly virtualizing everything so
I can move functionality between physical servers. This sounds interesting.