From owner-freebsd-chat Fri Jun 6 21:38:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA28854 for chat-outgoing; Fri, 6 Jun 1997 21:38:20 -0700 (PDT) Received: from ethanol.gnu.ai.mit.edu (we-refuse-to-spy-on-our-users@ethanol.gnu.ai.mit.edu [128.52.46.64]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA28847 for ; Fri, 6 Jun 1997 21:38:18 -0700 (PDT) Received: by ethanol.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id AAA03147; Sat, 7 Jun 1997 00:38:14 -0400 Date: Sat, 7 Jun 1997 00:38:14 -0400 Message-Id: <199706070438.AAA03147@ethanol.gnu.ai.mit.edu> To: scott@statsci.com CC: davidn@labs.usn.blaze.net.au, chat@FreeBSD.ORG In-reply-to: (message from Scott Blachowicz on Fri, 06 Jun 1997 21:26:19 -0700) Subject: Re: uucp uid's From: Joel Ray Holveck Reply-to: joelh@gnu.ai.mit.edu Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> What's the point in augmenting SMTP for a SEND extension? Protocols >> have their purposes for a reason. SMTP is designed to send mail; >> leave it there. If you want to receive mail, you can design a >> different protocol, or use a protocol that's been designed and >> implemented already such as POP. >Depends on your viewpoint...I'm just trying to think of a way for a remote >system to tell an SMTP daemon that the coast is clear and available for it to >send the mail (rather than forcing it to have to endure network timeouts or >some such). Oh, well, if that's all you're talking about, there already is one. It's the RFC821 TURN protocol, although I don't think that sendmail implements it. I also vaguely remember an ETRN command, but don't recall much about it. >Also, POP is for an individual user, not system-to-system (as my email from >work to home is - my wife doesn't have an account on our work systems which >are effectively just acting as an MX forwarder for home). My apologies. I hadn't realized that we were discussing site-to-site stuff. >> That way, other systems that need to send mail only don't need to mess >> around changing their protocol to meet the needs of extensions added for an >> entirely different purpose. >True...just trolling around for ideas...I'm just fine with using UUCP which >seems to be designed for my purposes and does the job just fine. The only disadvantage is that it isn't transparent. Happy hacking, joelh -- http://www.wp.com/piquan --- Joel Ray Holveck --- joelh@gnu.ai.mit.edu All my opinions are my own, not the Free Software Foundation's. Second law of programming: Anything that can go wrong wi sendmail: segmentation violation -- core dumped