Kevin,<br><br>Obviously, I could be wrong, but I thought "<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 11"><meta name="Originator" content="Microsoft Word 11"><link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CKFCROC%7E1%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml"><style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style><b style=""><span style="font-size: 12pt; font-family: "Times New Roman";">Set($MessageBoxIncludeSignature, 1);</span></b>" was to allow the passing along of the v-card in a reply.<br><br>As to your suggestion on using a group filter, I had first thought of that, but my problem is that these "signiture card users" exist sporadically throughout several groups that correspond on RT tickets involving Human Resources and Payroll requests. The HAVE to use RT and they send out too much email everywhere else using their signiture cards for me to ask them to turn it off just when corresponding to email to/from RT. It would get too confusing and inevitably someone would forget and then we get another error situation. I was hoping it would be a <i>simple</i> patch to examine the email for a v-card and simply ignore/bypass it just like it does a regular email with no CBM commands. If not, then we will just have to deal with it. It just looks bad from the Users perspective (you know how they don't understand when you tell them it's part of the system ;-).<br>
<br>Anyway, at least I know where it's coming from. Not knowing for me is like watching a movie (I'm an AVID movie watcher) with no plot (he he).<br><br>Thanks for your time and consideration on this.<br><br>Kenn<br>
LBNL <br><br><div class="gmail_quote">On Fri, Aug 20, 2010 at 10:22 AM, Kevin Falcone <span dir="ltr"><<a href="mailto:falcone@bestpractical.com">falcone@bestpractical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Fri, Aug 20, 2010 at 09:08:47AM -0700, Kenneth Crocker wrote:<br>
> I know that RT has a configuration that allows one to include v-cards in replies.<br>
<br>
</div>It does?<br>
<div class="im"><br>
> That alone<br>
> implies that RT has no problem with v-cards coming in with an email. However, since we<br>
> installed "CommandByMail" we occasionally get a set of error messages like below:<br>
><br>
> Failed command 'version: 2.1'<br>
> Error message: Command 'version' is unknown<br>
><br>
> Failed command 'end: vcard'<br>
> Error message: Command 'end' is unknown<br>
><br>
> I was wondering if anyone knew of a command or configuration or any setting in CommandByMail<br>
> or TakeAction that would resolve this issue?<br>
><br>
> Has anyone else run into this problem?<br>
><br>
> I only have a few customers that do this, but because they are in a highly sensitive area,<br>
> they always include signitures on their email and I can't ask them to stop it just for RT.<br>
<br>
</div>Might I suggest the $CommandByMailGroup config option that limits use<br>
of the plugin to a single group of power users?<br>
<font color="#888888"><br>
-kevin<br>
</font><br><br>
RT Training in Washington DC, USA on Oct 25 & 26 2010<br>
Last one this year -- Learn how to get the most out of RT!<br></blockquote></div><br>