I probably didnt make this so clear,

But of course DNS resolution is also required. The server needs
also to be able to resolve the host names to contact the remote
alltalk servers.

Glen.

--- In alltalk-avp@..., "lrs_y_gk_07" <glenk@...>
wrote:
>
>
> 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@... <mailto: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@... <mailto:glen@...> .
>
> As far as the glen@...
> <mailto:glen@...> client is concerned, the response
> is no different than one received directly from its own server.
>
> 2) Remote Authentication.
>
> 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@...
> <mailto:glen@...> ) having already determined the
> encryption details for abc555@...
> <mailto: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@...
> <mailto: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.
>
> 3) Remote Delivery Notifications
>
> 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@... <mailto: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@...
> <mailto: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.
>