i have two very major issues with the way the subject
of incoming email messages is parsed/handled:

(1) if there is a 10 year old issue with subject "XYZ"
and a new mail with subject "XYZ" comes in, it reopens
that old and probably unrelated issue.
It isn't so hard in a specific environment for users to
open issues with rather generic & useless subjects
which are eventually reused over time.  (This is
especially true when they reply to automated mail
messages which carry a static subject.)

While i understand the desire to handle:
  UserA sends mail to roundup & UserB w/ subject "ABC"
  UserB group replies w/ subject "Re: ABC"
In that very particular case, yes, it is good of
roundup to lump the two mails in the same issue, but
it's done by guessing which lacks precision.

i'd rather lose this nicety than have it in its current
form.

(2) mails sent to roundup cannot contain [ABC] in
subject.  I'm not sure how this should be dealt with,
but it's very furstrating (especially for new issues
being submitted) to get rejections such as:
The class name you identified in the subject line
("host.foo.bar") does not exist in the
database.

Valid class names are: category, file, issue, keyword,
msg, priority, query, status, user
Subject was: "[host.foo.bar] test"

i cannot control the format of all subjects, and the
current scheme used by roundup to receive commands
really gets in the way a times.

Logged In: YES 
user_id=6405

It appears that one man's "severly flawed" is another's "required 
feature". 
 
If you were to supply a patch to allow (via configuration) turning 
off of subject matching, command parsing, and error detection 
in class identification, it would have a very good chance for 
inclusion in the Roundup distribution. 
 
Reassigning this as a feature request, with appropriate subject. 
 

Logged In: YES 
user_id=469548

Well, I wouldn't call this "severely flawed", but I can say
we've been running into problem number 2 quite a few times.
We've got quite a few 'mutt' users and the standard
formatting for subject lines of forwarded emails is 
[<author>: <oldsubject>]. We've also got a support tracker
running, but people send their support requests to the
strangest places, so we end up forwarding emails to the
support tracker quite a bit. All mutt-users have now changed
their 'forward_format' variable, but it's still irritating:
try forwarding an email you got from a mailinglist (for
example: [staff]).

That said, I'm not sure I would turn on a configuration
turning off all subject matching, command parsing, etc.
Those are pretty useful features, after all. I'd rather find
a less intrusive way of specifying
classes/identifying/setting attributes, though I haven't got
a proposal as to what that less intrusive way should be.

This has been implemented for some time now with the following
config.ini configuration options:
- subject_content_match can be configured to match incoming subjects only
  for a certain time (after either *creation* of an issue or the last
  *activity* of an issue) you can also turn it off completely.
- subject_suffix_parsing can be set to 'loose' and will not raise errors
  if the subject contains a leading [ABC] in the subject.