Re: [exim] Canvass popular opinion - AMAVIS(new)

On Fri, Apr 30, 2010 at 7:33 PM, Ron White <exim.ml@???> wrote:
> As I continue to build my Exim gateway I've can see the question of a
> virus/spam quarantine on the horizon and would like to ask Exim expert
> their views.

> Ideally my 'per user' settings would allow a user to select if they
> block(drop at smtp time) || tag(change subject header) || quarantine ||
> allow messages that either contain a virus or score above their own

In the majority of mail systems, there is no possible reason to
accept/store messages with viruses in them. Reject these messages
during SMTP time, so that the person sending them has a chance of
fixing their own systems. Never let viruses go through to your
users/customers.

Pretty much the same argument applies to spam. If you know it's spam,
don't accept it (RBL up front to reject connections, etc); and
certainly don't waste your users' time by sending it on to them. Send
everything else on to them with your scores (i.e. standard
spamassassin add headers behaviour) and recommend that they train
their mail reader to their personal preferences.

If you have a close relationship with the users (i.e. internal to some
organisation) you might like to look at per-user spamassassin
preferences &c, but judge the amount of support work that will
generate against the value you gain. It might be more useful to hand
that work over to the people supporting the mail readers instead. How
easy would it be for users to correctly change their own settings?

If you are too accommodating, you end up with the position I've seen
in many many corporations, where *every* message is accepted and
preserved in a quarantine. If a user believes they are missing a
message, they raise a support call on the main admins, who have to go
trawling through the morass looking for it. A lot of wasted time &
effort -- and of course, if the user were not expecting a message,
no-one will be checking for it. Far better to reject up front & let
the sender know immediately that there is a problem.

-jim