If you encountered a bug, there is a chance it's resolved in the latest version. To check this, remove your existing reference to MailBee.NET and install the latest version by running this command in NuGet package manager console:
Install-Package MailBee.NET
This happens with .NET Core apps if codepages subsystem is not initialized. To fix, install System.Text.Encoding.CodePages package (for .NET Core 2.0+). In NuGet console:
Install-Package System.Text.Encoding.CodePages
Also, Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) method must be called before accessing any MailBee class (e.g. in Main method or Form_Load, depending on the application type). This initializes codepages support in .NET Core runtime.
By default, MailBee tries to take advantage of extended capabilities offered by mail servers. However, sometimes these extended features might not work properly despite the fact the mail server claims it supports them. The common reason for this is network antivirus, firewall or mail filter which may intercept the traffic between the mail server and the client. If it does not support any features supported by the mail server itself, this may cause problems.
MailBee allows the developer to disable any advanced features. To disable them all at once, set MailBee.Global.SafeMode property to true before creating any instances or calling any methods of MailBee classes.
If you experience System.AccessViolationException exceptions in Visual Studio, try to run the app without debugging (Ctrl-F5 instead of normal F5). In this case, upgrading to a newer version of Visual Studio may help. For instance, Visual Studio 2012 Update 3 is prone to this problem while Visual Studio 2013 is fine.
Log file can be very useful for debugging any errors which occur during the session between the mail server and the client. Also, if you decided to contact our technical support for resolving the issue, you should also attach the log file. You can enable logging using Log property of any mailer component (including Smtp, Pop3, Imap and Ews).
With Ews, it's also useful to enable .NET Framework tracing of all network activities. See Ews.Log topic for details.
Often, the issue may be caused by your network configuration, not by the errors in the code. You should also try to do the same with another POP3/IMAP/SMTP client. For instance, if you can't send a message, try to do the same with Thunderbird. But be sure to send from the same computer where you're using MailBee, using the same protocol and account settings (for instance, if the SMTP authentication is not used in MailBee, disable it in Thunderbird as well).
Even if the problem still does not get reproduced with Thunderbird, make sure your antivirus or firewall software (if any) does not treat popular e-mail clients in a special way. For instance, many security programs put the most popular email programs on white list while unknown programs may get blocked.
Also, please note that you should test using plain POP3/IMAP/SMTP clients, not those which can work via proprietary protocols (Microsoft Office Outlook is an example). Microsoft Office Outlook can communicate with mail servers manufactured by Microsoft (such as Exchange) using internal protocols which are not supported by other software. Windows Live Mail is another example. With such e-mail clients, you should check what type of connection you're using. It must be IMAP or POP3 for incoming e-mail and SMTP for outbound. Or, you can stick with Thunderbird.
Most mail services nowadays support only SSL/TLS connections with mail servers. In such cases, you should use SslMode property to enable SSL connections and use the appropriate SSL port number. Some servers allow you to use regular (not SSL) ports but change the regular connection into secure one during the already established connection with the mail server. This is called STARTTLS and such option can be set as one of values of SslMode property.
You may also need to set the particular SSL/TLS protocol to use. See MailBee.Security.SecurityProtocol topic. Usually, setting server.SslProtocol=MailBee.Security.SecurityProtocol.TlsAuto helps in most scenarios (server is Imap, Pop3 or SmtpServer instance).
Administrators often enable only MAPI access and no IMAP/POP3/SMTP as MS Outlook clients typically use MAPI and do not need IMAP or SMTP to connect to MS Exchange. Make sure SMTP, IMAP or POP3 are enabled and their respestive ports are opened if you have connectivity problems. Login errors often occur when the Exchange server expects the full login name (domain\jdoe) or even domain\jdoe\alias to be supplied as a login name while you supplied just an account name (jdoe). Another issue with MS Exchange 2007 and above is that plain-text authentication may only work if you're on SSL connection (dedicated port or STARTTLS).
When sending e-mail through Exchange server, it may help to disable CHUNKING extension (especially if Exchange SMTP Tar Pitting is enabled). To disable CHUNKING (so that MailBee won't use BDAT command instead of DATA even if the server states BDAT is supported), use this code:
server.SmtpOptions = ExtendedSmtpOptions.NoChunking
(server is SmtpServer object instance).
For Exchange accounts with Administrator rights, IMAP/SMTP access is usually disabled. Use normal user accounts instead.
Exchange Information Store service must be running. Otherwise, you'll get login errors in IMAP.
With MS Exchange, consider switching to Ews component if possible.
If you're on .NET 4.5 and experiencing TLS 1.0 related error when making EWS or OAuth 2.0 queries, upgrade your solution to a newer .NET version. Alternatively, add this at the top of your code:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12
Copyright © 2006-2024 AfterLogic Corporation. All rights reserved.