Slashdot Mirror

http://www.imap.org/imap.vs.pop.brief.html

>> I just hope that Gmail will soon develop pop3 support for Thunderbird.
> Maybe they will develop an interface that works over Trumpet Winsock too! That would be killer!

The one who moderated it as 'Flaimbait' is either humour-impaired or not aware of the significant advantages of IMAP over POP.

>> I just hope that Gmail will soon develop pop3 support for Thunderbird.
> Maybe they will develop an interface that works over Trumpet Winsock too! That would be killer!

The one who moderated it as 'Flaimbait' is either humour-impaired or not aware of the significant advantages of IMAP over POP.

143 is imap, 993 is imaps. That's not "outbound" email. IMAP (like POP) is a client protocol for accessing email (or news) servers. See the imap web site for info.

These people are talking about SMTP - port 25 - which is how email servers send / receive email messages between servers.

IMAP (Internet Message Access Protocol) was designed to centralize email information, I believe. If stored/implemented with a database, what more would you need ?

I think querying through SQL would satisfy most of us.. and be very useful in corporate environments (for example, query all email sent from a user to support), and it's already done by some projects like DBMAIL.

Anybody out there with experience using these ?

BTW, there's an extensive database of IMAP products including some that make the data accessible via LDAP... hours of fun!

IMAP (Internet Message Access Protocol) was designed to centralize email information, I believe. If stored/implemented with a database, what more would you need ?

I think querying through SQL would satisfy most of us.. and be very useful in corporate environments (for example, query all email sent from a user to support), and it's already done by some projects like DBMAIL.

Anybody out there with experience using these ?

BTW, there's an extensive database of IMAP products including some that make the data accessible via LDAP... hours of fun!

Here's a good description of IMAP vs. POP3:

IMAP vs. POP (www.imap.org)

Today, Communicator is the only viable IMAP mail client for X. Sure, there are dozens of alleged mail agents, but they invariably have some huge glaring usability problem that turn me away.

I'm not sure what your definition of 'viable' is, but this is the first time I've seen Messenger turn up in that sentence without a negative ;-) In any case, assuming you mean a graphical mail client (as opposed to one which can be run in an X-term) there's a pretty lengthy list right here. I would also be remiss if I didn't mention Pine which, though not graphical, is a very solid IMAP client (it should be since the author is one of the people to design the IMAP protocol) and allows you to configure any program you want for viewing of attachments; so unless you have to view your images inline, it works out pretty well.

Chris

• Between the KDE Two Conference material and KDE 2.0 Technology Overview, it appears that there is a proliferation of messaging systems.

  It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?

  What comes to mind are:

  • Lightweight Distributed Objects (LDO), submitted as an IETF draft, and
  • HTTP-SOAP, also an IETF draft
• Has any consideration been made of using some of the configuration libraries and data formats already available, such as:
  • ACAP, which has an IETF draft
  • libPropList which is used by GnuStep and OpenStep as well as by WindowMaker.
  • Ted Tso's .ini file reader?

It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.