on 5/28/2003 11:17 AM Iljitsch van Beijnum wrote:
I don't think moving to some kind of SMTPng is quite as impossible as
people seem to think.
Although I'm all for an SMTPng, it's important to delineate the benefits
that would be served from such an approach, and also some discussion on
how difficult this would be.
For example, a protocol would not be able to confidently deter the
transfer of unsolicited commercial email over a valid connection by
itself. However, an SMTPng by itself could specifically address the issue
of accountability.
The accountability information could in turn be used to help fight
forgeries, and this information would help to combat some kinds of spam.
It would help get a spammer's account yanked due to AUP violations since
you would be able to prove where the spam came from (assuming the ISP
enforced an AUP that prohibited spam). By the same measure, it would also
be useful for authoritatively rejecting mail from those ISPs who don't
enforce AUPs or who don't prohibit spam, and it would be usefule for
authoritatively rejecting mail from organizations who are known to be
spammers themselves (in these cases, it would effetively allow for better
blacklists). If we had a way to validate the transfer path (such as using
recursive signatures on the transfer path), then the accountability would
be further heightened by allowing us to reject any mail that had passed
through any of the known-offender networks. These would all be
improvements over what we have today, giving us better accuracy in our
rejection policies, but still allowing some spam through the network (eg,
first offenders).
Improved accountability would also substantially improve the enforcement
of anti-spam laws, should any exist. Since the improved accountability by
itself would not be sufficient to stop all spam, there would still be a
need for laws. Those laws would be significantly strengthened by the extra
accountability information. A strong law in conjunction with accurate and
credible filters would cumulatively be very effective in the fight against
spam, possibly even good enough to "win" the war.
An SMTPng could also help against forgery-related problems. This includes
common spam-related fraud, but also includes outright fraudulent
misrepresentations, worms, etc.
Co-existence with legacy SMTP is a problem. If it easy for spammers to
avoid using SMTPng, then they will stick with legacy SMTP. There are
operational ways for reducing the exposure (including heavily discounting
mail from SMTP during post-transfer filtering), but the hammer of law is
still going to be necessary to kill that problem. At the same time, if we
know that we can't directly fix this in protocol, then there is some
validity to the argument that we can just keep using the existing SMTP and
hope that laws do the rest. In that regard, the substantitive gain from
doing all of the work necessary is in the improved accountability that
SMTP *cannot* provide in its current form (even if all of the options such
as STARTTLS are used).
This is how I think an SMTPng might work:
C: <connect>
C: <send certificate>
S: <validate host identity>
S: ok
C: <request transfer>
S: ok
C: <send transfer headers>
S: <validate sender identity>
S: <validate transfer path>
S: <validate recipients>
S: <...>
S: ok
C: <send message headers, possibly encrypted/signed>
S: <validate headers (eg pass/reject contents)>
S: ok
C: <send message body>
S: ok
C: <close>
That gives a lot of data to validate and substantially improves the level
of accountability over anything that SMTP can offer in its current form.
There are lots of other things that could be incorporated once this was
done which would further add to the value proposition. In fact, the
long-term value to an SMTPng would be to address all of the other
mail-related issues that are also already outstanding besides just the
credibility shortcomings. This includes features such as encrypted message
headers (rather than just bodies), true i18n support, per-recipient
message routing (similar to the expiremental MB and other per-recipient
RRs), end-to-end option negotiation across the messaging network (in
addition to the hop-by-hop negotiation we have now), extensible OIDs as
response codes, reduced round-trip latencies, and more.
Things that would probably be needed to support any of this:
- new transfer protocol syntax (replace HELO with certificate
exchange, for example)
- optionally a new submission service
- URI and DNS types for the submission services
- new message routing services separate from MX routing
- new message format (separating transfer headers from message
headers from message contents, which are all one unit currently)
- MIME types for each message component, for compatibility with
legacy mail stores
- gateway rules for conversion betwen 821 and ng
This is a lot of work for the sole purpose of improving accountability but
it would probably be necessary in order to get beyond what SMTP can
provide today. It is much more justifiable if we are going to reinvent
mail for other purposes at the same time.
I also want to reiterate that we still need laws regardless of whether we
go to a new SMTPng or stay with SMTP. My feeling is that we (collectively)
should go ahead and start pursuing legal enforcement methods for use with
SMTP now, regardless of what we end up doing over the next five years on
the technology front. As such, I think the legal-interaction issue needs
to be addressed first.
I am also in favor of reinventing mail. It's a standing joke against the
IETF that people can readily commit flagrant forgeries in one of the most
important technologies of our time.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/