need organizational hint

Phil Howard phil-info-cyrus at ipal.net
Sat Apr 12 21:15:54 EDT 2003


On Sat, Apr 12, 2003 at 03:31:47PM -0500, Amos Gouaux wrote:

| >>>>> On Sat, 12 Apr 2003 09:41:12 -0500,
| >>>>> Phil Howard <phil-info-cyrus at ipal.net> (ph) writes:
| 
| ph> Not all users want, or do anything with, a separate spam folder.
| 
| We've been experimenting with this very approach this semester.
| That is: between the gateway MTA and the Cyrus server, mail gets
| processed by SpamAssassin and is "tagged" appropriately.  If folks
| wish it, they can then use Sieve to save spam into a JunkMail
| folder.  We've then got a weekly cron job (probably could use Cyrus
| events) to perform the following:
| 
|   ipurge -f -s -d 60 "user.*.JunkMail"
| 
| So far we haven't made a big deal about this, but have set up a
| number of folks.  Overall, I think it is safe to say the response
| has been very positive.  While I imagine some folks do forget to
| check their JunkMail folder, based upon some of the comments I've
| heard so far, it would seem that a fair number don't.

Why do you refer to a failure to check the junkmail folder as
"forget"?  I would think that is an intentional action on the
part of many.  I wouldn't be bothering with mine, except maybe
for regularly blindly deleting it.

But your situation is quite different because you aren't charging
people for each piece of mail.


| The other day I was about to get agitated because a user forwarded a
| bunch of spam (with full headers) and I thought they might do that
| for all the mail in their JunkMail folder.  Turns out they were
| either messages that SpamAssassin didn't tag, or the score was too
| low.  Upon further research I learned that this individual does
| indeed check the JunkMail folder on about a weekly basis.

What would this individual have chosen had they the choice to have
mail tagged as spam discarded or refused?  Would you even want to
allow that.  Would you want to send back a bounce message for that?
Or would you accept being in violation of RFC 2821 by letting mail
just disappear with no rejection of any kind?


| To be honest, no system is going to be perfect.  That's just fact
| of life, especially with such tenacious foes to contend with.
| While I imagine some would enjoy the ability to customize some of
| this tagging behavior, and I do plan on somewhat following
| developments along those lines, based upon what we've observed so
| far, I strongly suspect very, very few would opt to immediately
| reject the mail instead of utilizing the JunkMail folder.  At least
| in an EDU environment, folks get really touchy when it comes to
| systematically blocking things.  ;-)

I was about to say that being in an EDU environment, your requirements
are certainly different.  For one thing you aren't charging for mail
by the piece as far as I know.  Of course you might if you find some
student is receiving (and fetching) tens of thousands of large messages
a day which might be chunks of something not legal.

Were I in your situation, I probably would have something just like
what you have now.  It seems to be the right solution there.

In my plan, mail would be paid for by piece or size, after some agreed
minimum based on their service plan.  It's simple incremental pricing.
But to do that fairly, I also have to give end users control over how
the mail is not only filtered, but also how it is rejected.  They won't
pay for anything that is rejected (even though it still costs me some
portion just to take the SMTP connection and send back 550).

A small few extreme abusers will be layer 3 blocked and in those cases,
the users won't have a choice.  But that will only happen for cases
like SMTP attacks (which I have seen happen from 4 ISPs so far, of which
only one dealt with it and got unblocked).

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
-----------------------------------------------------------------




More information about the Info-cyrus mailing list