Documentation
    {{docApp.userSession.userId}}
    {{docApp.userSession.userName}}
    {{docApp.userSession.email}}
    Issuer : {{docApp.userSession.issuerInstance}}
    Expires : {{new Date(docApp.userSession.validUntil).toLocaleDateString()}}

{{docApp.title}}

{{docApp.description}}

INDEX

Documentation Library

Search for information on Hornbill Documentation.

{{docApp.searchError}}

{{docApp.searchResultFilteredItems.length}} results for "{{docApp.currentResultsSearchText}}" in {{docApp.searchFilterBySpecificBookTitle}}

Have questions about this site?

What is this site?

  • This website is Hornbill's new product documentation website and is currently under development.
  • It is intended that all existing and future public-facing documentation we produce will be available to search, browse and share.
  • Hornbill's current documentation is available at Hornbill Wiki but over time this content will be migrated to this documentation site.
  • Please feel free to have a look around at any time.

Why has Hornbill created this site?

  • Hornbill's products have moved on considerably since we introduced it almost 10 years ago. At the time, the MediaWiki tool was sufficient, but we have outgrown it.
  • Our customers are more enterprise focused and more self-sufficient than ever before, so for 2023 and beyond we have established a new documentation platform and team to drive our documentation initiative forwards.
  • We are aiming to deprecate the use of Hornbill Wiki for most Hornbill related documentation.
  • We want to enable our growing partner network with product resources and information, documentation beyond our Wiki approach is required.
  • We could definitely do with some help, and may even pay for some! If you have domain knowledge and would like to help, please check out our Hornbill Docs Contributor Guide and contact the Hornbill docs team at docs@hornbill.com.

What will this site be good for?

  • Community contribution will be facilitated, encouraged, and most welcome.
  • High quality documentation, will be kept up to date as rapidly as our products evolve.
  • Real-time content search and discovery.
  • Articles organized into books, books into libraries, creating a more natural and logical structure to our documentation.
  • Legacy API documentation and various other documentation sources will all be consolidated into a single unified documentation system.
  • Documentation available in browser as well as printable/viewable as PDF on demand.
  • Personalized documentation experience, allowing dark/light mode, article subscriptions, social media sharing and other useful features.
  • Almost all publicly available documentation on docs.hornbill.com will be open-source and available to fork on GitHub, allowing customers to derive their own custom documentation around Hornbill products should they wish to.

What is the timeline for this site?

  • We have taken the decision to publish and make available early, there is very little content at this time.
  • As and when we have completed/usable documentation, it will be published here.
  • We have a host of additional features we wish to add over time, so please watch this space.
  • We expect most of our existing documentation should be reviewed/migrated to docs.hornbill.com over the coming months.
  • The documentation project will be ongoing, will continue to expand, evolve and improve day-by-day.

{{docApp.libraryHomeViewProduct.title || docApp.libraryHomeViewProduct.id}}

{{docApp.libraryHomeViewProduct.description}}

  1. {{book.title}}

{{group.title || group.id}}

{{group.description}}

  1. {{book.title}}

{{group.title}}

{{book.title}}
More...

E-mail Protocol Support

Hornbill is designed to interoperate with public and enterprise class e-mail systems and supports the following well understood, industry-strength network protocols for the transmission and reception of open standards based e-mail messages. All documented standards with their respective encryption and security features are supported.

Supported E-Mail Protocols Matrix

Plain Text SSL TLS Notes
POP3 110 Defined in RFC 1939
POP3 110 Defined in RFC 2595
POP3 995 Full description is “pop3 protocol over TLS/SSL (was spop3)
IMAP4 143 IMAP Version 4 as defined in RFC 2060
IMAP4 993 Full description is “imap4 protocol over TLS/SSL”. Use this port instead of the now depreciated TCP port 585 “imap4-ssl”.
IMAP4 143 Using TLS explicit STARTTLS with IMAP Version 4 as defined in RFC 2595
SMTP 25 Incoming SMTP mail, generally the mail server will not route mail outside of the internal mail network so the mail server can not be used as a spam distributor. This is generally were most mail-related security restrictions are placed for incoming mail.
SMTP 465 The use of this port has become a typical port for accepting incoming mail over SSL. Port 465 for SMTPS shows up in Appendix A of the 1996 “SSL Protocol Version 3.0” draft-standard published by Netscape hereThe SSL Protocol Version 3.0. Unfortunately, the use of this port never became a standard, the port is not registered with the IANA for SMTPS, it’s instead registered for URD – “URL Rendezvous Directory for SSM” by Cisco. So while port 465 may be used in some places the recommended approach is to use TLS encryption (STARTTLS) on submission port 587 or standard port 25 instead.
SMTP 587 RFC 2476 Message Submission. Used by mail users authenticated in the mail server you are connecting to in order to send outbound mail. In other words, the mail server will act as a router and send mail on behalf of the user. It will also place sent mail into the “sent-items” folder of the authenticated users mailbox. This is defined in RFC 2476
SMTP 25 Incoming SMTP mail but with the option to negotiate a secure SMTP channel using the STARTTLS command in order that the data is encrypted. Standard defined in RFC 3207

Tip

As a general rule, there is better support for the TLS encryption schemes than there are for XXXoverSSL variants. The use of the standards plain ports with an encryption negotiate is compatible with more systems and networks generally. However, some older mail servers, or services that use another tool such as stunnel or ssh only support XXXoverSSL.

Verified Mail Server Compatibility

The following matrix shows the verified connectivity options for a number of different mail servers. Verified means we test for this as part of our automated confidence and regression testing scheme.

Exchange Server 2007 Exchange Server 2010 Postfix+Dovecot (Linux x86) Google Mail Yahoo! Mail Office365.com
POP3-Plain Yes Yes Yes No No No
POP3-SSL Yes Yes Yes Yes Yes Yes
POP3-TLS Yes Yes Yes No No Yes
IMAP4-Plain Yes Yes Yes No No No
IMAP4-SSL Yes Yes Yes Yes Yes Yes
IMAP4-TLS Yes Yes Yes Yes Yes Yes
SMTP-Plain Yes Yes Yes Yes Yes Yes
SMTP-SSL 1 No 2 No 2 No Yes No No
SMTP-SUBMISSION-TLS Yes Yes Yes Yes Yes Yes
SMTP-SUBMISSION-SSL No 2 No 2 No Yes No No
SMTP-TLS Yes Yes Yes Yes Yes Yes

Notes:

  1. SMTP over SSL (or SMTPS) typically listening on port 465 is not supported by most systems. This was a standard-to-be that never made it. Explicit SSL implementations (using STARTTLS) took over as the standard.

  2. It is NOT possible get Exchange Server to listen for SMTP on port 465 with SSL encryption.

    Microsoft Exchange does not support SMTP over SSL (SMTPS). It is possible to make any SMTP virtual server or receive connector listen on port 465, but that will not achieve the goal of secure SMTP (SMTPS) because SSL is not supported. Why is this? There are two types of SSL used on the standard internet mail protocols: “explicit” and “implicit”. Initially, most of the SSL implementations were implicit, meaning that a dedicated port for SSL was used and an SSL negotiation had to take place before communications could begin. As a well known example, consider HTTP, which is on port 80 by default, but HTTPS (HTTP over SSL) is on port 443.

    Several years ago, the Internet community decided that a dedicated port should not be required for SSL because it made systems more complicated. Instead a new standard was devised based on the idea of explicit SSL. Unlike implicit SSL, explicit SSL is negotiated by the specific protocol after the plain text connection is made, most commonly using the STARTTLS command.

    Netscape had already chosen 465 as the SMTPS port, but Exchange Server had no SSL functionality in its SMTP implementation. By the time the Exchange team added SSL support it was obvious that explicit SSL was a better solution than implicit SSL. Most other SMTP server and client vendors have implemented the STARTTLS command as well, so there never was much need to support port 465, which wasn’t an official Internet standard anyway. To this day, no version of Exchange Server supports implicit SSL for SMTP. Telling an Exchange Receive connector or SMTP virtual server to listen on port 465 does not change this fact. Therefore, you need to use a client that supports STARTTLS on port 25. If you can’t use port 25, the next logical choice is 587, which is the standard port for client SMTP submissions. There aren’t many modern clients that don’t support STARTTLS on 25, so adding support for implicit SSL has not been necessary. It should be noted that MS Exchange POP3 and IMAP4 implementations have always supported implicit SSL but as of Exchange Server 2007, there is now full support for explicit SSL for these two protocols as well. Information sourced from http://technet.microsoft.com/en-us/magazine/2007.11.exchangeqa.aspx

  • Version {{docApp.book.version}}
  • Node {{docApp.node}} / {{docApp.build}}
In This Document