Re: pop3 changes
brtmac@ksu.ksu.edu Sat, 04 June 1994 02:22 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14738; 3 Jun 94 22:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14734; 3 Jun 94 22:22 EDT
Received: from ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa24411; 3 Jun 94 22:22 EDT
Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id WAA14590; Fri, 3 Jun 1994 22:21:02 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Fri, 3 Jun 1994 22:21:01 -0400 (EDT)
Received: from po5.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q004/QF.IhvyGPK00Udd0ZnU5L>; Fri, 3 Jun 1994 22:19:08 -0400 (EDT)
Received: from grunt.ksu.ksu.edu (grunt.ksu.ksu.edu [129.130.12.17]) by po5.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id WAA09673 for <ietf-pop3@andrew.cmu.edu>; Fri, 3 Jun 1994 22:19:00 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: brtmac@ksu.ksu.edu
Received: from mort.ksu.ksu.edu by grunt.ksu.ksu.edu (8.6.8/1.34) id VAA07569; Fri, 3 Jun 1994 21:18:53 -0500
Received: by mort.ksu.ksu.edu (8.6.8/1.34) id CAA03086; Sat, 4 Jun 1994 02:18:39 GMT
Date: Sat, 04 Jun 1994 02:18:39 +0000
Message-Id: <199406040218.CAA03086@mort.ksu.ksu.edu>
To: Michael D'Errico <Mike@software.com>
Cc: ietf-pop3@andrew.cmu.edu
Subject: Re: pop3 changes
In-Reply-To: <19940604021048.AAA10593@rome.software.com>
References: <19940604021048.AAA10593@rome.software.com>
>> Right now, POP3 does >> not allow for a POP client to hand it mail to have sent out. That >> means that every single PC, Mac, etc. that runs a POP mail client has >> to be configured to know how to send mail, or where to send it so that >> it gets routed properly. It also has to get the headers correct, etc. >> It would seem to me that a way for a POP client to hand mail to the POP >> server and have it do the trick of getting it delivered would be a much >> preferable method. > >It is not the job of a POP server to know how to send mail. That is what >we have SMTP for. If your client software isn't smart enough to write >headers, then you should look into new client software. It sounds like >you need to talk to Qualcomm about Eudora.... Nearly all of the troubles that people are having around here is with Eudora. Nobody knows how to set it up, they just do it. Then they don't understand why their mail doesn't go anyplace, or why they don't ever get mail. We've had a lot of people set their Eudora stuff up so that their From: headers just ahs 'ksu.ksu.edu' or 'ksu.ksu.edu@userid' or some other strange thing. They also choose any random email address they happen to know as their From: mail address instead of what is the official address. >> The server can be configured for what should be in >> the headers, and where to actually send the mail to have it delivered. >> The only thing the POP client would need to know is where the POP server >> is. Right now POP clients on our campus have to know where the POP server >> is, where the mail router machine is, and how to configure the headers. > >The next logical thing for someone to ask for is an SMTP extension to >read their mailbox for them since their client software has to know where >the POP server is! We don't run SMTP on the same machine as POP (actually we do because too many people set their POP clients up that way, but that isn't how we want to do it). If POP is to be a Post Office Protocol, why not make it do what a Post Office does, and allow it to take delivery of mail from the client. >> In case you are wondering, we do not run the POP server on our main >> mail router. The machine that runs the POP server is configured to >> accept incoming mail and hand it off to the mail router, but that means >> we have to run both the POP server and an SMTP server on that machine, >> and it means that POP clients have to know how to speak SMTP to send >> mail. > >Exactly how easy do you think it would be to teach the client to speak >the POP version of SMTP? I suspect it would be about as difficult as >teaching it to talk SMTP directly. Oh wait, we'd have to agree on the >spec.... make that "much more difficult." (no smiley implied) Right now POP clients have to implement POP and SMTP. By adding one or two extra commands into the POP protocol (mail to: and data) you could elminate the need to do SMTP in the client. It seems silly to use POP to read mail and SMTP to send it. POP is for post office like stuff. SMTP is for mail transport (mail between systems). >> I suppose this is something that would be better suited for POP4, but it >> seems like something that should be there. You normally pick up and send >> mail at the postoffice. Why should that not be the case for POP? > >Your analogy is entirely wrong. If you have a postoffice box, you get >your mail out of a little box with your number on it. When you drop off >your mail, you don't put it in the little box, you drop it in the slot at >the other side of the building. > >I would absolutely oppose any such additions for POP4. POP is a protocol >for accessing a mailbox. It is not necessary nor desirable to add the >ability to send mail. Right now no POP client that I know of does any sort of mail routing. It just knows of one place to send mail, and sends *all* outgoing mail to that place. If it already has a POP connection to a centralized mail handling system, why not let it use that connection to hand a piece of mail to the system? An added benefit to this is that we could disallow SMTP connections from all of the random PC's and Mac's and junk on campus. Then people would have to authenticate themselves with the POP server in order to send mail, and the POP server would handle putting the correct From:, Reply-To:, etc. headers on the mail. Sort of like INN's inews does if you have the authentication stuff enabled. Brett McCoy, UNIX Systems Administrator Computing and Network Services Kansas State University, Manhattan KS 66506 vox: (913) 532-4908 / fax: (913) 532-5914 / e-mail: brtmac@ksu.ksu.edu
- pop3 changes brtmac
- Re: pop3 changes Michael D'Errico
- Re: pop3 changes Steve Dorner
- Re: pop3 changes brtmac
- Re: pop3 changes Glenn Anderson
- Re: pop3 changes Ned Freed
- Re: pop3 changes Michael D'Errico
- Re: pop3 changes Steve Dorner
- Re: pop3 changes Michael Scott Shappe
- Re: pop3 changes Ian Duncan
- Re: pop3 changes brtmac
- Re: pop3 changes Michael D'Errico
- Re: pop3 changes brtmac
- Re: pop3 changes Ned Freed