We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Aspose.Email.Pop3.Pop3Client does not work correctly with the name of attached files in alternative codepage


Aspose.Email.Pop3.Pop3Client does not work correctly with the name of attached files in alternative codepage.

For example, if the email contains the attached file with the name (with russian letters) “прекрасный документ с русскими буквами (2).txt” after processing by Pop3Client client, the extracted name will be: “„Ѓ„‚„u„{„‚„p„ѓ„~„Ќ��z „t„Ђ„{„…„}„u„~„„ „�� „‚„…„ѓ„ѓ„{„y„}„y „q„…„{„r„p„}„y (2).txt"
for that case the propery of the Aspose.Email.Mail.Attachment.ContentType:
application/octet-stream; name=”

But in case the attached file will have the name with english chars only, it will be processed correctly:
for the name of file - “Log.cs” the propery of Aspose.Email.Mail.Attachment.ContentType:
application/octet-stream; name=Log.cs

Could you fix the issue?

It appears in all versions of Aspose.Email.dll (1.0.0 - 1.5.0)


First of all, please accept my apologies for the delayed response.

I have worked with your scenario, and unfortunately I am unable to replicate the said issue on my end.

Could you please share a sample message for our review so we may correctly and efficiently evaluate the problem cause? It would be of great help, if you could share your code snippets too.

Thanks in advance for your understanding and cooperation.

no problem with simple mail but now, at first step, i would like just describe the situation in which the issue appears.

1) set the setting of POP3 server to TNEF format.
2) create the email with international letters + embedded picture + 3 attachents (2 with international letters and 1 with english letters only(!)) + use in the subject the international letters.
3) using outlook send the email as "Rich text"
4) read the email using Pop3Client client.

As result, after calling the method FetchMessage(xxxxxx) you will have broken name of attachments.

Next, after saving the MailMessage object into msg format, you will have the broken subject, the names of attachmets (for the one which had international letters in its name).

More other…
after the saving email into msg format, the place of the attachments will be wrong!

I would like to add one important info:

in case of creating the email as described above but with 2 attached files with internatinal files only!!! the processing was changed: the pop3 client read the emails from the server with correct name of attachments!!! but store it into the msg format with big count of errors (unread international letters in subject and the names of attachments).

I have tested your latest version of Aspose.Email.dll v1.6.0
No progress with that issue at all. Big problems with international letters are still presented.
Please, see the example of emails with issue in the attachment.

Two messages: original and processed by pop3 client class.
the second one contains a dozen issues which was described above.

Please, fix it +)
Thank you in advance!


Thank you for your detailed analysis.

I am looking into this matter and I will keep you updated with my results.



Thank you for your patience.

You can avoid your said encoding issue (broken attachment names and broken subject) by saving the fetched message to Outlook unicode message format. To do so, please explicitly specify MailMessageSaveType.OutlookMessageFormatUnicode in Save method as second parameter. Check the below code snippet for reference.

var message = client.FetchMessage(messageInfo.SequenceNumber);
message.Save(str_filename, MailMessageSaveType.OutlookMessageFormatUnicode);

The above code worked for me on Gmail Pop3 server. Try it at your end and feed us back with your results.

Note: Attached is my output for your reference.


After saving the message using your code (message.Save(str_filename, MailMessageSaveType.OutlookMessageFormatUnicode))
the subject appears in correct codepage. Thank you.

But the names of the attachments still have the issues.
See the picture for the details

Please, take your look on the picture.

I am trying to decode ContentType of the attachment using standard approach:


as you may see, I didn’t get correct decoding…

You are using the utf-8 for decoding the string, but it is not correct in our case…


Thank you for sharing the snapshots.

I can see that you are experiencing the problem that I am unable to replicate on my end. In order to investigate this issue further and raise a ticket for it, I have to ask for a sample application and a test account on your mail server for a few days.

Also to simulate your testing environment, I need your system specific details like,
  • OS version
  • OS Architecture (32/64 bit)
  • OS Service Pack version/language
  • Visual Studio version and Service Pack
  • .NET Framework version
  • Outlook version


On the client side we are using:
- WinXP32 + SP3
- VS2010 Ultimate Edition + SP1
- NET2.0
- Outlook 2003 (11.8330.8333)

the pop3 server have the mail-related setting to TNEF.
I am trying to organize the test access to our mail server but I can’t promise you on 100% that it will possible…
sorry… +(

In case of set the pop3 server mail-related setting to nHTML, the behavior of the work is changed.
The attached picture shows the result:
- no problem with international chars in sublect [+]
- no problem with international chars in the names of attached files [++]
- problem with drawing the embedded picture… [–]
(instead of the picture we see the red cross)

Hi Raza,

The situation with the international chars are more complex as I thought before…
In case of reading the rich formatted message on 32bit winxp using pop3client we get the issues in international names of the attachments.
But(!) in case of doing the same on the 64bit WinServer2008 we don’t have any issues!!! And all(!) works fine (for TNEF setting)!
But the embedded pictures doesn’t appear for both architecture of OS… (with the nHTML setting on the pop3 server).

In other words, the international chars decoding without any problems on 64bit OS but have (sometimes) the issues on 32bit OS.
It is the fact (for TNEF).

If you will take the look on the length of the encoded string (base64) from my previose email, you will see that it is strange…
If I encode the international string on 32bit OS from utf-8 + base64 manually, I get shorter length then i see in the attach.ContentType.Name property…

May be the сapacity of the OS has the influence on the behavior of decoding algorithm into your classes?


Thank you for your analysis.

I have prepared a VM to simulate your environment and I am currently looking into this matter more deeply.

The problem is that we are unable to find a mail server (having free subscription) that could enable us to turn the TNEF/nHTML settings on or off to exactly match your situation. As discussed earlier, no said encoding issues were found with Gmail Pop3 server when the fetched message was saved to Outlook Unicode Format. With such results, we believe that the problem lies in your mail server settings and not in Aspose.Email component. Therefore, we greatly need your help to setup a test account on your mail server (for a few days) to correctly isolate the problem cause. Once identified we can move forward to fix it.

Note: Please also provide a sample application or code snippets for our review.

Thank you for your understanding and cooperation.

Hi Raza!

Please see the snippet code below:

using( Pop3Client client = new Pop3Client(FEmailServer, FEmailPort, FEmailUserName, FEmailUserPassword) ) {

try {
Pop3MessageInfoCollection msgCollection = null;

client.Timeout = FEmailTimeout;
try {
msgCollection = client.ListMessages();
catch( Exception ex ) {
throw new Exception(string.Format(“err [{0}] reading from: {1}”, ex.Message, FEmailServer));

foreach( Pop3MessageInfo msgInfo in msgCollection ) {
int UniqueID = msgInfo.SequenceNumber;
MailMessage msg = client.FetchMessage(UniqueID);
[//msg.PreferredTextEncoding](https://msg.preferredtextencoding/) = System.Text.UTF8Encoding.Default; // <-- koi8-r???
msg.PreferredTextEncoding = Encoding.UTF8;

if( msg.To.Count == 0 ) continue;

//fixing the issue with russian chars in the names of the attachment
//fixed in v1.6.0!!!
foreach( var attach in msg.Attachments ) {
attach.NameEncoding = System.Text.UTF8Encoding.Default;
attach.PreferredTextEncoding = System.Text.UTF8Encoding.Unicode;

//due to issue with international chart just translit the string from russian into english
//fixed in v1.6.0!!!
[//attach.Name](https://attach.name/) = translitString(attach.Name);

[//System.Console.WriteLine](https://system.console.writeline/)("-[ {0} ]-------------------------", attach.Name);

try {
try {
[//msg.Save](https://msg.save/)(workingFolder + @"" + emailName + “.msg”, MessageFormat.Msg);
[//msg.Save](https://msg.save/)(LocalPath33, MessageFormat.Msg);
msg.Save(LocalPath33, MailMessageSaveType.OutlookMessageFormatUnicode); //OK!!!
finally {
finally {
// delete the read message
finally {
if( client.ConnectionState == Pop3ConnectionState.Authentication ) {


Thank you for the code snippets.

I have worked with your sample code by simulating the environment as discussed here. I am afraid, I didn’t find any encoding issues when fetched messages are saved to OutlookMessageFormatUnicode.

As we are unable to reproduce the issue on our end, we desperately need the test account on your mail server to look further into this matter.