I realize the above is a very old message. This was one of those Jesse
found lurking in the awaiting-authorization bucket last week. I’d’ve
responded then if I had a quick solution for Pitz (but since I don’t I
thought a few more days won’t matter …)
Till now we are satisfied with this TT-System, except with the mail
encoding in outgoing mails. We are in germany and we have some special
characters (i.e. äöüß äöüß). And any
text send via mail to RT or typed in in the webinterface gets corrupt
when mailed from RT.
This is something which is slightly concerning us too. Fortunately we
rarely need special characters (the odd sterling symbol, perhaps) so
have been quietly ignoring it.
I think the problem is the “Content-Type:”-line in the mailheader.
RT uses only “Content-Type: TEXT/PLAIN"
but it should be
"Content-Type: text/plain; charset=iso-8859-1”
Is it possible to add this charset to outgoing mails?
It’s easy to add any headers to outgoing mails by specifying them in
templates. I was on my way to do that when I realized it isn’t good
enough (so I didn’t, and embarked on my policy of ignoring it instead).
If you send a mail from your mailer in Latin1 then ‘RT’ adding the
above header on all mails will make that work correctly.
But what if an external requestor mails in using a different
charset? In order for you to be able to interpret her/his mail
you’d want the charset header of the requestor to be added, not your
Which charset is used for messages entered in the web interface?
Presumably it should be set to whatever the user’s browser is using,
which I think is supplied in an HTTP header.
If you solved the above so that the charset was based on that of the
message that provoked the current action, you’d have to make sure
that any ‘standard’ text being added by templates was in (a subset
of) that charset – you can’t use any umlouts in there because the
mail to which that message is being prepended might be in a charset
that doesn’t have them.
In practice Ascii would probably be OK. But if part of your
boilerplate includes things like the ticket subjects you’d have to
restrict those to being Ascii as well.
While investigating this I noticed that the Users table has fields Lang,
EmailEncoding and WebEncoding, which don’t seem to be used for anything
anywhere. There’s a few Mason elements which refer to them, but they in
turn don’t appear to be used in any pages[*0]. I’m wondering if they
could be intended to solve this.
[*0] But I’m still on version 2.0.13, so the above may be wrong in the
latest version. It’s just dawned on me why I didn’t send this last week
– I was on sending it after this afternoon’s upgrade so as to check
that. Oh well …