SmtpClient network activity log

Could you look into adding a way to log all network activity of the SmtpClient?

Something similar to this:

[ ](

We’re having issues sending mail to a few providers. The above tool is able to mail those providers without issues (from the same computer), but the SmtpClient from Aspose (or the default .NET SmtpClient) get’s a Timeout.

Having an activity log would help in diagnosing issues in the future as well.

Regards, Jerremy

Hi Jerremy,

Please accept my apologies for the delayed response.

We already have this feature on our roadmap, and hopefully the required logging functionality will be available with the release of Aspose.Email for .NET v1.8.0. For tracking purposes, I have attached this thread to the appropriate ticket (NETWORKNET-33200) from our bug tracking system. Once a fix is available for public use, you will be notified via this thread.

Please feel free to write back in case you have further inquiries or comments.


Just to inform you that your required feature is currently not supported by Aspose.Email for .NET. We have logged another ticket (NETWORKNET-33368) to bring feature on our road map. We will notify you via this thread as soon as we have made some significant progress towards the resolution of this ticket

Thank you for your patience.


Thank you for your patience.

Please download and use this latest version of Aspose.Email for .Net v2.1.0. We have supported the logging for Aspose.Email.Smtp client. In order to use diagnostics logging, you will have to modify the configSections by:

  • Adding a sectionGroup with name “applicationSettings”
  • Adding a section with name “Aspose.Email.Properties.Settings” and include:
  • Setting with name “SmtpDiagnosticLog” where filename is defined in the applicationSettings/Aspose.Email.Properties.Settings.

You can refer to the following sample of configuration for your requirements:

<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
    <section name="Aspose.Email.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    <setting name="SmtpDiagnosticLog" serializeAs="String">

We finally got around to testing this feature. It has one bug and three nice to haves.

The bug took me a bit to find. I had enabled logging for a Windows Service and set the log directory to “D:\something\smtp.log”. However no log file appeared. After a lot of searching and using ProcMon (Microsoft tool), I found it was writing the log file to the System32 directory.

After a quick look with Reflector it quickly became clear that this line breaks a few things:
<a title="Aspose.Email.Logging.LoggerManager

CTRL+Click to open in new tab." href=“”>LoggerManager.<a title="Logger Aspose.Email.Logging.LoggerManager.CreateLogger(string name, Appender appender);

CTRL+Click to open in new tab." href=“,Aspose.Email.Logging.Appender):Aspose.Email.Logging.Logger”>CreateLogger(“SMTP_DIAGNOSTIC_LOGGER_NAME”, new <a title="Aspose.Email.Logging.FileAppender.FileAppender(string fileName, IFormatter formatter);

CTRL+Click to open in new tab." href=“,Aspose.Email.Logging.IFormatter)”>FileAppender(info.<a title="string System.IO.FileSystemInfo.FullName { … }

CTRL+Click to open in new tab." href=“”>FullName, formatter));

Mainly the info.Fullname, the name of the file is correct, but that line removes the path information. And for Windows Services the startup directory is the System32 directory.

Secondly, there’s a nice date-addition to the filename when “SmtpDiagnosticLog_UseDate” is set to True. However this is only done during the initial creation of the log file. Not during runtime (e.g. when a new day starts, no new log file is created). It would be nice if it did role-over to a new day.

Another nice to have would be a clear “connecting to …” and “disconnected from …” (or some other way to more easily see when the SmtpClient connects/disconnects from servers, as this isn’t clear from the logs at the moment). It’s hard (though not impossible) to keep track of Smtp sessions.

The final nice to have is an indication if something was received, or if it was sent. Currently there’s no difference between sending/receiving lines in the log.

Thanks for providing feedback and suggestions for enhancing the product features.

We are afraid to inform that we could not reproduce the reported bug here and need more assistance from you. Could you please send us a compilable sample code (with configuration info) which can be used to reproduce it here as it is must required for logging any bug in our issue tracking system.

We will analyse your mentioned three nice to have features and forward this information to our development team for further processing.

Once the above mentioned sample code is provided, we will log ticket for bug and enhancements.

Thanks in advance for your cooperation and patience in this regard.

Let’s forget the “Windows Service” part, take your sample application from this example:

Now change the config to the following value:




If you do this you will notice that the file is indeed called “SMTP.log” but it’ll be created in the directory where you start the example program. You can try any path modifier you want (c:/smtp.log, c:\smtp.log, …\smtp.log, etc), it will create the log file at the specified location.

To get into a bit more detail, the log file will always be created in the directory that is returned by “System.IO.Directory.GetCurrentDirectory()”. This is due to the fact that the Logger is created with just the filename and not so much the path specified by the config value. Let one of your dev’s look at this post and then look at the part where the logger is created for the SmtpClient.

While this isn’t a huge issue with normal windows applications, this is a huge issue for Windows Services and ASP.NET sites since their current directories aren’t what you expect them to be.

Hi Jerremy,

Thanks for providing us detailed analysis.

We have tried the sample form based application and found the reported issue. We have passed all the current and previous information for web based applications to the development team and will let you know once the feedback is received from the developers.

Thanks for your patience and understanding in this regard.

This issue is logged in our issue tracking system as NETWORKNET-33494.

The issues you have found earlier (filed as NETWORKNET-33494) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.