Skip to main content
Kofax

Using TCLINK-MX7 with SSL 2048 Bit and 256SHA encryption

  1. Last updated
  2. Save as PDF
Article # 3032184 - Page views: 156

Issue

I have a request of the customer to use TC/LINK-MX7 (Microsoft Exchange 2013) with SSL, but their requirement is also that the SSL certificate should be 2048 bits with SHA-256 encryption.

  • Which steps must be done to get this type of certificate?
  • Is it possible to request also a certificate when TC/LINK-MX is configured to use multiple mail domains
    (configured under registry values TCLINKMX7\TCLSM\SMLinkDomain and TCLINKMX7\Exchange\SMTPDomainIn)?

Solution

This description is a guideline how to request the necessary certificates when using KCS TC/LINK-MX7 (KCS 10.0.1), Exchange 2013 and Microsoft certification services.
It assumes that the addressing is done in the format number@KCSService.SMLinkDomain (e.g. 1234567@fax.kcs)

Create a certificate request for TC/LINK-MX7
By default the C:\TOPCALL\SHARED\CREATE.BAT file which is used to create a certificate request will only request a certificate with 1024 bits.
Therefore we have to run the openssl tool with different parameters to request a 2048 bit / sha256 certificate request

  • Open an administrative cmd prompt (right-click "Run as administrator")
  • Within the cmd prompt window change to the C:\TOPCALL\SHARED directory (cd /d C:\TOPCALL\SHARED)
  • Set the OPENSSL_CONF environment variable to use the C:\TOPCALL\SHARED\Openssl.cnf file
    set OPENSSL_CONF=openssl.cnf
  • Verify the openssl version, it should be at least version 1.0.1 (KCS 10.0.1 ships version 1.0.1m), enter the following command and check the version number:
    openssl version
  • Optional steps:
    If you need the a certificate for TC/LINK-MX7 supporting multiple mail domains you have to reconfigure the OpenSSL tool to support so called subject alternative names.
    The Common name for the requested certificate is the primary Linkdomain (including all subdomains) and other mail domains are configured as subject alternative names
    • Create a backup copy of the C:\TOPCALL\SHARED\OpenSSL.cnf file
    • Launch Wordpad with Run as Administrator and load the C:\TOPCALL\SHARED\OpenSSL.cnf file. We cannot use Notepad to edit the file, because it does not detect the Unix line-breaks correctly
    • Under  View- Word wrap set No wrap
    • Locate the section [ req ] and scroll down to the req_extensions line
      remove the leading # and the next blank character from the req_extensions line, in this way the comment for the v3_req extension is removed and v3_req extensions are enabled:
      # req_extensions = v3_req # The extensions to add to a certificate request
      So after removing the comment the line looks like shown below
      req_extensions = v3_req # The extensions to add to a certificate request
    • Locate the section [ v3_req ] and scroll down to the following line
      keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    • Directly below the keyUsage line add a new line and assign the additional maildomain (as configured under TCLINKMX7\Exchange\SMTPDomainIn) as subjectAlternativeName:
      subjectAltName=DNS:*.SecondLinkDomain
      e.g.
      subjectAltName=DNS:*.kcs.sb.local
    • You might also add multiple maildomains, separated with a comma, e.g.
      subjectAltName=DNS:*.maildomain1.com,DNS:*.maildomain2.com
    • A sample openssl.cnf file is attached to this Article
    • Save the openssl.cnf file in text format (File - Save as - Plain text document, type: Text document (*.txt), File name: openssl.cnf)
  • Now create a new certificate request.
    Please note the addtional command line parameters -sha256 and the -newkey rsa:2048 which must be specified to request the required encryption level.
    When running through the wizard, the most important setting is the Common name, this should be configured to include all subdomains of the mail domain configured under registry value TCLINKMX7\TCLSM\SMLinkDomain, so for example, if the registry value TCLINKMX7\TCLSM\SMLinkDomain is configured to kcs, the common name in the certificate request should be set to *.kcs
    After the wizard is finished you will have the private key stored in the file PRIVATE.PEM and a certificate request file stored in file REQUEST.PEM

openssl req -config openssl.cnf -sha256 -new -nodes -keyout private.pem -out request.pem -days 365 -newkey rsa:2048

Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
................................................................................
................................................................................
................................................................................
....................................+++
.....+++
writing new private key to 'private.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AT
State or Province Name (full name) [Some-State]:Vienna
Locality Name (eg, city) []:Vienna
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kofax Austria GmbH
Organizational Unit Name (eg, section) []:Technical Services
Common Name (e.g. server FQDN or YOUR name) []:*.kcs
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:Kofax Austria GmbH

  • Check, if the PRIVATE.PEM contains the corrrect encryption method

openssl req -in request.pem -noout -text

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=AT, ST=Vienna, L=Vienna, O=Kofax Austria GmbH, OU=Technical Services, CN=*.kcs
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ....
        Attributes:
            challengePassword        :unable to print attribute
            unstructuredName         :unable to print attribute
    Signature Algorithm: sha256WithRSAEncryption
         ...

Install the Microsoft Certification services and reconfigure them to use SHA-256

  • This task is typically executed by the Domain Administrator at customer site:
    On a server located in the domain (might be even a domain controller) install the "Active directory Certificate Services" and enable also the Web enrollment (requires IIS).
    Please refer to Windows help for details.
    CertificationServicesRole.png
  • From the start menu Administrative Tools open the Certification Authority Management console
    Right click the certification authority and select Properties. In the Gerneral tab you see the default Hash Algorithm, which is set to SHA1
    CAHashAlgorithm.png
  • You can also verify the setting using following command line (open an administrative cmd prompt with "Run as administrator")
    certutil -getreg CA\csp\CNGHashAlgorithm
  • Change the setting to use SHA256. Take care to write SHA256 in uppercase characters
    certutil -setreg ca\csp\CNGHashAlgorithm SHA256
  • Afterwards restart the certification services and check again in the Certification Authority properties if the new setting was applied correctly
    net stop certsvc
    net start certsvc

Request the TC/LINK-MX7 Certificate from the Certification Authority

  • On the KCS Server with TC/LINK-MX7 open Internet Explorer and navigate to the Webpage of the certification authority:
    http://FQDN_of_the_CAServer/certsrv
    RequestACertificate.png
  • Click on Request a certificate
  • Click on Advanced certificate request
  • Click on Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
  • Open the C:\TOPCALL\SHARED\REQUEST.PEM in Notepad, select all contents with Ctrl-A and copy them to the clipboard using Ctrl-C
  • Paste the contents of the REQUEST.PEM into the field Saved Request: of the Web request form
  • In the dropdown box Certificate Template: select Web server
  • Leave the field Additional Attributes: empty and press the Submit button
  • Select the option Base 64 encoded and click then Download certificate
  • Save the certificate under C:\TOPCALL\SHARED with the filename CERTIFICATE.CER
  • Copy the C:\TOPCALL\SHARED\CERTIFICATE.CER to the filename C:\TOPCALL\SHARED\CERTIFICATE.PEM
  • Tipp: The CERTIFICATE.CER can be double-clicked in Windows Explorer and you can view the certification details, e.g. when exactly the certificate expires

Install the Root certificate of the Certification Authority on the TC/LINK-MX7 server

  • On the KCS Server with TC/LINK-MX7 open Internet Explorer and navigate to the Webpage of the certification authority:
    http://FQDN_of_the_CAServer/certsrv
  • Click on Download a CA certificate, certificate chain, or CRL
  • Select Encoding method: Base 64
  • Click on Download CA certificate
  • Save the Root certificate under the filename C:\TOPCALL\SHARED\<NameOfMyCA>-Rootcert.cer
  • Launch Notepad and open the file C:\TOPCALL\SHARED\<NameOfMyCA>-Rootcert.cer
  • Select all contents with Ctrl-A and copy the contents to the clipboard using Ctrl-C
  • Start a new instance of Notepad with Run as Administrator and open the file C:\TOPCALL\SHARED\ROOTCERTS.PEM
    The ROOTCERTS.PEM contains all root certificates of trusted Certification authorities
  • Press Ctrl-End to navigate to the end of the file
  • Enter a comment, e.g. Root certificate of <NameofMyCA> and paste then the contents fo the <NameOfMyCA>-Rootcert.cer
    So in fact the root certificate of the certification authority is appended at the end of the ROOTCERTS.PEM file and the comment is inserted so that you are able to identify the rootcertificate easily
    The comment must be entered outside the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers
  • Save the ROOTCERTS.PEM file

Check whether the Certification Authorities root certificate is installed correctly on the Micrsoft Exchange HUB/CAS Server (Exchange 2013)

  • This task is normally done by the Exchange Administrator user:
  • On the Microsoft Exchange server check, whether the Root certificate of your Certification Authority is listed as "Trusted Root certificate"
    If Exchange server and the server for the certification Authority are member of the same Windows domain, this should be normally the case.
  • Start mmc
  • Select menu option File - Add/Remove Snapin...
  • Under Available snap-ins select Certificates and press the Add > button
  • Under This snap-in will always manage certificates for: select Computer Account
  • Under Select the computer you want this snap-in to manage select Local Computer and press the Finish button of the wizard
  • Afterwards press OK to load the snap-in
  • Expand the Trusted Root Certification Authorities\Certificates Path and check, whether the root certificate of your Certification Authority is present
    RootCertificatesExchangeServer.png

Create a new Certificate request for the Microsoft Exchange HUB/CAS Server (Exchange 2013)

  • This task is normally done by the Microsoft Exchange Administrator user
  • Open the Exchange Administrative Center and login with an Exchange Administrator user
  • Navigate to servers - certificates and select the Exchange Server, where TC/LINK-MX7 connects to from the drop-down box
    ExchangeServerCertificates.png
  • Press the + button to open the new Exchange certificate wizard
  • Select option Create a request for a certificate from a certification authority and press the next button
  • Under Friendly name for this certificate enter e.g. the name of the Exchange server (in my case VMSB-EX2013) and press the next button
  • Leave the checkbox Request a wild certificate unchecked and press the next button
  • Under Store certificate request on this server, select the browse button and select your Exchange server within the Browse dialog. Confirm with OK and press then the next button
  • Under Specify the domains you want to be included in your certificate dialog press the next button
  • In the next dialog Based on your selections, the following domains will be included in your certificate you should use the + button to add the following domains
  • Ask the Exchange Administrator for help, if you are not sure, which domain names should be entered exactly:
    • External URL, how the CAS server will be reached, e.g. mail.yourcompany.com
    • Internal URL, how the CAS server will be reached, e.g. servername.yourcompany.com
    • Autodiscover URL
    • Exchange Domain Name
      ...
      These domain names are added as Subject Alternative names (SANs) to the certificate request. In my case following domains were added (sb.local is the Microsoft Exchange domain)
      ExchangeServerDomainNames.png
  • In the next dialog enter the information about your organization (Organization Name, Department, City/Loclity, State/Province, Country) and press the next button
  • Enter the pathname, under which the certificate request should be stored, this path name must be entered using an UNC path, e.g. \\MyExchangeServer\c$\MyExchangeServer_CertReq.req
  • Press the Finish button to create the certificate request

Get the certificate for the Microsoft Exchange HUB/CAS server from the certification Authority

  • The next steps are identical to the steps getting the certificate for the TC/LINK-MX7
  • Now open Internet Explorer on the Exchange server and navigate to the Webpage of the certification authority:
    http://FQDN_of_the_CAServer/certsrv
  • Click on Request a certificate
  • Click on Advanced certificate request
  • Click on Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
  • Open the Certification request file (in this example MyExchangeServer_CertReq.req) in Notepad and select all contents with Ctrl-A, copy the contents to the clipboard using Ctrl-C
  • Paste the contents of the certification request into the field Saved Request:
  • In the dropdown box Certificate Template: select Web server
  • Leave the field Additional Attributes: empty and press the Submit button
  • Select the option Base64 encoded and click then Download certificate
  • Save the certificate under any local directory of the Exchange server, use e.g. the name MyExchangeServer_Certificate.cer

Finish the pending certificate request on the Exchange HUB/CAS Server

  • Now open again the Exchange Administrative Center and go back to the page servers - certificates
    You should see there a Pending request. Select the pending request in the list and press then the ... button in the toolbar. Choose the option Import Exchange certificate.
    ExchangeServerImportExchangeCertificate.png
  • In the import Exchange certificate wizard enter the path where MyExchangeServer_certificate.cer is stored,
    Again the path must be entered in UNC syntax, e.g. \\MyExchangeServer\c$\MyExchangeServer_Certificate.cer
  • In the Specify the servers you want to apply this certificate to dialog add your Exchange server with the + button and press the Finish button.
  • Now the STATUS of the certificate should have been changed from pending request to valid

Assign the imported Certificate to Exchange Services

  • Now you have to assign the imported certificate to be used by specific Exchange services.
    Select again the certificate in the list and press then the Pencil button in the toolbar to edit the certificate ExchangeServerPencilButton.png
  • Navigate to the services section and enable the checkboxes for SMTP, IMAP, POP and IIS. Press the save button afterwards
  • This action will assign the new certificate to different services, so all exchange clients connecting e.g. using OWA will use the new certificate.
    Therefore assigning the new certificate must be only done after getting the confirmation of the responsible Exchange Administrator user.
    If there had been already another certificate assigned to SMTP or IIS services, you will get a warning to overwrite the existing assignment
    e.g. warning - Overwrite the existing default SMTP certificate. If you answer with yes, existing assignments will be overwritten.

Create and configure the Exchange Receive Connector

  • Open the Exchange Administrative Center and login with an Exchange Administrator user
  • Navigate to mail flow - receive connectors
  • Press the + Button within the toolbar to create a new receive connector
  • Assign a name, e.g. TCLINKMX2013 and select the Hub Transport role
  • Select a Custom type and press the next button
  • In the dialog A Receive connector can bind to a particular network adapter assign All available IPv4 addresses and configure the same port as configured under
    registry value TCLINKMX7\TCLSM\Port2SMTP. Press the next button afterwards
  • In the dialog A receive connector can accept mail from a range of IP addresses configure the IP addresses of the KCS servers running TC/LINK-MX7 and press the finish button
  • Select the newly created receive connector and press the pencil button from the toolbar to edit the receive connector
  • In the security tab enable the checkboxes Transport Layer Security (TLS), Enable domain security (mutual Auth TLS) for permission groups Partners and Anonymous users. Save the settings

Configure the mail mail domains used by TC/LINK-MX7 within the Exchange Transport config settings

  • Open the Exchange management shell (command line tool)
  • Within the TransportConfig set the TLSReceiveDomainSecureList to contain all possible subdomains of the mail domain as configured under TCLINKMX7\TCLSM\SMLinkDomain
    set-transportConfig -TLSReceiveDomainSecureList smlinkdomain,mx7.smlinkdomain,sms.smlinkdomain,free.smlinkdomain,fax.smlinkdomain,topcall.smlinkdomain
    so for example, if the registry value TCLINKMX7\TCLSM\SMLinkDomain is configured to kcs you have to configure
    set-transportConfig -TLSReceiveDomainSecureList kcs,mx7.kcs,sms.kcs,free.kcs,fax.kcs,topcall.kcs

Check the Microsoft Exchange default domain

  • Open the Exchange Administrative Center and login with an Exchange Administrator user
  • Navigate to mail flow - accepted domains
  • Check which of the listed mail domains is marked as default domain

Check if the Exchange Send Connector was configured correctly according to the TC/LINK-MX7 Manual

  • Open the Exchange Administrative Center and login with an Exchange Administrator user
  • Navigate to mail flow - send connectors
  • Select the Exchange Send connector created for TC/LINK-MX7 from the list
  • Within the tab delivery, verify that the Network settings are configured to Route mail through smart hosts and that the list of smart hosts contains the servers with TC/LINK-MX7 installed.
    You can specify the full-qualified domain names or even IP addresses. When using FQDNs, verify that the names can be resolved correctly using ping or nslookup
  • Smart host authentication should be set to none
  • Under tab scoping, check whether the Exchange sendconnector includes all address spaces, it should contain
    an SMTP address space where the domain fields contains the SMLinkDomain configured under registry value TCLINKMX7\TCLSM\SMLinkDomain (e.g. kcs)
    an SMTP address space where the domain field contains the SMLinkDomain configured under registry value TCLINKMX7\TCLSM\SMLinkDomain with all subdomains (e.g. *.kcs)
    an address space FAX with domain * (to support outlook contacts)
    one address space for each template address method (registry values TCLINKMX7\Exchange\Typexxx) with the domain set to * on each, so typically this will be FAXTC:*, FREE:*, TC:*,...
  • To check the port configured for the Exchange send connector, you have to use the Exchange management shell, get-sendconnector cmdlet, for the parameter ID you have to enter the name of the send connector
    get-sendconnector -id TCLINKMX7 | fl *
    To check specifically the port use
    get-sendconnector -id TCLINKMX7 | port
    The port must be the same as configured under registry value TCLINKMX7\TCLSM\Port2TC

Registry settings for TC/LINK-MX7 to use SSL

You should set the following registry settings to use SSL:

  • Configure the registry value TCLINKMX7\TCLSM\Port2SMTP to the same port as configured under the Exchange Receive connector
  • Configure the registry value TCLINKMX7\TCLSM\Port2TC to the same port as configured under the Exchange Send connector
  • Configure the registry value TCLINKMX7\TCLSM\SMSDDMode=1
  • Configure the registry value TCLINKMX7\TCLSM\SMRcvSecure=2 (SSL always mandatory)
  • Configure the registry value TCLINKMX7\TCLSM\SMSendSecure=2 (SSL always mandatory)
  • Configure the registry value TCLINKMX7\TCLSM\NotifyMailFrom=1 (to use the postmaster as originator for notifications returned to Microsoft Exchange)
  • Configure the registry value TCLINKMX7\Exchange\SMTPSyntaxToMail=1
  • Configure the registry value TCLINKMX7\Exchange\ExDomain to the Exchange default domain configured on the Exchange Server
  • Verify that the registry value TCLINKMX7\TCLSM\SMLinkDomain is configured to the mail domain name, for which the certificate was requested.
  • Verify that the registry value TCLINKMX7\TCLSM\CertificatePath contains the path where the REQUEST.PEM, PRIVATE.PEM, CERTIFICATE.PEM, ROOTCERTS.PEM are located (typically C:\TOPCALL\SHARED)
  • Verify that the registry values TCLINKMX7\Exchange\Typexxx are configured to the same Address spaces as configured under the Exchange SendConnector
  • Optionally: configure a second maildomain under TCLINKMX7\Exchange\SmtpDomainIn
  • Restart the TC/LINK-MX7 after applying the configuration changes and test outbound and inbound message flow and notifications

How to check whether SSL is really used in the direction from KCS to Microsoft Exchange

  • Enable the TCLINKMX7\TCLSM\TCPDebug=1 and set the TCLINKMX7\General\TraceLevel=0xff. Check the TCP trace.
  • The response returned by the Microsoft Exchange server for the EHLO should contain the 250-STARTTLS
  • Afterwards you should see that the TC/LINK-MX7 sends the STARTTLS command to the Exchange server
  • This STARTTLS command must be confirmed with a 220 SMTP response.
  • At this time the certificates are exchanged and verified - and from this point all communication is encrypted.
    If there is a problem with the certificates you will get an openSSL error. A description of possible OpenSSL errors can be found here:
    https://www.openssl.org/docs/manmast...ps/verify.html under the paragraph DIAGNOSTIC
  • Afterwards the EHLO command is repeated, followed by MAIL FROM, RCPT TO,...
  • You might install a network tracer like Wireshark and check whether the network traffic is encrypted.
    Take care that the TCPDebug trace is not encrypted within the TC/LINK-MX7 trace files.
  • Sample trace (working communication):

19/12:40:37.132 (10d8/15c4) TCP<-EHLO VMSB-KCS2012R2.sb.local
19/12:40:37.135 (10d8/15c4) TCP->250-VMSB-EX2013.sb.local Hello [172.20.242.180]
19/12:40:37.135 (10d8/15c4) TCP->250-SIZE 36700160
19/12:40:37.135 (10d8/15c4) TCP->250-PIPELINING
19/12:40:37.136 (10d8/15c4) TCP->250-DSN
19/12:40:37.136 (10d8/15c4) TCP->250-ENHANCEDSTATUSCODES
19/12:40:37.136 (10d8/15c4) TCP->250-STARTTLS
19/12:40:37.136 (10d8/15c4) TCP->250-8BITMIME
19/12:40:37.137 (10d8/15c4) TCP->250-BINARYMIME
19/12:40:37.137 (10d8/15c4) TCP->250 CHUNKING
19/12:40:37.137 (10d8/15c4) TCP<-STARTTLS
19/12:40:37.138 (10d8/15c4) TCP->220 2.0.0 SMTP server ready
19/12:40:37.232 (10d8/15c4) TCP<-EHLO VMSB-KCS2012R2.sb.local
19/12:40:37.239 (10d8/15c4) TCP->250-VMSB-EX2013.sb.local Hello [172.20.242.180]
19/12:40:37.241 (10d8/15c4) TCP->250-SIZE 36700160
19/12:40:37.242 (10d8/15c4) TCP->250-PIPELINING
19/12:40:37.243 (10d8/15c4) TCP->250-DSN
19/12:40:37.245 (10d8/15c4) TCP->250-ENHANCEDSTATUSCODES
19/12:40:37.247 (10d8/15c4) TCP->250-8BITMIME
19/12:40:37.248 (10d8/15c4) TCP->250-BINARYMIME
19/12:40:37.248 (10d8/15c4) TCP->250 CHUNKING
19/12:40:37.250 (10d8/15c4) TCP<-MAIL FROM:<"SB"@TOPCALL.kcs> RET=FULL ENVID=<20160419_124037_C1_02d57bfc_C2_000108e5_Name_00047545337@kcs> SIZE=965
19/12:40:37.262 (10d8/15c4) TCP->250 2.1.0 Sender OK
19/12:40:37.263 (10d8/15c4) TCP<-RCPT TO:<bernhard.schuetz2013@sb.local> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;bernhard.schuetz2013@sb.local
19/12:40:37.264 (10d8/15c4) TCP->250 2.1.5 Recipient OK
19/12:40:37.264 (10d8/15c4) TCP<-DATA
19/12:40:37.268 (10d8/15c4) TCP->354 Start mail input; end with <CRLF>.<CRLF>

  • Sample trace (SSL error): In this case the registry value TCLINKMX7\TCLSM\CertificatePath contained a wrong directory and the error returned was 20, which is X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY
    Lookup the error code under https://www.openssl.org/docs/manmast...ps/verify.html paragraph DIAGNOSTIC

19/13:30:55.641 (21c4/1d00) TCP<-STARTTLS
19/13:30:55.641 (21c4/1d00) TCP->220 2.0.0 SMTP server ready
19/13:30:55.673 (21c4/20ac) TCSRV called: 10
19/13:30:55.673 (21c4/20ac) tcsrv status request
19/13:30:55.674 (21c4/1d00) ID:7206 TCLSM.DLL:       <- SSL: verification problem: 20 error:00000000:lib(0):func(0):reason(0)
19/13:30:55.688 (21c4/1d00) TCP<-QUIT

How to check whether SSL is really used in the direction from KCS to Microsoft Exchange

  • Enable the TCLINKMX7\TCLSM\TCPDebug=1 and set the TCLINKMX7\General\TraceLevel=0xff. Check the TCP trace.
  • The response returned by the TC/LINK-MX7 server for the EHLO command should contain the 250-STARTTLS
  • After that the Exchange Server issues the STARTTLS command and TC/LINK-MX7 must respond with 220 Ready to Start TLS
  • At this time the certificates are exchanged and verified and the SMTP communication continues with EHLO, MAIL FROM,...

19/12:49:45.772 (10d8/f24) TCLSM.DLL:       SM_listen opens reception file C:\TCOSS\TCLP\Work\TCLINKMX2013\0.LMP (1404)
19/12:49:45.772 (10d8/f24) TCP<-220 VMSB-KCS2012R2.sb.local (KOFAX TC/LINK-SM Version 2.31.04) ESMTP service ready
19/12:49:45.773 (10d8/f24) TCP->EHLO VMSB-EX2013.sb.local
19/12:49:45.773 (10d8/f24) TCP<-250-VMSB-KCS2012R2.sb.local
250-DSN
250-STARTTLS
250 HELP
19/12:49:45.773 (10d8/f24) TCP->STARTTLS
19/12:49:45.774 (10d8/f24) TCP<-220 Ready to Start TLS
19/12:49:45.840 (10d8/f24) TCP->EHLO VMSB-EX2013.sb.local
19/12:49:45.840 (10d8/f24) TCP<-250-VMSB-KCS2012R2.sb.local
250-DSN
250 HELP
19/12:49:45.841 (10d8/f24) TCP->MAIL FROM:<bernhard.schuetz2013@sb.local>

 

Level of Complexity 

High

 

Applies to  

Product Version Build Environment Hardware
Kofax Communication Server 10.0.1+ All Microsoft Exchange 2013 or higher,
Microsoft Windows Certification Services		 n/a

References

Add any references to other internal or external articles

​

 

Article # 3032184
  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Article type
    Topic
  2. Tags
    This page has no tags.