Re: pop3 changes

[Ned Freed <[e-mail]>]

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

The fact that it doesn't add any complexity to the POP server in *your*
environment, which happens to have certain tools at hand you can use doesn't
mean there's no complexity associated with such schemes. All you have done is
hidden it somewhere else, in this case in sendmail.

This doesn't mean that this is a bad idea. However, it is important that we
discuss it on the basis of its real merits rather in terms of being 
advantageous to a particular environment.

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

Absolutely right. This is precisely the complexity that you've hidden by
submitting a preformatted message and letting something else do it.

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

Simplicity isn't the only issue here, nor, to be honest, do I see it as an
overriding concern.

The real problem with this sort of scheme is the lack of any precise
specification of how it is supposed to work. There are lots of issues this
kind of submission raises, including:

(1) How is the MAIL FROM address generated? By using forming an address based
    on the identity of the POP user that's logged in? On a Return-path: header?
    As part of a Received: line? Some other scheme? What's permitted and what's
    not?
(2) How are the recipient addresses generated from the headers specifying
    recipients? Are the standard to, cc, and bcc headers used? Or are some
    new headers used?  Do all addresses have to come in a simple form? Are
    groups allowed and what do they mean? Are empty groups assigned some
    special meaning? Are personal address books to be consulted? 
(3) How are Bcc: headers handled? Do they generate separate message copies
    with each recipient having their own Bcc: header? Or are all Bcc:
    recipients aware of each other? (Note that the use of this sort of
    interface exposes details that used to be strictly internal to a user
    agent.
(4) Should the posting agent add any missing headers, like Date: and From:?
(5) How will delivery receipts be dealt with without the SMTP extensions for
    requesting such things.

There are quite a few systems out there that use this sort of posting model
already, and there are already lots of interoperability problems. As long as
these details aren't dealt with, these problems will only increase.

Mind you, I'm not saying that we cannot deal with these issues. We most
certainly can deal with them, and if we decide to standardize such a posting
model, we must. But it is all far from simple, and some of these decisions
may have profound consequence down the road.

				Ned