[Top] [All Lists]

First vs. last -- Need and interest

2007-02-04 11:33:18


Peter J. Holzer wrote:
I'll try to provide an overview of various proposals

This sort of side-by-side comparison can only be helpful. However I'm not sure whether there is a clear agreement about the goals that will motivate making a choice?

In other words, how clear is it what problems need to be solved? In phrasing it that way, I am really posing questions: 1) What problems are being solved? 2) What is the basis for believing that there is a ready community of adopters for the solution, or rather, that there is a market that agrees that the problems need solving?

The list discussion seems to have focused on the mechanical issues. In looking for a statement of deeper motivation, one of the more crisp bits seems to be:

     "it has become common practice for different recipients to
     have their own content filters, and a single response code is not
     sufficiently granular to accurately reflect these differences."

from Eric's draft. The language does not mention additional reasons for needing responses that are contingent on the content -- and potentially vary for each recipient -- but at least it gives one that is simple, direct and probably compelling. (An other reason includes policies of the receiving MTA operator, possibly independent of the expressed input of the addressee.)

When email protocols were being developed, one of the debates was between having content precede addresses or addresses precede content. Each had its benefits and drawbacks. (In protocol development, header-first vs. header-last is a classic trade-off.) I wouldn't characterize the SMTP choice as arbitrary, but certainly it was not obviously the right choice.

By having addresses first, the protocol permits withholding transfer of the content, if there are no valid addressees. In a world of limited bandwidth and storage, along with any expectation that a substantial number of addresses will be invalid, having the addresses come first is an excellent choice. It is also the reason the protocol was made interactive, per addressee, in spite of the cumulative hassle of network latencies this creates.

To the extent that storage and bandwidth are cheaper and addresses are typically valid, having addresses come after content permits a richer evaluation model by the receiving MTA. In a world of content abuse -- and, yes, per-recipient preferences -- the content-first model seems considerably more appealing than what we have now. However, note that we probably lose the ability to have rejection before content transfer, except for the most basic sorts of rejections, such as being unwilling to take mail from a particular SMTP client host.

The need for communicating richer response information within the session has also come up in the MAAWG community, with a new effort to define response codes that contain information about policy violations, where I mostly view that term as referring to cross-message -- and possibly cross-addressee -- rejections. So, rather than saying "This address doesn't exist" the response might be more like "Don't bother contacting this host until you clean up your act."

This is not exactly the same requirement as is being discussed on this list, but I think it is related. At last week's MAAWG meeting, the interest in an effort to add some SMTP response codes was particularly strong, suggesting that there is a ready market for using the result of the work.

As for stylistic choice between LMTP and an SMTP enhancement, my immediate concern is that LMTP is only for last-hop processing.

However the need for a richer and finer-grained content-related response model is showing up for intermediaries, not just last-hop environments.

LMTP provides responses before content-transfer and after. That sounds pretty appealing, as does using an existing protocol.

Like others, I'm concerned about the added complexity.

I keep wondering whether it isn't just as useful and far simpler to have an SMTP option that says "send addresses after content"?


  Dave Crocker
  Brandenburg InternetWorking