=?UNKNOWN?Q? in the subject
Hi all,
an email was sent using an internet service (X-Mailer: TOL Mailer) to users of different domains. One of these domains is managed with a Messaging Servers, the other runs postfix. The user of Messaging server domains receives the message with the UNKNOWN coding in the subject:
(from the message source) Subject: =?UNKNOWN?Q?Itinerario=A0Da?= Cottanello A Contigliano
The account on the other domain, however, receives the message with the normal subject
Subject: Itinerario Da Cottanello A Contigliano
So I must exclude that the problem is the mailer.
Moreover, the MS domain has been recently migrated from a Microsoft system, and this problem, which is not limited to emails sent from that particular internet service, did not occour before the migration.
Any ideas on why this could happen?
# 1
Hi,
Please when asking questions always provide the version of messaging server (./imsimta version).
> an email was sent using an internet service
> (X-Mailer: TOL Mailer) to users of different domains.
> One of these domains is managed with a Messaging
> Servers, the other runs postfix. The user of
> Messaging server domains receives the message with
> the UNKNOWN coding in the subject:
>
>
> (from the message source) Subject:
> =?UNKNOWN?Q?Itinerario=A0Da?= Cottanello A
> Contigliano
>
> The account on the other domain, however, receives
> the message with the normal subject
>
> Subject: Itinerario Da Cottanello A Contigliano
>
> So I must exclude that the problem is the mailer.
I wouldn't jump to that conclusion.
Messaging server is very particular about enforcing RFC's. If you are seeing 'UNKNOWN' in the subject line then there was an invalid character (non 7bit) so the subject was encoded. It appears messaging server didn't like the character between "Itinerario" and "Da"
How other MTA's behave under that situation differs e.g. they may just discard the invalid characters or they may just pass the invalidly formatted email onto the next hop (garbage-in-garbage-out).
> Moreover, the MS domain has been recently migrated
> from a Microsoft system, and this problem, which is
> not limited to emails sent from that particular
> internet service, did not occour before the
> migration.
I wouldn't use Microsoft as any kind of guide as to the correct behavior with regards to the handling of email.
> Any ideas on why this could happen?
Explained already.
Do you find that ALL emails from this internet service experience the problem or just some emails? Any particular pattern?
Regards,
Shane.
# 3
Hi,
> I have the same problem - eight bit in the headers.
> Is there any possibility to transfer eight bit header
> without any mime encoding?
Refer here to your list of options - passing through unencoded isn't one of them.
http://lists.balius.com/pipermail/info-ims-archive/2006-December/027144.html
> I know this id wrong according to the rfc regulation.
> But I would prefer to get
> wrong header untouched.
Better to get the source of the emails fixed.
Regards,
Shane.
