Courier-MTA (http://www.courier-mta.org) is a complete email system
that my employer uses for corporate mailing. It includes a package
called sqwebmail, a web-based email client that we have installed so
that employees can access their emails when they are out of office/slow
internet connection.
Sqwebmail, when replying to a mail, removes [[^]]*] (hope I got that
correct from the Subject: header. The reasoning is that […] is
used only by mailing lists; hence when replied if the reply goes back
to the mailing list the mailing list software restores the tag anyway,
and if the reply goes back to the sender the tag is nonexistent.
When I asked on courier-users whether this behaviour was configurable,
this is what I got:
It is not wise for "ticketing systems" to mimic behavior that's been
used by mailing list processord for a long time before those "ticketign
systems" were invented.
Is the usage of square brackets configurable in RT? (I have about a
thousand tickets now, so even if it is, its going to be hard changing
all of them, plus the extra user education).
BTW, not just RT, but many CRM packages use […] to track tickets.
I don’t think any RFC or other standard reserves that tag for mailing
lists - or is it?
When I asked on courier-users whether this behaviour was
configurable, this is what I got:
It is not wise for "ticketing systems" to mimic behavior that's
been used by mailing list processord for a long time before
those "ticketign systems" were invented.
This statement is AFAIK false, and certainly arrogant (what
if the user puts something in square brackets? What if the
user is Swedish and the square brackets are not really square
brackets? Are humans not allowed to use square brackets in
Subject?). AFAIK, mailing lists only started using square
brackets in 1996 or so (and then the “square bracket convention”
was not even established; different lists used different formats
for tags, a lot did not use “square brackets”).
Even if RT really dates back only to 1996 (the author of the
“Call Center, Bug Tracking and Project Management Tools for
Linux” page claimed that RT actually dates back to before 1995),
it already used square brackets back then (RT 1.0.0), when the
“square brackets” convention for mailing lists was still not
firmly established.
For a more concrete counterexample, we can dig up Req 1.1,
dating back to 1994 and it also already used square brackets.
AFAIK, mailing lists did not even use any tags back in 1994.
If RT 1.0.0 cannot refute the false claim that ticketing systems
using square brackets for ticket numbers are invented “after”
mailing lists’ use of square brackets for tags, surely Req
1.1 (with its ancient 1994 date) can completely refute such
false claims. If I am not wrong in my dating (when mailing lists
started using tags), the evidence shows that mailing lists
started mimicking the behaviour of ticketing systems which were
then in existence, not the other way round as falsely claimed.
Sqwebmail, when replying to a mail, removes [[^]]*] (hope I
got that correct from the Subject: header. The reasoning is
that […] is used only by mailing lists; hence when replied
if the reply goes back to the mailing list the mailing list
software restores the tag anyway, and if the reply goes back to
the sender the tag is nonexistent.
I dug through my old mails to see what kinds of mails have square
brackets in the Subject header. This is what I find (in chronological
order):
Things that people typed manually ([Q], [official], [members],
[PATCH], [SUM], [SUMMARY], [for FIOGETOWN], [Windows 95], etc.)
Newsgroup voting results
Forwarded mails (pine, mutt, ancient versions of Netscape, etc.)
Parts of proper names (e.g., typo[media] 98)
Mailing list traffic (but not before 1996, as I mentioned in
my other reply)
Ticketing systems (Bugzilla, SourceForge, RT [of course], and
some unknown ticketing system used by the ESNIC)
I would say if Sqwebmail removes all [[^]]*] in Subject, it
will definitely confuse users if they do (1) or (3) (especially
for the pathetic case of the sender user agent being, e.g.,
mutt, where the entire Subject line would disappear; obviously
the Sqwebmail user will not be very happy), or if they encounter
(4).
In any case, this clearly shows that the “[…] is used only by
mailing lists” reasoning is presumptious and entirely unfounded.
(It might be interesting to see what Sqwebmail will do when the
Subject line contains ISO-2022 or Big5 multi-byte characters
that look like they have […] in them; most webmail packages
I have seen act pretty badly when fed Chinese/Japanese mails;
perhaps I should get a copy of Courier just to see what it will
do )-:
It is not wise for "ticketing systems" to mimic behavior that's been
used by mailing list processord for a long time before those "ticketign
systems" were invented.
Is the usage of square brackets configurable in RT? (I have about a
thousand tickets now, so even if it is, its going to be hard changing
all of them, plus the extra user education).
As Ambrose noted, that answer wasn’t polite enough, and false.
As for other CRM systems, I’d like to note Cisco TAC. They use
something like
/Case\s+[A-Z][0-9]{6}/
for their mail filtering.
So, maybe the tunable format of the subject line would be nice
feature.
As for other CRM systems, I’d like to note Cisco TAC. They use
something like
/Case\s+[A-Z][0-9]{6}/
for their mail filtering.
So, maybe the tunable format of the subject line would be nice
feature.
I think my bank (ICICI Bank) uses Siebel, and the tag is:
{ICICICARE#nnn-nnn-nnn}
For the first autoreply, and minus the for subsequent replies.
All the n’s are digits.
Minus the frills, I think RT2 should allow the characters used to format
the tag to be of user’s choice. {…}, <…> and (…) all should be
allowed to be used.
In fact, a printf-like format string for the tag would be a cool idea
$rttag = “[%r #%t]”;
with %r for $rtname and %t for ticket number would get us the current
tag. The above of course, should be dumped pretty low on the wishlist.
In fact, a printf-like format string for the tag would be a cool idea
The problem is not the generation of these strings, but the extraction
of the ticket ID from subject strings in incoming replies. You can
easily shoot yourself in the foot if your regexp (or another
mechanism) extracts another party’s tracking number…
Better use ticket-specific email addresses. Much less trouble.
The problem is not the generation of these strings, but the
extraction of the ticket ID from subject strings in incoming
replies. You can easily shoot yourself in the foot if your
regexp (or another mechanism) extracts another party’s tracking
number…
Better use ticket-specific email addresses. Much less trouble.
Ah, but ticket-specific email addresses would mean having to
hack crossbar.cf, or is it aliases.cf, or is it some other zmsh
script? I don’t even have a clue
Better use ticket-specific email addresses. Much less trouble.
Ah, but ticket-specific email addresses would mean having to
hack crossbar.cf, or is it aliases.cf, or is it some other zmsh
script? I don’t even have a clue
nah, it’s much easier than that. At a very simple level, you could use
a domain for your tickets (ticketnum@tickets.example.com). The major
MTAs should handle this. If you really didn’t want to, it’s pretty
easy to get the major MTAs to send everything matching a simple
pattern to a host (ticket+ticketnum@example.com)
Ah, but ticket-specific email addresses would mean having to
hack crossbar.cf, or is it aliases.cf, or is it some other
zmsh script? I don’t even have a clue
nah, it’s much easier than that. At a very simple
level, you could use a domain for your tickets
(ticketnum@tickets.example.com). The major MTAs should handle
this. If you really didn’t want to, it’s pretty easy to get the
major MTAs to send everything matching a simple pattern to a
host (ticket+ticketnum@example.com)
Ah, for my MTA I really have to hack some, and I found that the
file to hack is aliases.cf, though the hacking is much easier
than I thought.
The hack is basically finished; I’ll post it after I make sure
it works exactly the way I want it to work.
from the Subject: header. The reasoning is that […] is