completion URL

The completion URL formally completes a forwarding agreement handshake by setting a valid password; in addition, it serves those facets of the negotiation that imply setting parameters on the server, e.g. the Feedback Loop address, and agreement termination. The server of the URL is an MTA that has negotiated an agreement. The client is an MTA configured with the forwarding recipe that the agreement is linked with.

The client is a Mediator according to Internet Mail Architecture[1]. Client and server are also respectively named Forwarder and MDA according to MHS[2] terminology.

Semantics

This URL allows the client to set various types of data. It may coincide or not with the EHLO advertised URL, depending on the server convenience. If it coincides, it must obviously accept forwarding requests, but they are not considered here.

Every request to this URL must post the elements that authenticate the client and identify the agreement:

• forwarder-ID,
• the agreement-ID, and
• a valid (although possibly expired) password.

A request may contain one or more of the following data.

password

A password may be expired as far as SMTP Authentication is concerned, but still valid for setting a new password using this URL. Changing the password should be the first client concern in this case. The client may decide at any time that the password should be changed, after receiving a 535 Authentication credentials invalid response from the relevant SMTP server, or after its password has been reset at its policy negotiation URL.

Notice that a forwarder may have multiple agreements with the server. Each agreement has its own password.

The server may reject weak passwords.

Feedback Loop email address

The server must accept this address, and forward there any report associated with mail sent under the relevant forwarding agreement. The server should have an automated reporting mechanism; if it doesn't, this address can still be used to send complaints manually, in the correct format. The Abuse Feedback Reporting Format (ARF)[3] is assumed.

The server may reject invalid email addresses.

policy negotiation URL

The policy negotiation URL is used to recognize forwarders in case of new forwarding requests, thus it should not change. However, organizational changes may require that host names and/or locations be changed. Changing it for the given agreement may result in changing it for all agreements stipulated with the same forwarder-ID, according to the database design at the server. If not, the client should change the URL also for all existing agreements before requiring new ones. If not, its requests for new agreements may be rejected or generate a different forwarder-ID.

Forwarding agreements are not transferable, and the forwarder-ID cannot be changed. Hence, changing the negotiation URL is not meant for that. In case a whole line of business is merged or transferred, changing the URL may serve to cope with the relevant organizational changes.

The server may refuse to change the URL. In that case, a forwarder should terminate existing agreements and enter new ones.

agreement termination

Mailing lists can be canceled, and static recipes can be deleted, on the client's own initiative. When that happens, it should be notified using this URL. The notification should be done after the deletion. The server may verify the deletion at the negotiation URL. The client may give this notification after the server issued a delete command at the negotiation URL. If the client issues a deletion on its own initiative, it is its responsibility to also terminate any relevant forwarding chain upstream.

Server response

The server must fail in case of bad identification or authentication.

Positive server responses must include a list of the accepted settings. In case of URL changes, it must specify if the URL has been changed for more than one agreement.

Successfully setting a password for the first time concludes the handshake, and the forwarding agreement is considered undertaken.