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