> > Of course, that is why it's called "Store-&-Forward" mechanism.
> > But it does not guarantee "How soon it will get there!"
> Store-and-Forward comes from the old days when people had dialup
> modems. The best guarantee is to deliver directly without forwarding.
> Of course, if you want to send a message but can't reach another
> server you have a problem-- same as if you used http/ftp
> I wonder why spammers are the only ones to figure this out. The
> tragedy is that a good way to get rid of junk mail is to delete mail that
> doesn't appear to be store-and-forward.
More generally, just because a protocol has a capability doesn't mean you have
to use it.
General network-wide email facilities need store and forward. But nothing
prevents you from setting up a special SMTP link just for EDI that bypasses
general email facilities. Such a system is only constrained by the
characteristics of single-hop SMTP, not by the characteristics of what's
deployed elsewhere.
Lots of email software exists that can be configured this way.
> > Maybe we need new email service that guarantee the delivery
> > within a given time, e.g., Fedex or UPS style guarantee delivery. :-)
> You can use Fedex to send a package to your neighbor, but it's more
> reliable to walk over and give it to them personally. Same for smtp
> email.
I've always found the notion of a delivery guarantee somewhat amusing. in the
final analysis nothing can actually make such a guarantee. No amount of
protocol shopping changes the fact that the bits don't get through when the
network is down. You can try harder and you can lower the number of
intermediaries and you can guard against various failure cases, but in the
limit the various protocols tend to coalesce in this regard.
Ned
|
