From: Michael(_dot_)Dillon(_at_)btradianz(_dot_)com
[mailto:Michael(_dot_)Dillon(_at_)btradianz(_dot_)com]
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf