IM2000 Recipient Notification Agents

Recipient notification agent services

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 notification submission service

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 notification query service

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.

Mailbox names

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

Message notifications

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:

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).

Notification processing policy

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 also employ (via means that are beyond the scope of this specification) blacklisting services that blacklist specific messages, originators, or message stores.

© Copyright 2004-2004 Jonathan de Boyne Pollard. All rights reserved. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp information is preserved.