Re: [exim] help in setting up filters

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Noel Martin Llevares
Dátum:  
Címzett: Noel Martin Llevares, exim-users
Tárgy: Re: [exim] help in setting up filters
Thanks for the support, Phil.

Regarding your suggestions, it seems to be an overkill for us to do that. I
have used a helpdesk/ticketing system before (OTRS) and it doesn't really
fit what we want to be done.

Right now, I'm simply thinking of doing the following:

   - Create user filter for each agent.
      - Each outgoing email will be FORWARDED to a QA account. => This is
      easy in cPanel, I think.
      - This email should NOT be delivered to the client yet. => This part,
      I don't know how to make the filter yet.
   - QA staff needs to review the email (make corrections,edits,etc.).
      - QA staff should be able to send the email to the client *on behalf *of
      the original sender. => This part I also don't know how to do.
Gmail can do
      this. Many email servers also allow this. What do I need to do
with Exim so
      that the QA account can send an email as *someone else*? Or, is this
      simply a matter of the changing the "From:" and "Reply-To:" headers?


Thanks for the responses so far.

Noel Martin L.

On Mon, Apr 9, 2012 at 6:36 PM, Phil Pennock <pdp@???> wrote:

> On 2012-04-08 at 13:19 +0800, Noel Martin Llevares wrote:
> >    1. My boss wants to set up our email system such that all outgoing
> >    emails coming from our agents to our clients will pass through a
> >    "moderation queue" before being actually sent to the client.
> >    2. The "moderator" should be able read, review, edit, and send the
> >    messages from the "moderation queue" to the client.
> >    3. The client should see the email as coming from the original sender
> >    (the agent) NOT the moderator.

> >
> > I have been reading the docs from Exim.org and searched for "Exim filters
> > tutorial" from Google but still I can't make it do what I want. I am a
> > developer with no experience with administering mail servers.
>
> To do this, you'd need to:
> * come up with criteria to identify the mails in question;
> * write a Router which accepts mails for the recipients but, when not
> coming from the approval queue, instead delivers the mails to the
> holding system;
> * write the holding system, which includes ability to edit, and to
> re-inject the mail;
> * make sure that these re-injected mails do not match the rules needed
> for the Router mentioned above; eg, source IP for mail-server
> connection, or added message-header (which you can strip off again
> before delivery).
>
> Each Router is tried in turn.
>
> Using an email client with an IMAP/POP store for the holding system is
> going to create many problems, because email clients add trace
> information. You'd be better off writing your own web-based dispatch
> software.
>
> There are a number of pre-built solutions for this sort of helpdesk
> ticketing system, including roles, rules matching people in various
> roles, etc, so that you have have senior staff approve the responses of
> junior staff for a trial period, etc. I've never run such a system
> myself, so can't *recommend* one in particular. I can mention names and
> point for further investigation, including whether they actually support
> post-editing.
>
> You don't say if these clients are external customers or internal folks
> for whom you're a helpdesk.
>
> The "nobody ever got fired for buying IBM" solution is probably Remedy.
> I believe (but am not certain) that it's Windows software.
>
> The classic IT helpdesk software is Request Tracker, RT, written in
> Perl. It's geared for email-based management. The other main open
> source solution I see mentioned is OTRS.
>
> Beyond those three, there are many helpdesk ticketing solutions
> available, including cloud-based, internally hosted, and more. The
> "Cerberus" one ... I think the name is familiar, don't recall who I know
> that was using it.
>
> Beware that there's "Issue Tracking" and "Helpdesk software" and there's
> some overlap between the two; if you're dealing mostly with internal
> customers, then the benefits of using one system for both may outweigh
> the slight ugliness of systems designed mostly around web UIs which
> expect accounts for each person accessing them. Take a look at:
> http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
>
> On the more commercial side, I know folks who swear by Atlassian
> products (Jira for issue tracking) and the integration (Crowd) and how
> wonderful they are; I know people who swear *at* those products instead.
> They're Java based. The Apache project uses Jira (it's free for
> non-commercial use).
>
> -Phil
>