Re: pop3 changes Tue, 14 June 1994 22:34 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa10647; 14 Jun 94 18:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10643; 14 Jun 94 18:34 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa17475; 14 Jun 94 18:34 EDT
Received: (from postman@localhost) by (8.6.7/8.6.6) id SAA00709; Tue, 14 Jun 1994 18:28:56 -0400
Received: via switchmail for; Tue, 14 Jun 1994 18:28:55 -0400 (EDT)
Received: from via qmail ID </afs/>; Tue, 14 Jun 1994 18:28:20 -0400 (EDT)
Received: from ( []) by (8.6.7/8.6.6) with ESMTP id SAA00651 for <>; Tue, 14 Jun 1994 18:27:58 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Received: from by (8.6.8/1.34) id RAA21412; Tue, 14 Jun 1994 17:27:55 -0500
Received: by (8.6.8/1.34) id WAA12262; Tue, 14 Jun 1994 22:27:52 GMT
Date: Tue, 14 Jun 1994 22:27:52 GMT
Message-Id: <>
To: Michael D'Errico <>
Subject: Re: pop3 changes
In-Reply-To: <>
References: <> <>

Verily did Michael D'Errico say on June 14, 1994:

>First of all, you can't base an Internet protocol on sendmail.  It's
>not a standard by any means, and it doesn't even necessarily do the
>right thing with mail according to RFC 822 (since you can screw it up
>in the configuration file).  Any other MTA that rewrites headers 
>according to a configuration file has the same problem.

I just used sendmail as an example since it's the most commonly used
MTA on Unix machines.  Most of the email on the internet right now
flows through sendmail, so the fact that it can be messed up isn't
really an issue.  Most people manage to make it work properly.

>Secondly, as it stands now, POP3 is an incredibly simple protocol that
>reads a maildrop.  If you run it under a service like inetd, you don't
>even have to know that you're talking over the network.  If you add
>mail delivery capabilities to it, you increase the complexity quite a
>bit since you would have to add networking code to talk to an SMTP
>server, and address parsers to do the header rewrites you talked about.
>You also need the ability to queue the message for later delivery, and
>if any errors occurred in delivery, an error mailer to get the message
>back to the sender**.  Whenever complexity increases, reliability drops,
>and the number of people willing to implement such a thing also drops.
>These are both bad news for POP.

All you have to do is take the RFC822 formatted message that the POP
client hands to you and feed it into '/usr/lib/sendmail -t' or some
other similar acting program.  No networking involved, just a popen or
a fork.  It's then up to sendmail to deliver it to the correct place,
or queue it up for delivery if it can't be delivered immediately.  This
adds virtually no more complexity to the POP server.

>Also, there is already a widely deployed service for delivering mail
>(SMTP) which is being actively worked on (i.e. extended features are
>being added to create the ESMTP protocol).  If we decided to add a spec.
>for delivering mail via POP, it would be a parallel effort with ESMTP.
>Duplication of effort is never a good thing, and in this case would
>force a community of people to accept a limited subset of features of
>SMTP.  For example, there is a proposed extension to SMTP to handle
>delivery receipts.  It will take some time to finalize that spec. so
>there is a good chance it wouldn't make it into the POP Mail Delivery
>Extension.  As soon as people can get delivery notification with SMTP,
>the POP-only community will scream for it.  Then the ietf-pop3 list
>will have to be started up again....

As it stands, I can just feed an RFC822 formatted message to an SMTP
server.  I have to tell it where it's going, where it's coming from,
pay attention to the return codes and act reasonably based on those
return codes.  Granted, it's not all that complicated, but to do a
good job of talking to an SMTP server requires a fair amount of code.

In contrast, a command in the POP protocol that said, "Here is my mail,
deliver it", and which just took an already formatted mail message and
handed it off to an appropriate MTA for processesing would be much simpler,
and it would remove the need to have the POP client know as much about
the local mail setup as it currently does.

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: