|0||No flags set.|
|1||Force MailBee to try authentication methods regardless whether they are advertized by the server in its capabilities or not.|
|2||Force MailBee not to switch to other authentication methods if the best (most secure) of the desired methods is not supported by the server. Usually makes sense only ifflag is set too because otherwise the possibly unsupported methods won't even be tried at all.|
|4||Force MailBee to try simple (i.e. non-secure) authentication methods before secure ones. In other words, MailBee will iterate through the list of desired methods in reverse order. This option is useful for communicating with mail servers which have errors in their secure authentication implementations. This flag is also set by default if SafeMode was true. However, if you would better prefer to use secure methods if possible, consider using flag.|
|8||If this flag is set, MailBee won't retry the login attempt with a simple method if the currently tried secure method failed the authentication. Set this flag if you require the client to always use secure authentication. Do not set this flag if the server has problems with its implementation of security algorithms (many servers advertize secure authentication capability but in fact do not implement it correctly). The flag has no effect if non-secure methods are not available (e.g. when IMAP server advertizes LOGINDISABLED or SMTP server advertizes nothing but NTLM), or ifflag is set (because the simple method would have already been tried to the moment), or if flag is set (because it assumes the highest level of security).|
|16||If this flag is set, MailBee will use SSPI implementation of NTLM and GSSAPI methods. This implementation requires UnmanagedCode permission due to the need to access Windows API. If this flag is not set, MailBee will use NegotiateStream managed implementation and thus not require UnmanagedCode permission. Setting this flag sometimes helps with MS Exchange connectivity. Also, this flag has no effect for UWP and .NET Core apps as they either can't work with NegotiateStream (and SSPI implementation is used even if this flag is not set) or can't work via SSPI and NegotiateStream is always used. .NET Standard 2.0 edition of MailBee.NET.dll always uses NegotiateStream approach.|
|32||If this flag is set and no domain is specified (neither in account name nor in separate domain parameter), MailBee will use the local domain name for that. If not set, MailBee will use empty domain name in this case. This flag is only used with NTLM and GSSAPI authentication methods.|
|64||Set this flag if Login method must only change the internal state of the component to "logged in", no actual commands to the mail server will be sent. Useful when the login itself is performed with custom commands.|
These flags affect how MailBee selects authentication methods for login process.
By default, MailBee takes the list of the desired authentication methods (specified by authMethods parameter of Pop3.Login method for Pop3, authMethods parameter of Imap.Login method for Imap, or by SmtpServer.AuthMethods property for Smtp), filters out the methods not advertized by the server in its capabilities, and then tries the remained methods until compatible method is found. If such method was found, it's used for the authentication process. If not, an exception is thrown if exceptions are enabled.
The flags in this enumeration allow the developer to change the default behavior of MailBee.
The above means that the authentication process is actually two-step. First, the appropriate method is selected, then, it's tried. Most flags affect how the appropriate method is selected (i.e. the first step).flag, however, affects what happens after the second step (what to do if the authentication fails).