Sender in ImapMessageInfo different from Sender in MailMessage

Question

I have received a SPAM message for which the Sender property is set in case of ImapMessageInfo object but is null when i check it in MailMessage object. Is this by design or is this a bug?

var info = imap.GetMessageInfo("E+8BMAAEG9", ImapListFields.FullHeaders);
var message = imap.GetMailMessage("E+8BMAAEG9");

Console.WriteLine(info.Sender ?? "null");
Console.WriteLine(message.Sender ?? "null");

This is the result:

my.email@domain.com
null

Here are the email headers:

Return-Path: <my.email@domain.com>
Received: from 123.23.201.56 [123.23.201.56] (HELO [123.23.201.56]) by <my mail server> with SMTP (IdeaSmtpServer v0.80) id 5c73ff4834c2ebd2; Mon, 28 Apr 2014 16:19:57 +0200
Message-ID: <3994741C51D9FC3994741C51D9FC3994@XV1UR1XXV1>
From: <my.email@domain.com>
To: <my.email@domain.com>
Subject: Turn your 2 spare hours in a week to 230 EURO  helping others
Date: 29 Apr 2014 03:09:48 +0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109

Answer 1

It's an inconsistency in design of ImapMessageInfo and MailMessage objects. ImapMessageInfo.Sender actually returns ImapMessageInfo.From[0] if the sender fields is empty. On the other hand, MailMessage just returns null in this case.

Thanks for bringing this to our attention. We will probably change it in one of the next releases.

Answer 2

After looking into this, we found out that this behavior was added to make ImapMessageInfo present the same Sender when ImapListFields.FullHeaders is used as the one reported by the server when using ImapListFields.Envelope.

This means that changing ImapMessageInfo's behavior for ImapListFields.FullHeaders would not be a good decision, as it would break compatibility with ImapListFields.Envelope mode.

Another possibility - making MimeMessage and MailMessage behave like ImapMessageInfo - doesn't seem like a good idea either.

For now, we will keep the current behavior which seems to be the least bad option.