ietf-asrg
[Top] [All Lists]

Re: [Asrg] Spam, defined, and permissions

2004-12-22 10:35:14
This is yet another reason why a fine-grained permissions-based
approach, where the *recipient* can decide what E-mails they do and
do not want to receive (based on who the sender is, and what the
mail contains) is so decidedly the right way to pursue this problem.
So long as you are willing to spend an unlimited amount of money on
an e-mail infrastructure that accepts and stores terabytes of spam,
Sorry, John, why would we have to accept and store all this unwanted
mail?


Well, I didn't write what you responded to, but....


That's alright, it's a public list, isn't it?


You'd have to accept it, and probably store it temporarily, because you
can't apply filters that test the content until you _have_ the content.
(I suppose you may be able to optimize that away for users that don't
have any content-dependent filters turned on, or if the user has an
"absolute" test (= "this is unwanted, no question" when it trips)
enabled that the mail fails before the content shows up.

If the message tests out as clearly unwanted, you don't need to store
it at all.  But I suspect few people would use that; most, I expect,
will want such mail not dropped on the floor, but rather put in some
kind of "spam folder", in which case you _do_ need to store it
semi-permanently.

Of course, that's a guess.  If anyone has any hard numbers for those
proportions, I'd love to see them.


I'm familiar with the workings of a small-ish system with >75k accounts.
For a (probably roughly representative n=3350) sample of accounts, we're
only holding 284MB in quarantine ("spam"-folders). So I guess that we may
be 'ageing-out' rather aggressively, and perhaps filtering rather
conservatively.

Most customers seem fairly happy with the way things work, 
of another sample (n=3564), 42 have turned off "Spam Protection".
I'm guessing that it's these people who would be most likely to chose
fine-grained control.


Anyway, to the point:
I think that there's a misconception here. We could probably expect to see
"layers" of permission utilising whatever classification tools a provider
decides to make available to their customers. There are a number of points
in the process at which customers choices can be enforced which will have
different resource requirements:

For instance, I have customers who want only to receive mail from a small
set of senders. I can reject all other mail without examining or storing
much of the content.

Some of my customers are happy to have mail rejected on the basis of DNSBL
(or other) listings, or perhaps on SPF(eek!)-failures, again, I don't need
to accept/store those messages.

Others may be happy to reject messages with (say) SA scores > 20 but
quarantine those with 5 < score < 20. And of course they may want to
configure how messages are 'aged out' of the quarantine.

For that matter, I'm sure that some of my customers would be happy to use
some consent-token scheme, in which case I'm likely to be storing very
little unwanted mail for them.

And of course, we would aim to reject messages (if we do) during SMTP, so
as to limit the reliablity impact. This has all been said many times
before.


Some might assert that it's not economic to put this kind of stuff at
boundary MTA, and it might offend the religious,
but I don't believe it should be so lightly dismissed.  




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg