> From: Michael.Dillon@xxxxxxxxxxxxx [mailto:Michael.Dillon@xxxxxxxxxxxxx] > I don't disagree that band-aids can make things better for a > while. Or that huge efforts to create new band-aids are > better than tossing the whole thing out. But I also believe > that the band-aids are not a long term solution and that a > series of band-aids is an extremely expensive way to reach a > satisfactory email architecture. The difference between a band aid and an architecture is whether you have a coherent strategy. Let us imagine for a moment that you are right and we need to replace SMTP entirely. Its not a completely ridiculous notion that we might want to shift to (say) BOONDOGGLE a multi-media protocol that integrates synchronous and asynchronous modalities, text with video and sound. A multi media boondoggle that seamlessly integrates the entire spectrum of network communication from mail to IRC to virtual reality. OK you still need an email address. And you definitely need a strategy for transition. So in the transition period you need a mechanism to signal to potential email senders that you support BOONDOGGLE. How to do this? Sounds to me like you would need something that looks like an MX record. How about an SRV record? _BOONDOGGLE._tcp.example.com SRV 80 1 1 1 boondoggle.example.com Might be nice to be able to specify that the boondoggle server is the default for the zone. **.example.com PREPTR _preptr.example.com _BOONDOGGLE._tcp._preptr.example.com SRV 80 1 1 1 boondoggle.example.com (** being an administrative wildcard that is expanded by the server to any node that does not have a record of the type specified regardless of whether or not the node exists as discussed on the DNSEXT list many times). Might be nice to be able to discover the entire range of mail like services supported on example.com: **.example.com PREPTR _preptr.example.com _BOONDOGGLE._tcp._preptr.example.com TXT "SMTP={STARTTLS} JABBER BOONDOGGLE SQUALID" > Yes, there was accountability, but it was not in the email > architecture and it was wholly unconnected to the email > protocols and services. It turns out that a reliable email > system needs accountability imbedded in it, not tacked on as > an afterthought. Why does it turn out to be so? Why would an entirely new protocol behave any differently to SMTP+DKIM in this regard? Wouldn't it be a good idea to at least experiment in trying to extend SMTP before attempting to define an entirely new protocol? > Even knowing the last email hop with a high degree of > confidence will allow accountability. In order to know this > with a high degree of confidence, the organizations must have > a relationship, probably contractual, and must be in contact. Nope, empirically not necessary. Over a billion dollars a day of E-commerce enabled by VeriSign class 3 SSL certificates demonstrates that you are wrong on this. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf