EHLO advertised URL

The EHLO advertised URL receives forwarding requests; that is, requests for establishing a forwarding agreement. The server of the URL is an MTA ready to grant such agreements. The client is an MTA configured with a forwarding recipe, that is willing to relay related messages under an agreement. As its name says, this URL is advertised by the server in its EHLO response.

The client is a Mediator according to Internet Mail Architecture[1]. Client and server may be respectively called a candidate Forwarder and MDA according to MHS[2] terminology.

Semantics

Visiting this URL constitutes the first of the three steps provided for setting up a forwarding agreement. The URL itself may change as needed, since it is only used once for each request. The clients posts (or sends, if using SMTP transport) the essential data that defines the agreement:

• The recipe-ID as known by the client.
• The recipe-KEY, an authentication code for negotiating the agreement.
• A human readable recipe name.
• The recipient address(es); the target addresses at the server's. The server will transform these into the agreement's user-ID, according to its internal data structures.
• The agreement's category, one of the types defined.
• The policy negotiation URL, where the server will in turn pay a visit.
• Optionally, the forwarder-ID; this is the identity of the client as known by the server, in case the client has already entered into an agreement with the same server.
• Optionally, any evidence that may be relevant. For example, the IP address and GMT date of the user's opt-in.

The tentative list above is meant to comprise all the data to fully describe the forwarder's intentions.

The recipe-ID and the recipe-KEY will be used by the server to identify itself when it will, in turn, pay a visit to the supplied policy negotiation URL. By contrast, the recipe name is what will be visible to users and should meaningfully identify the forwarding. The name may be the incoming address at the client's in the case of static forwarding, or the newsletter or mailing list name.

The client is not authenticated at this stage. If a forwarder-ID is supplied, the server should verify that the policy negotiation URL coincides with the one already stored for that ID. If not recognized, the server must not use the supplied forwarder-ID for making decisions, but may use it as a hint to synthesize the content of the corresponding field of the agreement.

The server should carry out any verification that it wishes. If supplied evidence includes IP addresses that the server can verify, it should do so before they possibly change and before relevant log files are obliterated. Notice that, except for evidence, no IP addresses are involved.

Server response

The server accepts the request by creating an agreement-ID and communicating it to the client. The agreement-ID is a key to all related data, including the recipient address(es). The recipe-ID may be used as a prefix to create agreement-IDs that relate to the same remote recipe.

The server may take several paths. If the server can estimate that the agreement is likely to be granted within a few hours, it should say so. That information is needed by the client in order to decide how to queue the message at hand.

In case of multiple recipients, if the server cannot handle them uniformly it may respond with a temporary failure that includes a list of one or more addresses that can be handled uniformly and are likely to generate a positive response. In general, there should be only one address. However, some cases of static forwarding to multiple mailboxes might be accepted. (It is advisable to forward to a single mailbox that in turn explodes locally to the desired targets, if at all possible.)

If any verification fails, the server may reject the current request and let the client try again with a better one. If the request mentions an agreement that has already been established, the server should just signal that this is a spoof retrial.

If the server requires human intervention, or other lengthy process that may eventually result in negotiating a policy and granting the agreement, it should signal so. In this case the client marks the recipe as having an agreement underway, and continues to relay as usual meanwhile. It is the server responsibility to eventually visit the policy negotiation URL, possibly for the sole purpose of canceling the pending request.

Notice that it may be convenient for the server to grant an agreement to a known spammer for the sole purpose of rejecting any mail identified that way.