<html> Ok, flame it was and I should know better.  And I wrote my first program in 1970 on punched cards and was eager to try the new technology, paper tape, that was coming out for numerically controlled milling machines about that time. When people talk about applications and how they have behaviors that are descriptive of both Clients and Servers, yes the definitions get blurred.  I don't happen to like blurriness(sp?) Flames go both ways and my years working for Sun Microsystems and the two Linux servers at my elbow run alongside servers of just about every flavor you can name in my office, so lets not get "one-up loop" about that.  I concur that POP and IMAP are more "conversational" than SMTP which is after all a "Transfer" protocol.  And while I disagreed with your description and some of your numeric logic regarding sendmail, I definitely don't think the Jabber server should be loaded more heavily with managing the routing of packets of the contents of files, which I think is what you were saying too. So I already responded to Max Metral about the in-band negotiation of a file transfer that happens in a second Jabber Session that occurs P2P and uses a more efficient Transfer protocol, ala Napster.  To show no hard feelings, if you are interested more in what we are doing at Apps As Peers.com we can do a Mutual NDA and I can send you some details.  If you are still interested in that then you might be interested in our Sweat Equity program. It gets hot in the Desert here in Tucson you know and especially late in the day with the flames tend to show. Ollie At 08:37 AM 6/7/2002 -0700, you wrote: <blockquote type=cite class=cite cite>Mike angrily flames: > How's that?  POP AND IMAP are protocols for Clients to talk to > Servers to access stores of messages and attachments.  A Pop or > IMAP Client DOES NOT talk to another Pop or IMAP Client...EVER... > SMTP is the way you SEND messages to those stores and every single > email message you send is transferred using SMTP and BTW SendMail > is just an SMTP Program for sending mail, it has nothing to do > with "bulk". Oh dear, I appear to have killed your cat or something with my message.  I apologize. The distinction I was making -- apparently not well enough for you to understand -- was that in SMTP, there is usually minimal conversation; the conversation is, in 99% of cases, the same between the two partners, and the task is a batch-like, bulk task usually involving one transaction. By comparison, POP/IMAP are chatty, and they tend to stay connected for multiple discrete 'transactions'.  This is more 'peer'-like behavior, a la Jabber, etc. There isn't a hard-and-fast definition of what a server is and what a client is any more; more and more we're talking shades of grey.  Certainly it's nothing to get screamy about. > Have you ever setup an email client?  I think so.  Over the course of my 17 year career as a Unix hacker, I've also written about 20 sendmail.cf files, most from scratch (starting with a UUCP feed), as well as written about a million lines of Perl, including the first opcode-based safe remote execution protocol in any language anywhere.  Somewhere in there may have been a few e-mail clients on desktops. > If you did you had to setup the email server for getting your email > and choose POP3 or IMAP4 and then an SMTP server for outgoing, Well, maybe on Windows.  I distinctly remember not having to do that on Xenix, SCO Unix, Unixware, Irix, HP/UX, Domain/OS, RSTS/E, VMS, Digital Unix, Linux .96c, QNX, VxWorks, *BSD, BSDI, Netware, or PalmOS.  For that matter, I didn't have to do that on Windows, either. > or > if you leave that blank it tries to use the same server you setup > for incoming. Not all the world is Outlook Express. > If YOU want to add value, don't spout about things you obviously know > NOTHING about.  Read the specifications about POP3, IMAP4 AND SMTP and > you can find those at <a href="http://www.ietf.org">http://www.ietf.org</a> Thanks for the pointer.  So what exactly is Netscape's MTA again? > I completely agree it depends on where you are standing and you are standing in the dark. It happens to the best of us.  Good luck with AppsAsPeers.com; if you need any pointers, I have some work I did in 1996 which could be relevant. F. ********************************************************************** E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. **********************************************************************</blockquote> <x-sigsep></x-sigsep> Michael Oliver Chief Technology Officer AppsAsPeers.com 7391 S. Bullrider Ave. Tucson, AZ 85747 520.574.1150</html>