Mail Encoding Problem

RT Users
1

Hi all,

we are using rt-2.0.13 on a OpenBSD machine with sendmail.

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.

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?

tnx Pitz

2

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?

Just put

Content-Type: text/plain; charset=“iso-8859-1”

at the beginning of your templates.

Sebastian

Sebastian Flothow
sebastian@flothow.de
#include <stddisclaimer.h>

3

Hi all,

we are using rt-2.0.13 on a OpenBSD machine with sendmail.

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.

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?

tnx Pitz
The ultimate metric that I would like to propose for user friendliness
is quite simple:
if this system was a person, how long would it take before you
punched it in the nose? – Tom Carey

4

Hi all,

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
    default.

  • 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 …

Smylers
GBdirect