[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Dave Crocker <dhc@dcrocker.net>
cc: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, "Edmon Chung" <edmon@neteka.com>, ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Sun, 08 Sep 2002 22:15:33 -0400
In-Reply-To: Your message of "Sat, 07 Sep 2002 10:26:12 PDT." <5.1.1.2.2.20020907102329.033b0de8@jay.songbird.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: epp via smtp

[Caveat: POSIX, or rather XPG is assumed, not because it is the sole standard,
 but because it (XPG) is something I'm familiar with, and fond of. Like one
 of my kids.

 What follows assumes some set of files contain something of interest, e.g.,
 domain_create.xml, some 935 bytes of XML.
]


Dave,

Example: % mailx epp@f.q.d.n < domain_create.xml

The send-side mail spooling system performs read() of 935 bytes (from the
domain_create.xml file) and performs a write() of 936 bytes (trailing null)
to a temporary file. It proceeds to call gettimeofday() to prepend some 25
bytes of cruft before handing it off via fork()/exec() to another process,
the MTA, sendmail in this case, and unlink() the temporary file.

The receive-side mail spooling system performs similarly, with the spooled
instance of the message copied to some MUA-specific location, then unlinked.
I'll look at Vixie/Avolio and the source RSN to make sure my memory of XPG,
now POSIX, isn't a happy personal fiction.

While the <converted, or a term of your choosing> 935 bytes (plus cruft)
are managed by the two (or more) communicating MTAs, and the original is
optionally deleted at unlink()-time from the originating host (see also
the -r (remove) and the -s (symlink) options to lpr(1), similar semantics),
and not yet writen-and-sync'd into the portion of the filesystem managed
by the receiving or final MTA's spooler, one or more things may occur:

	o normal delivery (hooray!)
	o crash of either endpoint, or the relay(s) (boo!)
	o error of name to adderess resolution (hiss!)
	o network partition (ouch!)
	o sunspots and/or summer vacation (hooray!)

While unlikely, and possibly having only transient effect (that is, having
some temporal semantics such as spooled store-and-forward), these are all
quite different from, to quote my comment to Edmond, 

	[a] cron-driven sequence of shell commands shuffleing a set of
	*.xml files from a test directory to a server's i/o interface

Other than pilot-error, my cron-driven scripts lack the latency properties
and most of these potential, and frequently actual, failure conditions, of
SMTP transport sequences having some similar property of end-point delivery.

What I ment by "convert" was the temporal, and persistence, properties of
delivery of 935 bytes, from those of a file, to those of a message. I'll
pass on the serialization and on-the-wire stuff, other than those three
conditions I've mentioned.

Is it clear that if two processes are functionally indistinguishable,
but temporally distinguishable, or are non-functionally distinct, the
two processes are not identical? It is to me, but there are a lot of
folks a whole lot smarter than me, such as yourself, so I could be off
(comfortably) in a field of my own.

Have I answered your question? I seem to have deleted your last note,
which is sort of my point. Mail's permanence in the hands of a MUA is less
than that of files grazed only by open()/read() sequences of operations
by benevolent filesystems.

Eric

Home | Date list | Subject list