On Thu, 12 Feb 2004, Tony Finch wrote:
| Chris Edwards <chris@???> wrote:
| >
| >So now we use the selective defer scheme as discussed before. It seems to
| >work fine. See Alan's outline:
| >
| > http://www.exim.org/pipermail/exim-users/Week-of-Mon-20031006/061151.html
|
| MBM told me about this trick on Monday evening in the context of dealing
| with different policies between postmaster and other recipients. I like
| it :-)
I'm pretty sure it was Philip that first suggested the idea, long before
it was even possible. Then, when "defer" ACLs were introduced, someone
else ( can't remember who sorry ) posted a recipe.
| One question I have for you (since you've actually deployed it) is how
| you deal with aliases. I can in principle deal with the case of aliases
| like tony.finch@??? vs. fanf2@??? by pre-computing
| a big lookup table generated from all our virtual domains, but I'm not
| too fond of the idea -- it isn't very dynamic.
Fraid we aren't doing anything much clever on the technical side.
We have 2 profiles - spam-haters and spam-lovers. By default, everyone is
a spam-hater (thanks to a robust organisational policy) and messages are
rejected during the dialog. Anyone who wants to receive their spam can
opt to do so - and we deliver it with tagged headers so they can do the
junk folder thing if they so wish.
Much of the mail handled is destined for departmental servers where we in
the centre don't have direct access to the user/alias db - although tho we
do use callforwards to reject unknowns. Moreover we don't have any
consistent way of authenticating users on departmental servers, which
makes it tricky to have a self-service method for folk to change their
prefs. So we came up with this solution:
Users enter their full email address in a web form. They click "submit"
and receive an email with a confirm URL, which they click. The address
is then registered in MySQL as spam-loving.
If the user has 2 aliases on which they wish to receive spam, they simply
need to submit them both. On the other hand, in our environment, partly
for historic reasons, many users have several aliases but don't know them
all. They only need submit the alias they regularly use and/or the alias
on which they sign-up to receive spammy newsletters etc. Any other
aliases they don't know about get filtered by default. The frontdoor MX
machines simply have a single table of spam-loving addresses.
| More tricky is the case when a recipient address resolves to more than
| one person and they have different settings. Do you implement a separate
| spam threshold for each alias, or smoosh the users' settings together
| in some way to get some compromise threshold?
All or nothing. If the owners of a distribution alias register were to
register it as spam-loving then all the recipients would get the spam.
This hasn't happened yet...
--
Chris Edwards, Glasgow University Computing Service
