[sork] the sork conglomerate

[Eric Rostetter]

Quoting Tim Gorter <email@teletechnics.com>:

> It seems to me that we are certainly wanting to head in the same direction,
> as I think we both are talking about server side operations. At least as
> you mentioned that the tasks we are talking about should be server side
> rather than client side.

Yes.

> If you don't mind, I definitely want to proceed, as this is one of the few
> things holding me up in placing Horde2.0/IMP3.0 into full production, which
> I want to do soonest. If there is anything I should keep in mind, let me
> know.

Already done with the changes I wanted to make, so go ahead and start
your additions.
 
> In my application it certainly has to be user specific.

Great, I'd prefer that!

> Depending on the O/S and local mail agent setup, one may (or may not) need
> .forward to invoke procmail. If we are to make the module for all, I'd
> say we have to address both situations. Although I will start with the
> 'without' option first. It being the way my server is set up.

Yes, start with the "without .forward" approach, and simply document how
to setup the .forward file to call procmail if needed.  (My system also
calls procmail automatically without use of a .forward file)

> Yes, I prefer this kind of filtering to be done server side, the reason I
> am following this path. And anyway, I think the filtering with IMP is of
> different sorts, where here am more looking at those functions that should
> happen automatically in user absence. Of course what these include is
> always up to debate.

Yes.  I'm not against a filtering module.  But I want to control what it
filters, and how rules are setup.  And it should be an individual account
filtering module, not a system wide one.

> Then again via procmail letting a user decide if he wants
> 1. All email, no filtering, or further action.
> 2. filtered to folder of suspect email
> 3. delete all suspect email.
> fairly simple, no great user settings, a choice of 3 recipes, and again,
> everything happens server-side.

We'll have to discuss this more (on the list, with others, etc). Also,
I don't know much about SAM either, so we need to check up on SAM to
make sure we're not duplicating efforts...

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

"TAD (Technology Attachment Disorder) is an unshakable, impractical devotion
to a brand, platform, product line, or programming language. It's relatively
harmless among the rank and file, but when management is afflicted the damage
can be measured in dollars. It's also contagious -- someone with sufficient
political clout can infect an entire organization."

--"Enterprise Strategies" columnist Tom Yager.