🚀 go-pugleaf

In article <davecb.725911218@yorku.ca>,
 posted to comp.mail.headers,comp.mail.misc,
 davecb@nexus.yorku.ca (David Collier-Brown) wrote:
>
>  This assumes store-and forward, something which is getting
>less and less poplular at time passes, and was never part of
>the RFC world anyway. 

Assuming that for each message sent, one does not
a)	directly open an SMTP connection to the recipient's host
	(assuming such a connection even exists)
and
b)	the SMTP command SEND or SAML (not SOML or MAIL) is used,
	and that on failed delivery the entire message is rekeyed manually
	by the originator
then mail is inherently store-and-forward to some extent.  RFC822 and
RFC1123 both provide mechanisms for routing of mail, which usually is
implemented as store-and-forward. And let's not forget RFC976, which
specifically applies to UUCP mail (inherently store-and-forward).

As the use of computers and computer-based mail grows within an
organization, it is often the case that mail gateways are set up to offload
mail transport handling tasks from individual workstations. Often the mail
gateways will store mail, later forwarding it to a workstation, or to another
machine.  I submit, therefore, that store-and-forward may actually become
more widely used, not less so, within the Internet.

As network topologies and sizes change, it is sometimes enlightening to review
one's assumptions. To take another mail-related example, it used to be the
case that a moderate number of "hops" (say two dozen) could be considered to
be an indication of a mail loop.  Today it is possible to easily reach
several dozen hops (via gateway and firewall machines) even within a small
organization. Result: hop count alone is probably no longer useful as an
indication of a mail loop (if it ever was).

-- 
	Bruce Lilly		blilly!bruce@Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce