My strong belief is that a proposal for a new protocol that
does the same thing as SMTP but slightly better is a total
non starter. No matter how much better the protocol is the
cost of transition will dominate.
Right! It is not the protocol that is at fault, it is the architecture
in which the protocol is used. I once lived in a house that had not been
designed by an architect. It started life as a granary, then was
converted to a tiny house by installing a kitchen sink and a bathroom.
Then the owner added a bedroom on one end, extending the gable roof.
Next the house was doubled by extending it to one side under a shed
roof. At this point the owner's alcoholism was affecting the quality of
the work. Various corners were cut such as a single-pane mobile home
window. Another bedroom was added to the other end of the house by
extending only the shed-roof section. No electrical outlets in this part
and only one tiny window. Finally, when the owner's alcoholism was well
advanced he filled in the gap beside the last bedroom with a hand-poured
concrete floor, and a roof and walls made with poles (with the bark
still on) and scrap plywood. This became the entrance foyer to the
house. Shortly thereafter, I bought the house, my first home purchase.
The Internet email architecture is a lot like this house, with add-ons
and patches. The latest round of SPF/DKIM stuff feels a lot like that
last room built with poles and whatever scrap was handy. I just feel
that given the lessons learned in scaling an email system to global
proportions, we could do better by taking an overall architectural view
to the problem, and coming up with a more robust architecture.
The only way that I see a new email infrastructure emerging
is as a part of a more general infrastructure to support
multi-modal communication, both synchronous and asynchronous,
bilateral and multilateral, Instant Messaging, email, voice,
video, network news all combined in one unified protocol.
Wrong! This is a sure way to invite second-system effect. Read this
http://en.wikipedia.org/wiki/The_Mythical_Man-Month or better yet, read
the book itself. Sometimes it is better to leave things out of your
design than to include them all.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf