meor(_at_)mail(_dot_)SoftHome(_dot_)net wrote:
The current protocol is just as susceptible to server outages as the
proposed would be.
What you have completely failed to realize is that there are far more
active players in delivering a piece of email than just the servers.
Your proposal forces the user to be "aware" of the state of every single
router-hop and piece of wire along the way. Router crashes in backbone?
Users can't even hit "SEND" for _any_ email that would traverse that
router, either side.
Certainly, that's at first glance "no worse than web". I fail to see
how decreasing the reliability of email to the same (not that good)
level as the web does anyone any good.
What you're also completely failing to see is that server administrators
don't _want_ to expose their mailbox servers to the Internet. That's
where all the email sits, right? All your email ripe for plucking by
hackers. That's why there are gateways and firewalls.
You couldn't email to sites behind gateways. You couldn't email to
sites with intermittent connectivity (either by design or accident).
Senders would have to take evasive action if the link went down in the
middle of transmission. Etc. Trying to send to two people whose
server's connectivity was intermittent exactly out of sync? Impossible.
We're trying to build things that isolate the user from the low-level
behaviour of the Internet, not the opposite.
Requiring end-to-end instant (especially reverse) connectivity is
totally impractical in a one-to-many transmission scheme - which is what
email is - unlike web (except in the rare and unusual case of webcasting).
And finally, as described before, trying to do any sort of centralized
logging or filtering becomes impossible, unless you want to make your
routers SMTP-aware - which is a gross violation of the layering
principle inherent in any well-designed and built networking stack.
They're flakey enough as it is :-(
Your "fix" would break many of the desirable (and in some circumstances
_critical_) characteristics of email that we rely on.
It really is a total non-starter.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg