[sork] the sork conglomerate

[Tim Gorter]

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.

Sunday, July 21, 2002, 10:53:11 PM, you () wrote:
ER> Quoting Tim Gorter <email@teletechnics.com>:

>> A few problems I have that I want to resolve include.
>> using .forward file for forwards.
>> I want to transfer this function to procmail, as this allows a lot more
>> flexibility, multiple forwards if needed, some filtering if wanted.

ER> We do want to make a procmail version or two.  Your help is appreciated.
ER> If you can wait a bit, you may want to wait until I reorganize the forwards
ER> module (ala the passwd module) to use a Drivers class setup.  But you don't
ER> have to wait if you don't want, as we can simply change it to the new format
ER> afterwords (without any real problems).

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.

ER> Question is which method(s) of procmail you want to use.  My greatest concern
ER> would be one that operates just like the .forward version -- it puts the
ER> procmail file into each user's home directory.  There are others who want
ER> all rules put into one file (e.g. /etc/procmailrc) and others who have a
ER> setup where procmail files goes elsewhere, but one per user (so each file
ER> might be, e.g. /var/procmail/$USER for each user).  So which one or more
ER> of these would you be interested in?

In my application it certainly has to be user specific. /etc/procmailrc is
as far as I understand server wide only, and it has to be in individual
user folders for it to be user specific. Although you mention an
alternative location (/var/procmail/$USER) which I cannot find any further
documentation about. This would be my preference as I'd rather keep it out
of individual users tampering range. In essence which path one goes down
though should probably be a configuration issue, and thus changeable (by
inserting the path to the rc in the config file) but again without knowing
more about the /var/procmail/$user option I cannot say how simple this is.
But I presume the issue of tampering is the same with the .forward file,
although this is more difficult to resolve.

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.

ER> As for as filtering, this would be redundent with the filtering in IMP 
ER> already, but I'd still be interested in adding a real well done filtering
ER> module, since filtering is best done by the server and not the client.

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.

ER> BTW, .forward allows for multiple forwards...

until I saw your module I didn't even know it would allow a copy to remain
on the server! shows how much more there is to learn.

>> I know there is a separate group starting on the SAM module for SpamAssasin
>> integration. Again I want to pull this under the one hat, as in end effect
>> it has to do with mail filtering that can be done via procmail.

ER> I don't see any reason to move SAM or any functionality of SAM into our
ER> modules.  SAM is a bit different in goals and design that what I would
ER> want in sork.  But I'm willing to have a simple filtering module added
ER> to sork (filter based on header/content/size/etc as a server function
ER> rather than a client function).

I have not quite figured how the SAM module is to work within IMP, but the
way I see it, there are two methods to invoke SpamAssassin, on a user level
and on server-wide level.

The primary way (for starters) I was looking at is that SpamAssasin is
invoked server-wide, so that all email has a header added when it is
suspect.

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.

>> now I am not a super programmer, nor am I familiar with the CVS repository
>> system. So at the moment I look forward to the help of you guys, and if you
>> have already something in this direction, it would be nice to talk to you.

ER> Talk away.  Most of what you want has already been discussed, requested,
ER> and or added to the todo list.  But some (like filtering) is new.  procmail
ER> backends for the modules are very much desired, so your efforts would be
ER> greatly appreciated.

what's that great line, something like - all great talk - and now the
action...

ER> You don't have to be a great coder -- I can clean up the code you submit
ER> if it isn't up to specs.  But code/patches certainly would speed up 
ER> development...

Thanks for the support, I appreciate (and will probably take you up on)
your offer.

regards,
tim.