forwarding agreement
A forwarding agreement consists of the procedural data corresponding to a forwarding recipe. It contains the recipient and the list-id, which are keys to override any dmarc=fail in the forwarded messages. The record can also contain all the data posted by the forwarder, such as the agreement-id and the base email address. A receiver can also monitor the flow, for example, by recording the number of messages, the date the agreement was negotiated, and the date the last message was received.
Establishing a forwarding agreement
The sender has to know that it is forwarding a message. This may not be obvious with static forwarding recipes. These can be adapted, for example, as described here.
An MX server that accepts forwarding agreements must advertise it with a DNS resource record. The DNS record is located in the _fixforwarding subdomain of the domain that qualifies the destination address. Its fields allow the forwarder to determine whether it meets all the requirements, and, if so, the post address to which to send a request form. A forwarder should check the DNS record for each new forwarding recipe, or periodically for old recipes that have not yet been authorized.
Authorization to forward messages that may fail DMARC checks will be sent via email to the base address provided by the forwarder in the request. The receiver will need to ask their user to confirm the forwarding recipe, so a response may take a few days. For new forwarding recipes, the user confirmation request is effectively equivalent to a Confirmed Opt-In (COI), so depending on the forwarder's confidence in receiver's operations, it can be omitted or announced.
To be continued
...
Using and maintaining agreements (old stuff)
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.
