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