policy negotiation URL
The policy negotiation URL is where a forwarding agreement is established and maintained. The server of the URL is the forwarding MTA that applied for, and possibly obtained, an agreement associated with a specific forwarding recipe. The client is the MTA who granted (or is going to grant) the agreement, or some other entity acting on behalf of one or more of the final recipients involved in the forwarding.
Please note that the client and server roles are exchanged with respect to the other two handshake URLs. The server is a Mediator according to Internet Mail Architecture[1]. Server and client are also respectively named Forwarded and MDA according to MHS[2] terminology.
Semantics
This URL must accept different types of requests. Various queries are provided for learning the current settings and the available options. Corresponding actions are provided for altering those settings. For an HTTP oriented URL, it might make sense to differentiate the query part of the URL itself. However, a one-to-one correspondence between a forwarder and its policy negotiation URL simplifies the task of identifying the forwarders, for authentication purposes as well as database design.
Every request to this URL must post the elements that identify the recipe and the client, as given in the forwarding request:
- the recipe-ID,
- a valid recipe-KEY, and
- the agreement-ID.
The recipe-ID and the agreement-ID unambiguously identify the relevant (target) recipient address(es). The recipe-KEY authenticates the client.
The next element in the body of the request may have a local name of get or set, according to the type of request that the client posts. In the following, we describe the meaning of the data. The format will have to be worked out so as to allow, for each keyword associated with a get or set verb, a list of values, or named-index=value pairs. Example keywords are as follows:
- DNSBL, a possibly empty list of available DNSBLs accompanied with a boolean value that tells if they are active or not for the relevant recipe,
- SPF, an array of boolean reject/accept values, one for each possible SPF result, and
- flags, the enabled and non-disclosure values as mentioned here.
The recipe-KEY itself can be changed by the client, for security reasons. The client usually is the final MTA; however, it may in turn forward messages under a further agreement. That is to say, the client may also be a Mediator. In that case, it must ask for, and obtain, additional receipt-KEYs that it will eventually return to final MTAs, so that they can access senders recursively.
For static recipes and completed agreements, the server must honor a request to get forwarders, that a client may issue to learn the chain of agreements that have already been established between the server playing the role of target host, a.k.a. MDA, and third parties playing the role of Mediators. This is where the additional receipt-KEYs mentioned in the previous paragraph are returned. The forwarders keyword is going to be get-only, in the sense that set forwarders is not going to be supported: The final MTA will have to access each upstream host in order to learn or change policy settings.
In addition, forwarder-ID, password, completion URL and determination are set-only elements that must be set once, before the agreement is completed. The server may refuse to change its forwarder-ID or the completion URL afterward. The password is already expired when it is being set, which forces the use of the completion URL. Setting a void password equates to saying that the old one is expired. The determination must be set if the client does not set forwarder-ID, password, and completion URL: it is a human readable text explaining why the client acted the way it did.
Finally, besides get and set, a delete element may be posted to a completed agreement. It means to erase any data concerning the forwarding recipe, as far as the relevant recipient addresses are concerned (See below.)
Credentials and cryptographic support
When using HTTPS transport, the client should download and verify the certificate being provided. This is done a couple of layers below SOAP. (It can be done within SOAP if we throw in more WS-* stuff. However, requiring that may make the protocol overly complex.) The reputation of the certificate signer could be taken into account when deciding about the trustworthiness of a new forwarder. However, most certificates are signed by just one CA, and most CAs don't spend much effort into verifying what they sign.
An intriguing subject is the possibility to get/set credentials. A credential or certificate, in this context, is an asymmetric key signed by some other MTAs. This might be done with classical X.509 PKI concepts and tools. However, a Web of Trust, à la PGP, seems better suited for this task. MTAs already publish cryptographic keys. Infrastructures and key servers for signing and revoking keys already exist, so all what is necessary is to provide a list of pointers.
An MTA who has been honoring a forwarding agreement for some time, might ask its peer to certify that. The receiving MTA should have collected enough data to conclude that a forwarder is not a spammer, before signing.
An MTA who is in doubt whether to grant an agreement to a given forwarder might get the list of credentials and verify the signatures of any signer it knows to be a trustworthy peer. The number of known signers would then be a valid complement of the relevant whois information. For example, the client may check how many months ago the domain has been registered, if the names of its responsible staff are unencumbered by privacy protection, then, say, multiply that number by the umber of recognized signatures, and grant the agreement if the result is more than a predefined minimum. Taking into account the tree of indirect trust (with suitable coefficients) might result in a reliable algorithm. However, that may complicate this specification more than what it is worth.
Server response
The server must fail for any unrecognized or invalid identification, in case the client comes in with a nonexistent receipt-ID, or invalid recipient address(es). The server should fail with a transient error in case the client wants to enable an unsupported DNSBL, and similar errors possibly due to lack of synchronization.
For valid get requests, the server must include a list of values that the client may modify in a subsequent set request.
Positive responses should always include the status of the agreement. It remains underway until a forwarder-ID/password pair and completion URL have not been set. Afterward it switches to pending completion until a valid password has been set by visiting the URL thus provided. Eventually it will be complete. The server should react to a determination setting, that is the client's refusal to grant the agreement, by deleting all data, as if receiving a delete verb.
It goes without saying that, after it has acknowledged a given set of options, the server must honor those settings. Effective changes are not necessarily synchronous, but must be carried out withing a reasonable amount of hours. If this URL is being serviced by a different machine than the one that hosts the recipe, and the latter is currently down or disconnected, fulfilling the request has to be delayed. Obviously, mail must not be relayed by an MTA which is down or disconnected. Settings must take place within a few hours after that MTA gets back into operations.
A delete request, or a determination not to grant a forwarding agreement, implies to remove all occurrences of the relevant email address(es) from the forwarding recipe. For static recipes, that means to delete the recipe and the mailbox; users might just disable forwarding otherwise. The status of the agreement switches to deleted, and the server shall continue to acknowledge valid requests about it, until the delete operation is actually completed. That is to say, the recipe data and keys used to service this URL must be deleted after the recipe data that make forwarding possible. Thereafter, requests will fail.
