MAILBEE POP3 SMTP WEBMAIL IMAP4 POP IMAP EMAIL COMPONENT VB ASP ACTIVEX COM VBA OCX NET .NET C# VB.NET ASP.NET DOWNLOAD QUEUE SSL SECURITY CENSOR ACCESS PARSER C++ DLL CONTROL LIBRARY MIME INTERFACE

MailBee POP3

AfterLogic Forum : MailBee POP3

Topic: Message objects - strange behaviour

Author

Message

<< Prev Topic | Next Topic >>

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 15 February 2008 at 4:14pm \| IP Logged

Hello,

My application acts as a mail proxy. It fetches emails from a POP3 server and saves them to the HDD. Then a POP3 server in my application gets the email message saved on HDD and delivers to the local mail client.

Everything works perfect untill I modify the email message some way before saving to the HDD.

An example of correct behaviour:

1) retrieve POP3 email message to the Message object
2) save the message to EML using SaveMessage()

Strange things start to happen if I decide to modify the message some way, e.g. add something in the subject line. Actions that cause incorrect behaviour are:

1) retrieve POP3 email message to the Message object
2) modify the Message object subject property
3) save the message to EML using SaveMessage()

And what's the strange behaviour, you ask? Well... the only difference between these two output EML files in this two examples should be only the subject line (let's assume the subject change doesn't contain any special characters, just ASCII chars). The subject is of course changed, but not only. There is a big difference in the mail headers. Below are two examples of headers for the example 1 and the example 2.

1st Example headers (correct, as received)

Code:

X-From_: user1@sampledomain1 Sat Feb 16 00:21:05 2008

Return-Path: <user1@sampledomain1>

Delivered-To: user_2@sampledomain_2

Date: Fri, 15 Feb 2008 23:21:05 -0000

Message-ID: <20080215232105.88244.qmail@domain_3>

To: user_2@sampledomain_2

Subject: Some Subject

From: <user_3@sampledomain_3>

MIME-Version: 1.0

Content-Type: text/plain; charset=iso-8859-2

Content-Transfer-Encoding: 8bit

2nd Example headers (incorrect, as saved after the subject change)

Code:

Return-Path: <user1@sampledomain1>

MIME-Version: 1.0

From: user1@sampledomain1

To: user_2@sampledomain_2

Subject: [MODIFIER] Some Subject

Content-Type: multipart/related;

     type="multipart/alternative";

      boundary="----=_NextPart_001_7 2AE_69525F90.16496DF1"

Date: Fri, 15 Feb 2008 23:21:05 -0000

Message-ID: <2736587215202328116827@Komputer_Rafala>

X-From_: user1@sampledomain1 Fri Feb 15 23:21:05 2008

Delivered-To: user_2@sampledomain_2

Why this happens? Please try a simple task:

Code:

FMessageToSend2 := TMessage.Create(nil);

FMessageToSend2.Locked := false;

FMessageToSend2.ImportFromFile('exisitingfile.eml');

FMessageToSend2.SaveMessage(tmpfilename1EML);

FMessageToSend2.Subject := '[MODIFIER] ' + FMessageToSend2.Subject;

FMessageToSend2.SaveMessage(tmpfilename2EML);

FMessageToSend2.free;

Now compare the tmpfilename1.EML and tmpfilename2.EML and you'll see the difference. Is there any way to have both the EML files the unchanged (except the subject)?

Cheers,R
Rafal

Andrew
AfterLogic Support

Joined: 28 April 2006
Location: United States
Online Status: Offline
Posts: 1189

Posted: 16 February 2008 at 1:57am \| IP Logged

Actually, each parsed e-mail message can be built back in some ways and user won't notice any visual changes, however, MIME source of these messages can significantly differ. None of e-mail parsers would build fully parsed messages in exactly original view because each parser has its own build algorithm.

However, if you need to modify just headers, Message.MinimalRebuild property should be useful for you.

Best regards,
Andrew

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 16 February 2008 at 11:33am \| IP Logged

Thanks a lot! This works, at least partialy. I've used the following code to modify the subject and to keep the message as received:

Code:

aMsg.MinimalRebuild := True; 

aMsg.Locked := false;

asubject := '[MODIFIER] ' + aMsg.Subject;

aMsg.RemoveHeader('Subject');

aMsg.AddHeader('Subject', subject);

It works ok. All headers and message encoding remains the same. The problem is however the encoding of the new Subject header. It seems that amsg.Subject is decoded depending on the CodePageMode and if I add it to the original message headers, it is not encoded properly according to the original encoding. I've tried the EncodeHeaderText() method but with no successful results. I use:

Code:

asubject := aMsg.EncodeHeaderText('Subject', '[MODIFIER] ' + aMsg.Subject, aMsg.CharsetOriginal, aMsg.bodyEncoding);

And when the message is in my mailer client inbox I can notice that the Subject is encoded inproperly. Is there some way to keep the new Subject encoding the same as the original message?

Cheers,
Rafal

Andrew
AfterLogic Support

Joined: 28 April 2006
Location: United States
Online Status: Offline
Posts: 1189

Posted: 18 February 2008 at 5:16am \| IP Logged

This happens because EncodeHeaderText method doesn't perform actual converting header charset, it just encodes headers to QP or Base64.

You should additionally convert header charset before encoding. This can be done via ConvertCharset method:

Code:

aMsg.EncodeHeaderText("Subject", aMsg.ConvertCharset("[MODIFIER] " & aMsg.Subject, "", aMsg.CharsetOriginal), aMsg.CharsetOriginal, 2)

Also, it's not a good idea to use aMsg.bodyEncoding because it may be equal to 0 or 1, but EncodeHeaderText won't work with these encodings properly.

Best regards,
Andrew

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 18 February 2008 at 2:30pm \| IP Logged

Thanks Andy. It works.

By the way (another question), I've noticed that some Outlook Express emails have this header:

Code:

Content-Type: text/plain;

        charset="iso-8859-1"

When I use the Message object and load such a message to it, then the CONTENTTYPE property contains 'text/plain; charset="iso-8859-1"' instead of the only 'text/plain'. The CHARSET property is empty in this case. I think there's might be some issue regarding the message parsing. Please check this out. Thank you.

Rafal

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 18 February 2008 at 2:53pm \| IP Logged

Hello,

I've written that this works, but not always...

Andrew wrote:

You should additionally convert header charset before encoding. This can be done via ConvertCharset method:

I've just received such a spam:

Code:

Content-Type: text/plain;

        charset="us-ascii"

Content-Transfer-Encoding: 7bit

Subject: business credit cards for bad credit

So, we have nothing special here to encode. However if I call the EncodeHeaderText() method together with the ConvertCharset() method I receive such a new header:

Code:

Content-Type: text/plain;charset="us-ascii"

Content-Transfer-Encoding: 7bit

Subject: =?us-ascii?Q?[MODIFIER]_business_credit_cards_for_bad_?=

     =?us-ascii?Q?credit?=

My questions are:

1) Could there be no charset information in the subject? In my case it is always the same as the message charset and in this particular case, there's no need to encode anything.

2) The "Content-Type:" header field has been changed dispite the MinimalRebuild has been set to TRUE and I've removed and added only the Subject field. Why? I'd like to keep the EML exactly the same except the subject field.

Cheers,
Rafal

Andrew
AfterLogic Support

Joined: 28 April 2006
Location: United States
Online Status: Offline
Posts: 1189

Posted: 19 February 2008 at 6:18am \| IP Logged

Quote:

This is by our design and described in the documentation. If you need to learn message type, you may use Message.BodyFormat property or split ContentType by semicolon.

Quote:

1) Could there be no charset information in the subject? In my case it is always the same as the message charset and in this particular case, there's no need to encode anything.

Actually, EncodeHeaderText() method doesn't check if header contains non-latin characters which need to be encoded. However, header may have special characters which should be encoded and, moreover, long headers may cause various problems with some mail servers, but EncodeHeaderText() method splits long header to some short lines. Over-encoding doesn't affect messages negatively, except it a bit increases their size.

Quote:

2) The "Content-Type:" header field has been changed dispite the MinimalRebuild has been set to TRUE and I've removed and added only the Subject field. Why? I'd like to keep the EML exactly the same except the subject field.

MinimalRebuild means modifying message headers only. It assumes keeping headers content intact, but doesn't assume keeping their original formatting. If messages with the same content are composed with different formatting, but according to MIME standard, they'll look equally for end-user and doesn't matter if their internal formatting differs. Both the versions of Content-Type formatting fulfill MIME standard.

Best regards,
Andrew

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 19 February 2008 at 1:35pm \| IP Logged

Quote:

I've changed my method to use EncodeHeaderText() only if the subject line is longer than the standard 76 chars. However I have to disagree that over-encoding doesn't affect messages negatively. I've received today a few spam messages which subject is unreadable after the EncodeHeaderText method. One of them had the subject like this:

Subject: Ulead DVD PictureShow 4.0©ç©çżN-Hy

After the EncodeHeaderText() method the subject looks like this:

Subject: =??Q?[MODIFIER]_Ulead_DVD_PictureShow_4.0=A9=E7=A9=E7=BFN-Hy?=

And my Thunderbird client shows the encoded subject line as a single "?" character and a correct subject (Ulead DVD PictureShow 4.0) when no encoding is used.

This happens often... However when I decided to encode headers only if they are longer than 76 chars, this problem almost not exists.

Thank you for the rest of your reply and kind support.

Cheers,
Rafal

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 19 February 2008 at 1:43pm \| IP Logged

By the way, I've just got an email with such a header:

Code:

text/plain; charset=unicode-1-1-utf-7

The subject line in this email was longer than 76 characters and the EncodeHeaderText() has been launched. Strange things happen. The original subject is:

Code:

Subject: Delivery Status Notification (Failure)

And after the EncodeHeaderText() it looks like this:

Code:

Subject: =?unicode-1-1-utf-7?Q?[MODIFIER]_Deli?=

      =?unicode-1-1-utf-7?Q?very_Sta tus_Notification_(Failure)?=

My email client (Thunderbird) displays the encoded subject in this way:

Code:

+AFs-MODIFIER+AF0- Delivery Status Notification (Failure)

Where is the problem?

Cheers,
Rafal

Andrew
AfterLogic Support

Joined: 28 April 2006
Location: United States
Online Status: Offline
Posts: 1189

Posted: 20 February 2008 at 2:09am \| IP Logged

Quote:

After the EncodeHeaderText() method the subject looks like this:

Subject: =??Q?[MODIFIER]_Ulead_DVD_PictureShow_4.0=A9=E7=A9=E7=BFN-Hy?=

And my Thunderbird client shows the encoded subject line as a single "?" character and a correct subject (Ulead DVD PictureShow 4.0) when no encoding is used.

The encoded header you provided doesn't contain a charset specification at the beginning. To get rid of this issue, specify a valid charset for EncodeHeaderText() method.

Quote:

My email client (Thunderbird) displays the encoded subject in this way:

Code:

+AFs-MODIFIER+AF0- Delivery Status Notification (Failure)

Where is the problem?

That's strange. We've just checked such subject in some mailers (Outlook Express 6, Thunderbird 1.5, The Bat 4) and got it displaying correctly:

Which version of Thunderbird do you use? Is it a localized version?

Best regards,
Andrew

rafaellop
Newbie
Newbie

Joined: 13 September 2007
Online Status: Offline
Posts: 26

Posted: 21 February 2008 at 6:37am \| IP Logged

I use Thunderbird 2.0.0.9.

Andrew
AfterLogic Support

Joined: 28 April 2006
Location: United States
Online Status: Offline
Posts: 1189

Posted: 21 February 2008 at 7:40am \| IP Logged

We've checked this with some other e-mail clients, they display such subject correctly. It seems this is a bug of Thunderbird version you use. Try to contact Thunderbird support team and ask them to investigate this.

Best regards,
Andrew

Christian Steve
Newbie
Newbie

Joined: 22 October 2009
Online Status: Offline
Posts: 2

Posted: 22 October 2009 at 9:19am \| IP Logged

My subject seems corrected now Andrew. Thanks for investigating this important issue. I'll let my employees know about Thunderbird for when or if they experience such isssues in the future.

Thanks again,

Christian

Search for other posts by Christian Steve

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

Printable version

Forum Jump

.NET Components

ActiveX Components

Web scripts

Solutions

MailBee POP3