Re: [exim] DynaStop - It works for me.

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Alun
Fecha:  
A: exim-users
Asunto: Re: [exim] DynaStop - It works for me.
Chris Lightfoot <chris@???> said, in message
63rm8QMHchV8.63m8+kHi8V1OriZt+hqWlg@???:
>
> but what do they do in that case? if the message is
> accessible to them, they just have to copy it from their
> spam folder; otherwise they have to wait for the weekly
> report, or go and hassle the admin, or whatever.


I don't know if it's a worthwhile point to make at this time, but I
recently re-hashed the spam filtering system for the University.
Previously we offered outright blocking, flagging and refiling of
presumed spam, on a per-user opt-in basis.

We found that:

Blocking was the most popular opt-in service. Our users just didn't
want to receive this stuff at all and, it seems, were willing to accept
the risk of collateral damage.

Refiling was taken up by very few people and, of those, the vast
majority never even looked at the messages that had been refiled. This
led to "Spam" folders which were GBytes in length containing messages
that had never been read, going back years. Of course, the messages in
these folders, valid or otherwise, had been delivered successfully, so
the senders never knew they'd not been read.

This latter case was the most worrying one. With the introduction of
Freedom of Information legislation, there are stringent requirements on
acceptance of mail (namely that if we accept it we should deal with
it). Presumably the first test case will clarify just how reasonable we
have to be, but Aber doesn't want to be the one to test it! So, we
wanted to move to a "block it or flag it in an obscure header"
approach, whereby we either rejected at SMTP time or required our users
to think a little about how crazy they wanted to be with their own
client-side filtering.

The re-organised system is still opt-in/out, and acts at SMTP time,
either blocking messages or allowing them through with an added header.
We have (currently) 57,184 e-mail addresses here. The changed system
was widely publicised. The default action is to block at a SpamAssassin
score of 5, or on the basis of a few DNSBLs or other local criteria.
159 recipients have chosen to change their settings from the default.
145 of these have made changes to strengthen the blocking, leaving 14
who've chosen to opt out of it (though only 2 have opted for *all*
blocking to be turned off). If we assume that 99.7% (the 56,995 who've
not made any changes to their filtering options) of recipients have
just ignored the publicity, we're still left with 84% of the remainder
opting for more, rather than less, blocking.

People can look, at any time, at the list of senders we've blocked for
them (though not the content), using a web page, and can whitelist
addresses themselves. Of course, I don't know for certain how many
false positives we've had, but the current whitelist across all 57,184
addresses, has only 189 entries, submitted by 78 recipients. In the
past four weeks we've blocked 5,246,085 messages. Either we've got a
false positive rate of 0.004% (1 in 27,000) or my users really don't
care about message loss, even though they've got the option. To me, at
least, either case is acceptable!

Cheers,
Alun.

-- 
Alun Jones                       auj@???
Systems Support,                 (01970) 62 2494
Information Services,
University of Wales, Aberystwyth