Rt-mailgate extension options and qmail

Rich_Lafferty · February 7, 2002, 6:56pm

Right now, --ticket-id-from-extension and --queue-from-extension
don’t work with qmail. This patch fixes that.

Those two options should probably be made mutually exclusive; this
patch doesn’t fix that.

(Attached.)

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

rt.diff (878 Bytes)

Jesse_Vincent · February 7, 2002, 7:03pm

It might be better if the code for finding out what the ENV{'EXTwhatever} got
pulled out into its own sub and then called once before we get into
the switching on options bit…

-jOn Thu, Feb 07, 2002 at 01:56:42PM -0500, Rich Lafferty wrote:

Right now, --ticket-id-from-extension and --queue-from-extension
don’t work with qmail. This patch fixes that.

Those two options should probably be made mutually exclusive; this
patch doesn’t fix that.

(Attached.)

-Rich

–
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

— rt-mailgate.old Thu Feb 7 13:12:26 2002
+++ rt-mailgate Thu Feb 7 13:50:05 2002
@@ -76,10 +76,22 @@
$Queue = shift @ARGV;
}
if ($flag eq ‘–ticket-id-from-extension’) {
  $TicketId = $ENV{'EXTENSION'};
   if (exists $ENV{'EXT'}) {  # qmail
       $TicketId = $ENV{'EXT4'} || $ENV{'EXT3'} ||
                   $ENV{'EXT2'} || $ENV{'EXT'};
}
   else { # postfix, others?
$TicketId = $ENV{'EXTENSION'};
   }
}
if ($flag eq ‘–queue-from-extension’) {
  $Queue = $ENV{'EXTENSION'};
   if (exists $ENV{'EXT'}) {  # qmail
       $Queue = $ENV{'EXT4'} || $ENV{'EXT3'} ||
                $ENV{'EXT2'} || $ENV{'EXT'};
}
   else { # postfix, others?
$Queue = $ENV{'EXTENSION'};
   }
}
if (($flag eq ‘-a’) or ($flag eq ‘–action’)) {
$Action = shift @ARGV;

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

Bruce_Campbell · February 7, 2002, 7:21pm

It might be better if the code for finding out what the ENV{'EXTwhatever} got
pulled out into its own sub and then called once before we get into
the switching on options bit…

Design fribble - should the mailer (and thus possible environment
variables) that rt-mailgate is called from be known to rt-mailgate.
Might help there.

I’ll just go crawl back under my rock and redesign whois shall I?

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Rich_Lafferty · February 7, 2002, 7:56pm

It might be better if the code for finding out what the
ENV{'EXTwhatever} got pulled out into its own sub and then called
once before we get into the switching on options bit…

I considered that, but figured it trivial enough to inline.

That whole section needs to be redesigned – making those options
mutually exclusive sort of beats the point, IMO. But then you run
into problems of queue-ticketnum vs ticketnum-queue and so on,
and different DASHes, and different MTAs, and so forth.

So, more generally, how do you see that working?

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

Jesse_Vincent · February 7, 2002, 8:11pm

Somewhat longer term, I see redoing the syntax as somethign on the order of

rt+queue=foo#owner=bar#id=baz

For now though, the dupicated special casing code makes me a bit uncomfortable.

-jOn Thu, Feb 07, 2002 at 02:56:33PM -0500, Rich Lafferty wrote:

On Thu, Feb 07, 2002 at 02:03:43PM -0500, Jesse Vincent (jesse@bestpractical.com) wrote:

It might be better if the code for finding out what the
ENV{'EXTwhatever} got pulled out into its own sub and then called
once before we get into the switching on options bit…

I considered that, but figured it trivial enough to inline.

That whole section needs to be redesigned – making those options
mutually exclusive sort of beats the point, IMO. But then you run
into problems of queue-ticketnum vs ticketnum-queue and so on,
and different DASHes, and different MTAs, and so forth.

So, more generally, how do you see that working?

-Rich

–
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

Rich_Lafferty · February 7, 2002, 9:37pm

Somewhat longer term, I see redoing the syntax as somethign on the order of

rt+queue=foo#owner=bar#id=baz

Perhaps we’re solving different problems. That reminds me of VERP,
which makes me think it’s intended to be machine-generated, while I
see it as a customer-visible convenience.

For example, for the queue-in-extension option, I see it as a way to
use a single alias to push mail into RT: set up the alias “support”
and “support-workstations” goes in one queue, “support-servers” to
another. But “support-queue=servers” isn’t how nontechnical users –
ie, support desk customers – think email works; email addresses don’t
usually take parameters, and “support-servers” hides the fact that
it’s a parameter.

For now though, the dupicated special casing code makes me a bit
uncomfortable.

Well, we’ve gone from undocumented mutually-clobbering MTA-specific
duplicated code to undocumented mutually-clobbering less-MTA-specific
duplicated code.

I’m going to leave this a works-for-me right now, because my priority
is getting RT in place here, and we needed that feature for a
translucent migration – but I don’t need it to work with postfix at
all, and I know the ticket number’s always in EXT2.

Once that priority’s out of the way, I’ll see about revisiting it with
a more general solution; but if our requirements are as far away from
yours as the syntax example above suggests, I think we’re implementing
entirely different ideas that happen to share code; specifically, I
think one of our historical requirements happened to resemble your
temporary implementation of a feature quite unlike ours.

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

Jesse_Vincent · February 7, 2002, 9:46pm

For example, for the queue-in-extension option, I see it as a way to
use a single alias to push mail into RT: set up the alias “support”
and “support-workstations” goes in one queue, “support-servers” to
another. But “support-queue=servers” isn’t how nontechnical users –
ie, support desk customers – think email works; email addresses don’t
usually take parameters, and “support-servers” hides the fact that
it’s a parameter.

nod That wasn’t how I was thinking about it, but your use case makes
plenty of sense. I think I like your answer better than mine

I’m going to leave this a works-for-me right now, because my priority
is getting RT in place here, and we needed that feature for a
translucent migration – but I don’t need it to work with postfix at
all, and I know the ticket number’s always in EXT2.

grin makes sense.

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

Rich_Lafferty1 · February 7, 2002, 9:44pm

Somewhat longer term, I see redoing the syntax as somethign on the order of

rt+queue=foo#owner=bar#id=baz

For now though, the dupicated special casing code makes me a bit
uncomfortable.

It also doesn’t work. Please ignore; since I have to fix it
again anyhow, I’ll get you a less-duplicative patch.

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

seph · February 8, 2002, 1:30am

For example, for the queue-in-extension option, I see it as a way to
use a single alias to push mail into RT: set up the alias “support”
and “support-workstations” goes in one queue, “support-servers” to
another. But “support-queue=servers” isn’t how nontechnical users –
ie, support desk customers – think email works; email addresses don’t
usually take parameters, and “support-servers” hides the fact that
it’s a parameter.

when I was confronted with this, I decided that what was right for
users, would never be correct programaticly. different syntaxs make
sense for different queues.

So I have my rt server accepting unweildly machine syntax, and my
mailing server has aliases from nice things to scary things. (see the
scary exim hack in the docs)

Not perfect, but it’s the balance that worked for me.

seph