Bruce Guenter <[EMAIL PROTECTED]> writes:
> On Tue, Jan 18, 2000 at 03:26:49PM -0000, Anthony DeBoer wrote:
>>> [ protocol wishlist ]
> >
> > That should include something that makes sense for a host that's behind a
> > firewall and/or NAT and/or dynamic-IP dialup to authenticate and download
> > mail for multiple users (to basically do what people try to do with
> > fetchmail/multidrop or ETRN or other dodgy solutions nowadays).
>
> Would it be acceptable to ensure that each message has an accessable
> envelope sender address, or are you thinking of something else or more?
You'd want the envelope recipient, actually, not the sender.
The protocol should allow for a single piece of mail to have multiple
envelope recipients; if you're trying to do an RFC-level protocol and
get it used by other MTA communities, you have to allow for the ones
that don't split deliveries. You would want to specify that the client
mailhost strip other-envelope-recipient information, in case another
recipient was Bcc'ed.
Considering, in fact, that people sending the same PowerPoint or AVI to
all the folks in an office account for a big chunk of bandwidth, there
might be motivation for the queue-handling software to identify multiple
queue entries that were in fact the same message, and merge them to a
single copy with multiple recipients. Whether that would be a win would
hinge largely on the popularity of big attachments at a given host and
the size of their pipe. Note that the need for this would be pretty much
MTA-independent, since the remote host that gave you the large message to
multiple recipients might be running qmail. :-)
I guess an existing protocol that does most of what's wanted would be
UUCP, but nobody wants non-IP solutions anymore. Maybe you could use
UUCP's IP transport mode, though. :-)
--
Anthony DeBoer <[EMAIL PROTECTED]>
