Date: Fri, 06 Jun 1997 02:47:07 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: scott@statsci.com, chat@freebsd.org Subject: Re: uucp uid's Message-ID: <199706051647.CAA02615@labs.usn.blaze.net.au> In-Reply-To: Your message of "Wed, 04 Jun 1997 08:29:12 MST." <m0wZHzt-000QdNC@bloke.statsci.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> For an intermittent connection that's initiated from one > direction only (i.e. my home system initiates the connection > to work), it seems like SMTP is backwards for mail going from > work to home. SMTP seems to be really meant for continuous > network connections (or nearly so). Yep, exactly. ETRN support in sendmail greases the wheels a bit for the idiots who've gone out and purchased, say, MS Exchange for their dial-up system without knowing all the ins and outs of the situation, but to have sendmail "stuck" while servicing the queue is an added inconvenience we could all live without. POP is just plain inadequate. Yes, I know about the kludges, but well, they aren't called "kludges" for nothing. Header rewriting is a (somtimes) necessary evil, and having to stick the envelope into the headers simply because it goes throught a needlehole that strips the headers is a nasty hack. So, UUCP does it, but that is also messy to setup and administer, especially so from the novice point of view. Very few will actually support it these days too, in spite of it solving most of the problems you've outlined. > over TCP to gather send email (and queued file transfers) traffic > to/from home. I have to say that it seems to work quite well. Yes, it does. Half o my own uucp connections (just under a dozen, but gradually dropping off) are over tcp. > IS there any standard software that I could use in place of UUCP > to allow easy file transfer and email requests to be queued and > processed at connect time? We need a new protocol, imho. Not unlike smtp, or maybe even a variation of smtp that is receiver driven. > I suppose one could funnel everything through a POP mailbox drop, > then write some custom delivery scripts on my home system, but > that seems like more work and more error prone to me. A nasty, evil hack. The idea is to get the delivery envelope into headers, in a form recognised by the remote system. There are no standards here, and therein lies the evilness. Once nice feature of ZMailer which I (ab)used often was to split recipients into different queues with different retry parameters. Periodic callers with smtp would get redirected to a "slow" queue and it wouldn't interfere with the rest of mail delivery. Nifty. It has a similar function to ETRN (XTRN) that does much the same thing, plus its scheduler is threaded. Eventually this will get to the stage where I'll take the plunge and just reinstall the damn thing - I miss a lot of its features. Unfortunately more recent versions have become less stable, and not having time to really get my hands dirty with it, I've procrastinated for months. I guess it's not a case of hating sendmail enough yet... or is that again? :-)). Regards, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706051647.CAA02615>