forwarding recipe
A forwarding recipe is the procedural data by which a mail server can build a new envelope for an existing message before re-injecting it into the mail system. It includes the forwarded address that the original message bore, one or more new recipient addresses to whom the re-injected message is destined, and a policy. The policy determines the new envelope sender address, at least.
Common forwarding recipes
Static recipes
Historically, recipes were written in sendmail's .forward files in a recipient's home directory, in order to elicit specific forwarding behavior from the server when a message is received at a given mailbox. Recipes have to be addressable by their forwarded address, so that the software can find any relevant recipe upon message reception. Obviously, the software that implements the SMTP server dictates the format that recipes have to comply. Depending on the implementation, the data that conceptually makes up a recipe may be spread among several files.
A pipe character (|) in a .forward file allows executing external programs. Similar concepts work for .qmail and .courier. A forwarding recipe may consist of
| sendmail -f postmaster@example.org newrecipient@example.com
Notice that the forwarded address is implied by the location on disc where the recipe is written. In addition, the behavior triggered by messages bouncing to postmaster@example.org is conceptually part of this recipe but is specified somewhere else.
Newsletters and mailing lists
Dynamic recipes are managed by specialized software. Such software has well defined schemata to precisely define what messages are forwarded to what addresses. A number of best practices documents exists that specify how to reliably send bulk mail, e.g. MIPAssoc. In case the model proposed here will be adopted, it may be added to the list of things to do, but it will have to be done on a per-package basis.
Backup MXes
Main article: Backup MX
A backup MX also does forwarding. What is special in it, is that forwarding recipes are implicit.
Quest for agreement
A forwarding recipe introduces a new segment in the message path, which should be considered within the recipient's realm. In fact, the newrecipient address is wp:personally identifiable information of its owner, therefore its owner should have explicitly given a permission to use it in a certain way. That permission, also called opt-in, is not routinely asked for. Even when it is, e.g. when subscribing to a mailing list, the relevant forwarding recipe is stored at the forwarding host only. Forwarding agreements are proposed to obviate this limitation and let a forwarding recipe be known and acted upon by its owner, directly from the target host.
Envelope sender tweak
An easy technique to let the sending software know that a message is being forwarded is by changing the envelope sender to some special value that is only understood within the host/ADMD. For example
| sendmail -f ff=keyword=param=postmaster@example.org newrecipient@example.com
The line above provides a keyword and a parameter for using an existing forwarding agreement, or start negotiating one. The sending software, upon seeing that the remote MX accepts the ff model, shall search a local database for a record corresponding to newrecipient@example.com, the remote MX, and the keyword parameter. That record is considered a complement of the forwarding recipe.
If the record is found and contains an id/password for logging in, the sending software recovers the original envelope sender from the Return-Path header and forwards the message according to this model. For ongoing negotiations, the record may contain an indication to either queue the message or send it normally until the negotiation completes. Otherwise, the keyword and parameter can be used to load a configurated environment and launch the first step of the negotiation. In this case the return code indicates whether to queue the message or sending it normally.
Sending the message normally, which is also done in case the remote MX does not support FF, implies using the default envelope sender, in this case postmaster@example.org. The tweaked envelope sender never leaves the relevant host. However, it may be set on an internal host inside the same ADMD in case the existing forwarding recipe is not on a boundary host.
Policy considerations
In its simplest form, a forwarding recipe may be difficult to manage. The complexity may increase depending on who and how can create mailboxes and recipes on the system, what spam filtering options are available, and spam reporting mechanisms.
On a small system where only the postmaster creates mailboxes and recipes, for example, a recipe as exemplified above may make sense. Upon receiving a delivery failure, the postmaster should decide whether to drop the recipe as the target address becomes unavailable or to advise the final recipient that the relevant mailbox is full. Larger systems will require to automate that behavior, therefore it becomes necessary to define exactly when and how each operation is performed. For example, a policy can specify a different behavior for a mailbox full situation if an alternative email address or, say, an SMS-enabled phone number are available for advising the final recipient.
A policy may contain various configuration items. It can provide for a number of different states, so that the server can stop receiving new mail in certain cases, possibly requiring that appropriate local responses are given, e.g.:
551 User not local; please try <forward-path>, or 251 User not local; will forward to <forward-path>
Two flags are as follows:
- enabled: mail is accepted, and
- non-disclosure: the target address shall never be revealed.
As a forwarding recipe's policy is limited to local behavior, the non-disclosure flag affects the text in the server response, and do DSNs and MDNs as for lists. See RFC 3461, 5.2.7.4 confidential forwarding addresses; RFC 3798, 6.2. Privacy; RFC 3885.
