Re: pop3 changes

[Michael D'Errico <[e-mail]>]

>I see no problem with the pop server runing sendmail, or whatever mail
>transfer agent you want to run on the pop server machine, to deliver
>the mail, or queue it for delivery.  This way only the POP server
>machine has to know how to deliver mail to a smarthost, if it's not
>the smarthost.  And, if things change, there is only one place to
>change the configuration, not hundreds or thousands.

I understand why you would like to see this feature, but there are so
many problems with it that it wouldn't be a good idea to add to POP.

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.

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.

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 I said, I understand the problem you have, but adding mail delivery
to POP is not the answer.

Michael D'Errico
[e-mail]

**Yes, sendmail does all this for you, but any part of a spec. that
requires the existence of sendmail can not be a part of that spec.