Dave, Steve, John, all:
Let me add several thoughts along these lines:
NNTP has since day one had the capability to retrieve headers (HEAD),
and later specific headers (XHDR, et al). I tend to think that this
isn't enough bang for the buck to completely rearchitect SMTP around
such a notion.
Early in the discussion, I thought we were talking about the envelope.
Validating the envelope seems to me useful, if only because it provides
a way to reduce the number of bytes sent, and believe it or not, this is
still a problem in certain parts of the developing world, where
bandwidth is still expensive. Right now some solve the problem with
upstream filtering. That has its own set of problems that are as much
political as technical.
John mentioned CHUNKING. The reason CHUNKING hasn't taken off is that
it was intended to address the idea that it would be possible to run out
of resources within DATA, and that this should be signaled. While
theoretically possible, I don't know that CHUNKING would have made any
difference to either end from this perspective. I don't think it will
do much in the context of spam either, since it requires a certain level
of cooperation on the part of the client to CHUNK a header. Not that
one couldn't encourage it, but is it worth it?
Eliot
On 10/29/09 10:57 PM, Dave CROCKER wrote:
Steve Atkins wrote:
It would be very, very nice to have an ESMTP extension that
allowed sending just the headers of an email, waiting for a
2xx or 5xx response, then sending the body. And that's the
general solution to this sort of problem, though a little broader
in scope than is really appropriate for the DKIM forum alone.
Seems like the SMTP Clients with mail that would get dropped after the header
would not be inclined to implement the option.
But perhaps it would still have uptake, presuming bad authors are different
from
bad transmitters...
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html