Talk:Forwarding

The definition for forwarding needs to be much more specific. Here is a suggestion:

Forwarding is the act of transferring a message to another recipient address. The change in recipient address is what distinguishes Forwarding from other types of relaying. Relays using the SMTP protocol implement Forwarding by changing the address in the RCPT TO command.

Forwarding is a fuzzy SMTP term, also because of how it is used in section 3.9 of RFC 5321. In addition, forwarding in our sense can be also done by a backup MX, without changing the envelope recipient. Ale 17:51, 21 December 2008 (GMT)

We need to avoid the fuzzy terms, and get very specific about what we mean. We already have a general term, relaying, which includes Forwarding and other actions, such as the MX relay you mentioned, open relays, and relays used as transmitters on behalf of domains wanting better deliverability. Each of these forms of relaying has its own set of problems, and if we lump them all into "Forwarding", we won't be able to come up with a simple solution to the "forwarding problem". For example, a backup MX must check periodically to see if the primary MX is up, and then transfer all the mail it has accumulated.

Conversely, there are things we will ask of Forwarders that we don't expect a backup MX to worry about, because there is a direct relationship between the backup MX and the primary MX. They must be "tightly coupled", presumably under one management, so the authentication requirements we expect Forwarders to abide by don't apply. If we ask all relays to set up authentication records, we will have a huge problem with non-compliance.

The fundamental reason for the "forwarding problem" is the lack of a prior relationship between the Forwarder and the MDA (or downstream Agent). We should limit our definition of Forwarding to just those situations that are likely to have this problem. The narrower definition is also what I believe the SPF community wants. --Macquigg 20:01, 21 December 2008 (GMT)

I mostly agree with your analysis. However, there is one reason why it may be convenient to keep the definition fuzzy until the solution will have been analyzed more thoroughly.

One reason why backup MXes need to couple with their primary is to learn what mail addresses they should reject. Traditionally, they don't have an explicit list of forwarding recipes, and deduce them from the MX records. By having an authentication record for each user they could actually create a list of valid addresses. Users preferences, e.g. about DNSBL checking, could be transferred by the same mechanisms that will have been built for explicit recipes --when it will have been built, that is.

When spam wasn't a relevant problem, ESPs used to exchange or buy backup MX services from third parties. Helping to reinstate that possibility would be a plus. Backup MXes are not the primary concern of the FixForwarding solution, though. If we will realize that there is no piece of software or configuration setting that can be conveniently shared between the two problems, we will stop considering the second one. However, I don't think it's advantageous to blow that chance before realizing if that's the case. Ale 06:35, 22 December 2008 (GMT)

OK, we'll keep the definitions fuzzy on the main pages, and I will try to clarify each time I am sssuming a more specific definition. When I capitalize a word like Forwarder, it means the definition is special.--Macquigg 18:45, 22 December 2008 (GMT)