Re: [exim] implementing a spamgourmet substitute with exim

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Ian Eiloart
Dátum:  
Címzett: Exim Users
Tárgy: Re: [exim] implementing a spamgourmet substitute with exim

> On 12 Aug 2015, at 12:33, Nick <oinksocket@???> wrote:
>
>
> I do know about the simple method for routing any arbitrary prefix to local user addresses (local_part_prefix = ...; local_part_prefix_optional), but
>
> a) this exposes the real user name in the disposable address - just remove the prefix and you have a non-disposable address
> b) wont permit with shared aliases which route to several users
> c) there is no fine control for specific prefixes - or at least, not without the help of a unix admin
>
> I suspect maildrop/procmail/sieve or plain exim filters or router configurations will be able to do what I want, but I'm not a huge exim expert and I'd rather not re-invent a solution if one exists already.


Oh, and then I read the other half of your post.

Some good news: I think you can do the counting thing. Exim can extract parts from a dot-separated local part, and use those parts as arguments in a rate limiter. I’ve not done this, but I think you need to do something along these lines. Taking the spamgourmet format as an example:

1. extract the counter with something like
${extract{2}{.}{$localpart}}

2. Use that result in a ratelime expression.
$ratelimit = ${extract{2}{.}{$localpart}} / 36500d / per_addr / strict

This limits uses to x emails per century, which should do the job, provided the database is kept up to date. You might want too call a script, when the rate limit is exceeded, to remove the alias from your alias list.

Some bad news: I don’t think there’s a simple way of doing the rest. You’re going to have to set up a whole infrastructure to manage the rest.

Unless, you just do this:

1. Create an alias map foo -> realuser1, realuser2, etc.
2. Permit all prefixed addresses for aliases
3. Create a list of banned aliases.
4. Use the mechanism above to allow people to create self-destructing addresses, using the mechanism above.
5. Allow users to register a secret which can be used to destroy an alias on command. Eg by sending an email to prefix.secret.username@???

Of course, it might be useful to put all these aliases in a different domain: that way you don’t have to worry so much about the namespace.



Now, here are some observations that I wrote before I thought of the above:

I use two mechanisms for disposable addresses:

A) Exim’s suffixes, with plus-addressing (partly because we can forward the emails to Exchange or Cyrus IMAP which also support plus addressing). I also use Gmail plus addressing. This is quite simple to use. I use the sender’s domain name as the suffix, so I can keep track of them, though it does sometimes confuse when I have to talk to them. I don’t think I’ve ever been spammed at any such address, though it’s plausible that some smart spammer is stripping suffixes from addresses. That’s less likely if you use a more common character like a dot. Plus addresses have the disadvantage that one occasionally comes up against a web site that thinks the plus is not a valid email address.

The merits of this mechanism are (i) I don’t need to do anything special to create an address, (ii) I can cancel an address by asking my mailbox filters to discard messages, but I’ve never had to do this, (iii) I don’t need to liaise with anyone for any reason. The demerits are (i) it doesn’t offer any privacy, (ii) persistent spammers can guess my root address from the one I’ve given them.

B) opaq.com masked email addresses from dnt.abine.com. This is a freemium service, and I don’t pay anything for my usage: the premium service doesn’t seem to add enough for me. But they also offer blockers for tracking cookies, single use credit card numbers, password management (I prefer 1password), and other privacy related services.

These addresses get far closer to anonymity, since the domain isn’t mine (the two domains I use have ~20k users and less than 20 users respectively), and the local part does not contain any repeated strings: they’re apparently random eight character hex strings. Perhaps they’re hashes of my email address and a date, or just randomly assigned from an unused pool: the total pool is about 4.2 billion, so probably sufficient that they’ll need a substantial market share before they become guessable.

Opaq.com addresses can be created by a browser plugin, automatically, when I fill in a web form with an email field. And I can log in to their site to see a list of my email addresses, the web site that I created it at (so there’s a security concern right there: a one stop shop of web sites where I chose to conceal my identity). For each address, I can disable delivery or delete the address. Can also see how frequently it’s been used, where it delivers (I can register several destinations), when it was created, or I can delete it.

So, if I was very concerned about security I’d want assurance from Abine that when I delete an address, they keep no record of it beyond the fact that it should not be reallocated. And that they keep no delivery logs.

Now, unless you have a lot of users, I’m guessing privacy isn’t really your concern: it’s the worry that an email address might get re-used by someone else.


--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148