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

Thank you for taking the time to reply Jim.

On Sat, 2010-05-01 at 16:09 +1200, Jim Cheetham wrote:
> 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.
I entirely agree.

>
> 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.
This makes sense Jim, thanks. There is a concern that it becomes a bit
like 'an old curiosity shop' if you allow users to say 'what is this
message you've blocked? Can I see it - it may be important?'.

My preference is to drop spam at SMTP time after content scanning it.
Let it become the senders problem if it's a false positive. I appreciate
that in a heavy / hard-working server this may have serious performance
issues - but I'm not sure at what point the balance tips.

>
> -jim
>