Recipient notification agents are passive entities. They are driven by their clients. They provide Recipient Notification Agent Submission Protocol service to message stores and Recipient Notification Agent Query Protocol service to recipient MUAs.
These services are separate. Recipient notification agents that speak these protocols over TCP can, and in fact should, speak these protocols on separate IP addresses. These IP addresses may have different reachability characteristics. Indeed, the reachability of the IP addresses on which the access services are provided is one of the measures that recipient notification agent owners may employ for securing their recipient notification agents.
For example: A recipient notification agent, for use only by people within a single organisation and only when those people are connected to that organisation's own network, may be configured to speak RNASP on an IP address that is reachable from the rest of Internet, and to speak RNAQP on a non-public (RFC 1918) IP address that is only reachable by people within the same organisation as the recipient notification agent.
Recipient notification agents must allow multiple concurrent sessions of both protocols to exist, and must not delay transactions in a session because of the mere existence of other sessions. Recipient notification agents must behave as if all transactions are atomic with respect to one another.
Recipient notification agents should provide their owners with mechanisms for specifying an upper bound on the number of concurrent sessions that the message store will serve. Recipient notification agents may simply close any new connections as they are made if an attempt is made to exceed the session limit, or may employ the transport protocol's mechanism for refusing new connections. Owners should not set an upper bound for RNASP sessions that is less than 2, or set an upper bound for RNAQP sessions that is less than 5.
The location of the RNASP service is a matter of public record.
For Internet mail, the location of the RNASP service is published in the public DNS database by the owner of the recipient notification agent using SRV resource record sets. (A recipient notification service is thus useless without ownership, in some manner, of a domain name.) There is, intentionally, no well-known port number for RNASP service. The port number is contained in the DNS information.
When moving the RNASP service to a different IP address or port number, the RNASP service should continue to be available on the old IP address or port number until such time as the SRV records to locate it will have expired from any caching DNS servers. In other words, the RNASP service should continue to be available on the old IP address or port number for the TTL period of the old SRV resource record set. (Some DNS server softwares provide a "time to die" mechanism to allow DNS changes to be synchronised with a service changeover.)
The location of the RNAQP service is provided to recipients by explicit agreement between the recipient notification agent owner and the recipients. (The recipient notification agent owner and the recipient may, of course, be one and the same.)
There is, intentionally, no well-known port number for RNAQP service. The choice of port number is a private matter for recipients and the recipient notification agent owner.
In IM2000, a mailbox name denotes a specific user at a specific recipient notification agent.
The domain parts of mailbox names are used to locate the appropriate RNASP service.
The local parts of mailbox names are determined by private arrangements between recipients and recipient notification agent owners. They need not reflect the recipient account names. Recipient notification agent owners may decide
Recipient notification agents accept message notifications on behalf of recipients. A message store transmits a message notification by connecting to a recipient notificiation agent's RNASP service and transmitting a notification.
Notifications are designed to be short. Nonetheless, recipient notification agents should provide a mechanism for their owners to impose an upper bound on the overall number of notifications that will be accepted, in order to impose a quota on those agents' local resource usages. Recipient notification agents must not arbitrarily discard either any or all previously accepted notifications if an attempt is made to exceed this limit, and should instead simply reject the additional notifications with an appropriate transaction error. However, recipient notification agents may provide a mechanism for their owners to impose a replacement policy, specifying what notifications (if any) to discard in such situations to make way for the new one(s).
Notifications are also designed to be idempotent. Recipient notification agents need not store message notifications in persistent storage. To allow for recipient notification agents that may have been restarted, losing all notifications that they had remembered, message stores may refresh (unsilenced) notifications from time to time, causing notifications to be repeated. Thus, recipient notification agents must collapse multiple identical (consecutive or concurrent) notifications to the same recipient for the same message (i.e. a given message identifier at a given message store) into a single notification.
A notification comprises four data:
To these data, the recipient notification agent adds two more data:
These data are presented to recipient MUAs when they query for message notifications using RNAQP.
When collapsing multiple identical notifications into a single notification:
It is deliberately unspecified whether the date and RNASP client address are those of the first or of the last notification received. Recipient notification agents should choose those of the first notification, but may choose those of the last notification.
Recipient notification agents must consider two message store locations to be identical if either
The purpose of noting the RNASP client's IP address is to allow recipients to impose filters that exclude particular RNASP clients. In furtherance of this, recipient MUAs should, when displaying lists of message notifications to users, include the RNASP client's IP address (and may map that to a domain name and display that in addition).
A recipient notification agent's notification processing policy is the primary weapon that recipients have against originators. Recipient notification agents decide how to process notifiations based upon global policies set by their owners and per-recipient policies set by individual recipients.
Recipient notification agents act on the principle that notifications from message stores are potentially hostile. Message stores owners may potentially be in collusion with message originators, or message store softwares may simply be badly written and behave abusively.
Recipient notification agents also may simply discard, after recieving, and with no indication to the notifier, notifications that match set criteria. For examples:
Recipient notification agents may discard notifications that reference particular individual messages.
Recipient notification agents may discard notifications that have been sent by a specific account at a specific message store.
This is the weapon used by recipients to block communication from a particular (unwelcome) originator, without blocking communications from other (innocent) originators who happen to use the same message store. It requires that the recipient trust the message store not to allow originators to employ a never ending succession of different accounts.
Recipient notification agents may discard notifications that reference specified message stores.
This is the weapon used by recipients to block all communication from all originators who use a particular message store. Its existence is the incentive for message stores to not act in collusion with nuisance originators, and to respect notification silence commands from recipients reasonably promptly.
Recipient notification agents may discard notifications sent from RNASP client IP addresses that are not associated with the message stores that they reference.
This is one of the weapons used by recipient notification agent owners to prevent attempts to impersonate a message store. (If a message store generates its message identifiers in the recommended manner, such attempts should be fruitless anyway, and such impersonation is thus little more than a nuisance to recipients, who find spurious notifications for messages that do not actually exist.) Recipient notification agents may (using some means beyond the scope of this specification) determine which IP addresses are the RNASP clients of a given message store, and ignore notifications purporting to be for messages on that message store sent from any other RNASP clients.
Recipient notification agents must not assume that message stores connect to their RNASP services using the IP address(es) on which those message stores provide their own MSRAP services. Recipient notification agents must not discard notifications solely upon the basis that the RNASP client IP address does not match the location of the message store given in the notification.
Recipient notification agents may discard notifications that don't reference message stores by domain name.
This is the weapon used to make it more expensive for nuisance message store owners to set up "throwaway" message stores.
Recipient notification agents may also employ (via means that are beyond the scope of this specification) blacklisting services that blacklist specific messages, originators, or message stores.