forwarding agreement

A forwarding agreement is the procedural data that matches a forwarding recipe. It contains an agreement-ID and a password, the forwarder-ID, the category, the user-IDs, the URL where the agreement can be renegotiated, and a policy. In addition, a forwarding agreement implies that the relevant forwarding recipe exists at the forwarder's and its policy matches the one in the agreement.

Doubly linked vs. singly linked lists

Introducing forwarding agreements is the major point of the solution designed in this site. Current forwarding practices resemble what is known in programming as a singly linked list. Forwarding agreements transform that into a doubly linked list. (See wp:Linked list.)

Data fields

agreement-ID

The agreement-ID may be the remote alias name, the list-id, or the newsletter name. It is the name associated with the password for SMTP Authentication. For static recipes with a single recipient, this may coincide with the recipient's user-ID if deemed useful for saving a db lookup.

forwarder-ID

The forwarder-ID identifies the forwarder as an entity, organization, or individual. Identifying who is the forwarder is the main criterion for quickly granting agreements. In addition, when sending multiple messages in the same session a forwarder may change agreement-ID by using the AUTH parameter to the MAIL FROM command, if both agreement-IDs share the same forwarder-ID.

category

An agreement may be established for different scenarios that imply forwarding, as described in section 3.9 of RFC 5321, Mailing Lists and Aliases. The category identifies what type of forwarding recipe corresponds to the agreement. The recipe can be static, i.e. manually edited configuration data, or dynamic. A tentative list of categories is as follows:

• single recipient static,
• multiple recipient static,
• mailing list,
• newsletter,
• backup MX.

Sometimes static recipes can be edited using web forms or other remote mechanisms. The key difference is that static recipes allow a single user with enough permissions to edit multiple addresses at once, e.g. by providing a comma separated list. Dynamic recipes allow to independently add/delete single addresses without even letting the relevant user know whether there are more addresses on the list.

Mailing lists have a time-honored mechanism to subscribe/unsubscribe by email, web form management has been added on top of that, and the software designed to manage forwarding agreements may act compliantly. Any list that is not, strictly speaking, a mailing list, is a newsletter.

The category is not supposed to change during an agreement's life-cycle, thus some of the above distinctions may be dropped.

user-ID

The user-ID identifies the local recipient(s) to whom forwarding is granted. Even if database orthogonalization is used, agreements are counted according to their multiplicity.

URL and policy are described below.

Establishing a forwarding agreement

The sender has to know that it is forwarding a message. This may not be obvious in case of static forwarding recipes. That can be done by tweaking the envelope sender specified in the -f command switch as described here.

An MX server who accepts forwarding agreements shall advertise it on the EHLO response, providing an URL for starting the agreement setup.

Triple handshake

1. When forwarders visit the advertised URL, they post the URL where the policy may be negotiated.
2. Upon receiving that data, the server in turn visits the supplied URL and negotiates the policy. A successful negotiation will conclude with a token for visiting yet another URL, for setting the password.
3. If the previous step concluded successfully, the forwarder can now visit the completion URL and set a password for the specific account.

At any step, either party may interrupt the automated process and require human intervention. In certain conditions, e.g. when the recipient already knows the sender, the process should conclude rather quickly; an SMTP implementation may run the above procedure on the fly when it realizes that an agreement is missing.

URLs

All URLs involved in managing forwarding agreement shall obey the same basic protocols. Unlike URLs mentioned in, say, RFC 2369, the behavior of each URL type shall be fully specified, so that the process can be carried out without human intervention. (To say that human intervention is not necessary does not imply that it is not possible, see below.)

For the time being, let's assume that each URL serves SOAP or REST request/response pages under HTTPS transport. An advantage of using an existing framework is that it avoids having to specify any encoding, multiple lines syntax, and similar kind of stuff; experience published about NETCONF can be used as a guideline, see RFC 5381. Lisa does not like SOAP[1], REST looks simpler[2]. (See also Using XML in Internet Protocols.) HTTPS as a transport allows secure password exchange; in addition, the certificate and its signing authority can be taken into account when deciding to grant the agreement (but see also Credentials and cryptographic support.) SOAP has further security options and WS-* features, but for the time being they don't seem necessary.

We define the following URLs:

• the EHLO advertised URL,
• the policy negotiation URL at the forwarder's, and
• the completion URL.

The first and last ones are served by the target MTA.

Using and maintaining agreements

An MX server needs a database to store its agreements. Besides dedicated web procedures, the SMTP server software will consult the database for authenticating logins. Ad-hoc RCPT filters will check that the authenticated (or current) agreement-ID is granted permission for each recipient. Either all MXes in a given domain share the same database, or single hosts or groups of hosts maintain their own copies. In the latter case, they must advertise different EHLO URLs.

Note that the user-ID address given in the agreement may well be an alias. Mailbox owners may want to browse what forwarding agreements exist for their addresses. Thus, it is useful to have an owner to user-ID index to find all involved aliases. The policy negotiation URL at the sender's must be capable of serving similar queries: given a user-ID it must find in its local databases all aliases that deliver to the given mailbox, which is then forwarded, along with any granted agreement. That way it is possible to recursively browse all the mail addresses that eventually result in mail arriving to a given target mailbox. The implementation must be quite tightly integrated in the mail server software, accounting for postmasters who manually edit forwarding recipes.

The primary negotiation that a forwarder must grant is to terminate the agreement and hence stop that forwarding. Alternatively, static recipes may be disabled causing the relevant server to supply responses like

551  User not local; please try <forward-path>

It is the users' right to require complete deletion of all of their data at a given place. Using this scheme also for mailing lists would provide a unified way to unsubscribe.

Policy considerations

For static agreements, the policy shall prescribe what boundary filters the forwarder (i.e. the sender w.r.t the agreement, when it acted as a recipient of the forwarded message) enforces for a specific recipient.

For newsletters and mailing lists, the policy may store additional data related to the opt-in operation, e.g. the GMT date and public IP a web request came from.

The sender may be exempted from DNSBL checks. SPF checks should never be done for forwarded messages.

Depending on the SASL mechanism being used with SMTP Authentication, the password may have to be changed more or less often.

In addition, the forwarding recipe policy must be matched.