Re: pop3 changes

Michael D'Errico <Mike@software.com> Sat, 04 June 1994 01:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14341; 3 Jun 94 21:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14337; 3 Jun 94 21:14 EDT
Received: from PO2.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa23540; 3 Jun 94 21:14 EDT
Received: (from postman@localhost) by po2.andrew.cmu.edu (8.6.7/8.6.6) id VAA01944; Fri, 3 Jun 1994 21:12:28 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Fri, 3 Jun 1994 21:12:27 -0400 (EDT)
Received: from po3.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.chvxHLy00UdbERgE4T>; Fri, 3 Jun 1994 21:11:52 -0400 (EDT)
Received: from rome.software.com (rome.software.com [198.17.234.2]) by po3.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id VAA07596 for <ietf-pop3@andrew.cmu.edu>; Fri, 3 Jun 1994 21:11:38 -0400
Received: from rome (rome.software.com [127.0.0.1]) by rome.software.com with ESMTP id AAA10593 for <ietf-pop3@andrew.cmu.edu>; Fri, 3 Jun 1994 18:10:48 -0700
To: ietf-pop3@andrew.cmu.edu
Subject: Re: pop3 changes
Date: Fri, 03 Jun 1994 18:10:47 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Michael D'Errico <Mike@software.com>
Message-ID: <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....

> 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!

> 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)

> 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.

Michael D'Errico
mike@software.com