Dear AllTalk Server owners,

There is now an important new requirement for network access for AllTalk server to allow AllTalk server intercommunication.

AllTalk server now must be able to access remote Alltalk servers on port 21025. IE AllTalkServer must have outbound access on port 21025 for all IP addresses.

Can you please ensure that before the Update on December 1, that the computer hosting your Alltalk server has permissions to access 21025 at any IP address.

The reason for this is to allow intercommunication between AllTalk servers - Alltalk server must be able to contact other AllTalk servers to verify credentials and send Delivery notifications.  If your server doesn't have permission for outbound 21025 permissions, you wont be able to seemlessly communicate with other AllTalk servers.

A detail explanation of the new services follow.

1) Remote CERT.

AllTalk server can now return credentials for users on other servers. IE AllTalk clients can now request the encryption certificate for any other AllTalk client regardless of the server on which the account is held.

The Alltalk server wil respond to the CERT command from an AllTalk client by returning the current encryption certificate for the requested address. If the account is not local, the AllTalk server will attempt to connect to the server on which the account is held and if connection is successful, it then replays the CERT command and returns the response to the client.

eg. glen@... connects to the Galkam server and issues "CERT abc555@..." . The Galkam server identifies that the account is not local and attempts to connect to the LRSupport server. On successful connection, the Galkam server replays the cert command "CERT abc555@...". The LRSupport server returns the appropriate response. The Galkam server, then replays the response back to glen@....

As far as the glen@... client is concerned, the response is no different than one received directly from its own server.

In keeping with AllTalk's Anti-Spam policy, no message can be accepted unless the sender has been authenticated.

AllTalk (or other SMTP) Clients wishing to send secure messages to an AllTalk server for which it is not a member MUST use remote authentication.  Remote authentication works by the allowing the client to request Authentication from the RECIPIENT'S server and that server relaying the request back to the Senders Server.  On receiving a request for remote authentication, the Recipients server makes a connection back to the SENDERs (claimed) server.  The client then authenticates as normal and the RECIPIENT's Alltalk server "PROXY's" the authentication process - so in effect, the calling client simply authenticates against its own server. For Example:

The Sender (glen@...) having already determined the encryption details for abc555@... from a previous CERT command, connects directly to the LRSupport server on the standard AllTalk Messenger port (21025). Because the client knows it does not have an account on that server, it issues a request for remote authentication "AUTH RCRAM-MD5 glen@...". The LRSupport server then attempts to make a connection to the Galkam server (the Senders' claimed server) and issues the "AUTH CRAM-MD5" command. The Galkam server, simply responds with the standard Challenge string which the LRSupport server returns to the client (glen@... ). The client then authenticates as normal using the returned challenge string. The LRSupport server monitors the connection for a successful authentication, and once satisfied that the Sender is who they claim to be, will then accept messages from that client.

Note: There is NO RISK of compromising the sending clients credentials during this process. The CRAM-MD5 authentication protocol is based on MD5 signing and the actual passwords are never sent during the exchange, nor is there any way to derive the password from the exchange. Further, it is not possible to replay the exchange to trick the server into providing a logged-on session as the server issues challenges that can never be re-used.

In order that delivery notifications  (ATTrack CSV files) are returned to the Sender regardless of which server the recipients mailbox is located, AllTalk server supports Remote Delivery Notifications.

AllTalk server generates delivery notifications at the time the recipient downloads a message and indicates a successful decryption (or not as the case may be). For Senders on the same server, the AllTalk server simply writes the tracking record directly into the senders mailbox in the tracking folder. For senders who are on a different server the Recipients AllTalk server will make a connection to the senders server on the Messenger port and issue a NOTIFY command. The Senders AllTalk server on receiving the NOTIFY will write the tracking record in the senders Mailbox. Note: should the Senders server be unavailable at the time, the recipients server will store the tracking record for sending later when the Senders server is back up.

4) Remote Address book

It has been proposed in the past that AllTalk servers will be able to exchange Address book details. This is no longer be required as the Remote Authentication process now allows clients wishing to retreived address book details to do so directly from any server they wish. Together with the fact address book maintenance might represent significant traffic for the Server owners, it is no longer our intention to provide this functionality.

However, for the clients who have elected to publish their Doctor details in "Organisations and People" the expectation is that other AllTalk clients wanting to communicate with them will be able to do so with no more detail than their Published ID (eg Provider Number).

The ability for AllTalk server to deliver messages based on the Provider number is based on the "Entitiy index" which is automatically built from published details in the address book. This index is quite small (no more than a few Kbytes generally) and contains only the link between the Published ID and the AllTalk mailbox. Alltalk servers will automatically exchange Entity Index details ensuring that the details are always up to date.

This information is used by the CERT function to retreived the mailbox for a given Provider number.

eg. glen@... wants to send a message to a doctor whos provider number is 1234567F. The client connects to the Galkam server and issues "CERT 12345678F". The Galkam server checks for a mailbox of that name and does not find one. It then checks the Entity Index and finds that the provider number is associated with a malbox on the equery.lrsupport.com.au. It then carries on as if the client had requested "CERT 12345678F@..." and as for the remote CERT example above, it connect to the LRSupport server and replays the CERT command, returning the response to the client.