Auteur: Kelley Reynolds Date: À: exim-users Sujet: Re: [Exim] A couple things before I start my Exim migration
--- Original Message ---
From: Nigel Metheringham <Nigel.Metheringham@???>
Sent: Thu, 13 May 2004 09:28:53 +0100
To: exim-users@???
Subject: Re: [Exim] A couple things before I start my Exim migration
> [No recipe answers here, but a few pointers]
>
> On Thu, 2004-05-13 at 08:08, Tom Wiebe Lists wrote:
> > SpamTraps - SIMS allows you to designate certain addresses as spamtrap
> > addresses and any host sending email to one of these addresses (which I
> > disseminate widely) blacklists the sending server for a short time. A
> > simple yet remarkably effective anti-spam measure. Is there a way to do
> > this on Exim. I believe Stalker's CommunigatePro does this as well. > Not directly. It could, however, definitely be worked round. Spamtrap
> addresses aliased to a program invocation (probably with the sending
> host as a parameter to the program). The program (most likely a perl
> script) would update a dbm file keyed on sending host and having (say) a
> timestamp as the data. You would also have a regular cron job which
> walks the dbm file and removes stale entries (thats why you put the
> timestamp in the data). Use the dbm file as a host blocklist in an acl.
As a more (or less depending on your perspective) encapsulated way of doing this, you can have exim directly create SQL entries in an ACL which are referenced in an ACL previous to it. For cleaning (very important), you have a couple of options. You can use a scripted cronjob, you can just include a timeout in your sql query to not blacklist hosts that are particularly old (then update instead of insert on extant hosts), or you can randomly run a query which will clean out stale entries in an ACL every x messages or so. SQL has a bit more overhead than dbm, but if you are wanting to do a large variety of custom data-tracking and blocking, it may be the way to go for simplicity.
> > Blocking Address Harvesters - When an attempt to send email to a number
> > of invalid addresses is made, the sending server is temporarily
> > blacklisted by SIMS. Another simple, and effective anti-spam measure.
>
> Probably similar form to the one above. Be very careful, though, about
> having blanket address acceptance.
Ditto, use rcpt_fail_count (or rcpt_failed_count, I always forget)
> > Throwaway email addresses - I have a router entry in SIMS that will
> > send any email addressed to user.<whatever>@domain.com to
> > user@??? on the server. I use this extensively to sign up for
> > stuff and, if the address gets abused, can route it to error and I've
> > blocked a bunch more spam. I've tried using an alias for this, to no
> > avail, thinking this is likely a router? Any pointers in setting this
> > up would be most helpful. > Look at local_part_suffix (and local_part_prefix) in routers and
> transports documentation. These are also available in filters which
> allows you to do per user designation of these.
Nigel has this one covered as well.
A bit more on SQL... one of the reasons I like it more than dbm files, despite the overhead, is the ability to track a wide variety of information. For example, it makes it convenient to
1. Store filtering preferences in it so different people can block different attachments.
2. Multiple SA preferences
3. Logging delivery success, one can autowhitelist or autoblacklist over time (very effective at catching infrequent spamming hosts and reducing resource usage)
