Archive for the ‘Mail.dll’ Category

System.Security.Authentication.AuthenticationException

Friday, December 2nd, 2016

.NET uses SChannel.dll as underlying SSL/TLS implementation. SChannel is OS dependent and if incorrectly configured or configured to use only the latest TLS/SSL versions, may lead to problems with TLS/SSL negotiation.

Please note that protocols that were considered secure some time ago, like SSL 3.0, are no longer considered secure. New OS updates may disable some protocols or cipher versions. On Windows this is done via registry settings.

SSL version status

  • SSL 2.0 was deprecated (prohibited) in 2011 by RFC 6176.
  • SSL 3.0 was deprecated by RFC 7568 in June 2015.
    As of 2014 the 3.0 version of SSL is considered insecure as it is vulnerable to the POODLE attack that affects all block ciphers in SSL; and RC4, the only non-block cipher supported by SSL 3.0, is also feasibly broken as used in SSL 3.0.
  • The use of RC4 in TLS is prohibited by RFC 7465 published in February 2015.
  • The token supplied to the function is invalid

    Full exception looks like this:

    System.Security.Authentication.AuthenticationException :
    A call to SSPI failed, see inner exception.
    ----> System.ComponentModel.Win32Exception :
    The token supplied to the function is invalid

    Most likely your client tries to use TLS 1.2 but you are using old certificate on the server (e.g. signed using md5RSA algorithm).

    There are 2 options for you:

    1. Regenerate the certificate (especially if it’s self-signed).
    2. Use older TLS/SSL version (TLS 1.1, TLS 1.0, SSL 3.0). You can force Mail.dll or Ftp.dll to use it using following code:

      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls11;
          //client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls; // TLS 1.0
          //client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Ssl3;
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      
      

      Please contact your server administrator as TLS 1.1, TLS 1.0 and SSL 3.0 aren’t considered secure anymore.

    The client and server cannot communicate, because they do not possess a common algorithm

    Full exception looks like this:

    System.Security.Authentication.AuthenticationException :
    A call to SSPI failed, see inner exception.
    ----> System.ComponentModel.Win32Exception :
    The client and server cannot communicate, because they do not possess a common algorithm

    There are 2 possible scenarios:

    1. In most cases this means that the client is trying to use older SSL protocols like SSL 3.0, TLS 1.0 or TLS 1.1, but the remote server requires modern protocol – TLS 1.2.

      By default all our clients support TLS 1.2. Some older versions need to be told to use TLS 1.2, it is also a good practice to force TLS 1.2 only:

      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12;
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      
    2. Second option is the server is not supporting TLS 1.2 – you’ll need to use older protocol (TLS 1.1, TLS 1.0, SSL 3.0):
      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls11;
          // client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls; // TLS 1.0
          // client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Ssl3; 
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      

      Please contact your server administrator as TLS 1.1, TLS 1.0 and SSL 3.0 aren’t considered secure anymore.

    The message received was unexpected or badly formatted

    Full exception looks like this:

    System.Security.Authentication.AuthenticationException :
    A call to SSPI failed, see inner exception.
    ----> System.ComponentModel.Win32Exception :
    The message received was unexpected or badly formatted

    This error generally means that something is incorrectly configured on your machine.

    What you should try:

    1. Try forcing the latest TLS version (TLS 1.2):
      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12;
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      
    2. Use older TLS/SSL version (TLS 1.1, TLS 1.0, SSL 3.0). You can force Mail.dll or Ftp.dll to use it using following code:

      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls11;
          //client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls; // TLS 1.0
          //client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Ssl3;
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      
      

      Please contact your server administrator as TLS 1.1, TLS 1.0 and SSL 3.0 aren’t considered secure anymore.

    3. Finally you can download IISCrypto and review “Schannel” and “Cipher Suites” tabs.

      For example we have seen clients that have TLS 1.0 turned on, but have TLS_RSA_WITH_3DES_EDE_CBC_SHA cypher suite turned off. If server requires this cypher, you’ll get this error message.

      Selecting “Best Practices” and restarting, should solve the issue. You may need to select additional protocol suites depending on what your server requires

      Please note that using TLS 1.2 and forcing your server administrator to enable TLS 1.2 is the only correct and secure way to go.

    One or more of the parameters passed to the function was invalid

    Full exception looks like this:

    System.Security.Authentication.AuthenticationException:
    A call to SSPI failed, see inner exception.
    ----> System.ComponentModel.Win32Exception:
    One or more of the parameters passed to the function was invalid

    This error generally means that you are trying to use TLS/SSL protocol version that is not supported on your machine (most likely it was turned off, because it is no longer considered secure)

    What you should try:

    1. Try forcing the latest TLS version (TLS 1.2):
      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12;
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      
    2. Use older TLS/SSL version (TLS 1.1, TLS 1.0, SSL 3.0). You can force Mail.dll or Ftp.dll to use it using following code:

      using (XXX client = new XXX())
      {
          client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls11;
          //client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls; // TLS 1.0
          //client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Ssl3;
      
          client.ConnectSSL("host");
      
          client.Close();
      }
      
    3. Try to disable strong crypto using code:

            const string DisableCachingName = @"TestSwitch.LocalAppContext.DisableCaching";
            const string DontEnableSchUseStrongCryptoName = @"Switch.System.Net.DontEnableSchUseStrongCrypto";
            AppContext.SetSwitch(DisableCachingName, true);
            AppContext.SetSwitch(DontEnableSchUseStrongCryptoName, true);
      

      -or- by using app.config file:

      <configuration>
          <runtime>
              <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
          </runtime>
      </configuration>
      

      ref: https://msdn.microsoft.com/en-us/library/mt298998(v=vs.110).aspx

    4. Finally you can download IISCrypto and review “Schannel” and “Cipher Suites” tabs.

      Selecting “Best Practices” restarting, should solve the issue. You may need to select additional protocol suites depending on what your server requires

      Please note that using TLS 1.2 and forcing your server administrator to enable TLS 1.2 is the only correct and secure way to go.

      Please contact your server administrator as TLS 1.1, TLS 1.0 and SSL 3.0 aren’t considered secure anymore.

    Using TLS 1.2 with IMAP

    Friday, November 18th, 2016

    By default most systems allow SSL 3.0, TLS 1.0, 1.2 and 1.2 to be used.

    TLS 1.2 is the most secure version of SSL/TLS protocols. It is easy to force the connection to use it. All you need to do is to set Ftp.SSLConfiguration.EnabledSslProtocols property to SslProtocols.Tls12:

    // C#
    
    using (Imap imap = new Imap())
    {
        imap.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12;
    
        imap.ConnectSSL("imap.example.com");
    
        imap.UseBestLogin("user","password");
    
        // ... 
    
        imap.Close();
    }
    
    ' VB.NET
    
    Using imap As New Imap()
    	imap.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12
    
    	imap.ConnectSSL("imap.example.com")
    
    	imap.UseBestLogin("user@example.com", "password")
    
    	'...
    
    	imap.Close()
    End Using
    

    For explicit SSL/TLS, code is almost the same. You first connect to non-secure port and secure the connection using Imap.StartTLS command:

    // C#
    
    using (Imap imap= new Imap())
    {
        imap.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12;
    
        imap.Connect("imap.example.com");
        imap.StartTLS();
    
        imap.UseBestLogin("user@example.com","password");
    
        // ... 
        
        imap.Close();
    }
    
    ' VB.NET
    
    Using imap As New Imap()
    	imap.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12
    
    	imap.Connect("imap.example.com")
    	imap.StartTLS()
    
    	imap.UseBestLogin("user@example.com", "password")
    
    	'...
    
    	imap.Close()
    End Using
    

    To use TLS 1.2 .NET Framework 4.5+ must be installed on your machine and you application should target .NET 4.5+.

    It is possible to use TLS 1.2 in applications targeting .NET <4.5, but 4.5 must be installed on the machine. After you have .NET 4.5 installed, your 2.0-4.0 apps will use the 4.5 System.dll and you can enable TLS 1.2 using this code: [csharp] imap.SSLConfiguration.EnabledSslProtocols = (SecurityProtocolType)3072; [/csharp]

    Logging in Mail.dll

    Monday, August 1st, 2016

    To enable logging for Mail.dll clients (Imap, Pop3, Smtp) you only need to add the following line before you connect:

    // C# version:
    
    Limilabs.Mail.Log.Enabled = true;
    
    
    ' VB.NET version:
    
    Limilabs.Mail.Log.Enabled = True
    
    

    You can observe the log output by:

    • looking at the Visual Studio’s output window (View/Output/’Show output from’: Debug)
    • subscribing to Log.WriteLine event
    • defining custom listeners using your application’s config file (App.config or Web.config)
    • using log4net

    This is how the log looks like in the Visual Studio’s output window:

    You can also enable logging using your application’s config file (App.config, Web.config):

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <system.diagnostics>
    
          <switches>
            <add name="Mail.dll" value="Verbose" />
          </switches>
    
        </system.diagnostics>
    </configuration>
    

    log4net

    If you are using the latest version of log4net.dll, Mail.dll is going to use log4net instead of standard .NET System.Net.TraceSource class. Please refer to log4net manual on how to capture log entries.

    Mail.dll uses logger called “Mail.dll” (_logger = LogManager.GetLogger(“Mail.dll”)) and level Info (_logger.Info(message)) to log information.

    Please remember that even when using log4net, you need to enable logging by setting “Limilabs.Mail.Log.Enabled = True” or by setting Mail.dll trace switch in the config file (App.config, Web.config) to Verbose as shown above.

    Log to file

    You’ll need to define a TextWriterTraceListener that writes to a file and connect it with Mail.dll trace source. The easiest solution is to modify your application’s config file (App.config, Web.config) accordingly:

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <system.diagnostics>
    
            <trace autoflush="true"/>
       
            <switches>
                <add name="Mail.dll" value="Verbose"/>
            </switches>
       
            <sources>
                <source name="Mail.dll">
                    <listeners>
                        <add name="MailLogFile"/>
                    </listeners>
                </source>
            </sources>
       
            <sharedListeners>
                <add 
                    name="MailLogFile" 
                    type="System.Diagnostics.TextWriterTraceListener" 
                    initializeData="c:\mail.log"/>
            </sharedListeners>
    
        </system.diagnostics>
    </configuration>
    

    Log.WriteLine

    Log class exposes WriteLine event. You can use that event to subscribe your own logging library.

    // C#
    
    Log.WriteLine += Console.WriteLine;
    
    ' VB.NET
    
    Log.WriteLine += Console.WriteLine
    

    Helpful POP3 and IMAP Exchange 2013 links

    Thursday, February 18th, 2016

    Here is the list of some helpful links regarding IMAP and POP3 protocols in Exchange 2013:

    Enable IMAP4 in Exchange 2013

    Enable POP3 in Exchange 2013

    POP3 and IMAP4

    Public folders in Exchange 2013
    Public folders and IMAP

    Shared mailboxes in Exchange 2013
    Accessing shared and delegated mailboxes

    Helpful POP3 and IMAP Exchange 2010 links

    Thursday, February 18th, 2016

    Here is the list of some helpful links regarding IMAP and POP3 protocols in Exchange 2010:

    Enable IMAP4 in Exchange 2010

    Enable POP3 in Exchange 2010

    Managing POP3 and IMAP4 in Exchange 2010

    Understanding POP3 and IMAP4

    Public folders and IMAP

    Accessing shared and delegated mailboxes