First vs. last -- Need and interest

Folks,

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"?
d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net