imp
IMP Webmail Client 4.2
IMP Webmail Client is a set of PHP scripts that implement an IMAP based webmail system. more>>
IMP Webmail Client 4.2 is created as a set of PHP scripts that implement an IMAP based webmail system. Assuming you have an account on a server that supports IMAP, you can use an installation of IMP to check your mail from anywhere that you have web access.
It is written in PHP and provides webmail access to IMAP and POP3 accounts.There are several current branches of IMP. IMP 4.1.x is the current production version of the stable branch. It requires PHP 4.3.0 and version 3.x of the Horde framework. It adds new features like crypting support, flexible charset handling, virtual folders for saved searches, a WYSIWYG editor for creating HTML messages, improved MIME message handling, and many more.
IMP 3.2.8 is the latest production version of the previous stable branch. It requires PHP 4.1.0 and version 2.0 of the Horde framework. It adds advanced features such as searching multiple mailboxes, identities, and a hierarchical mailbox navigator, as well as a cleaner, redesigned user interface. As with IMP 2.2 before it, it passes the "MIME Torture Test" that UW makes available.
Major Features:
- Spell checking
- Mail filtering (must install ingo module)
- Message searching
- Many Mime viewers (over ?)
- Encrypting, signing, decrypting and verifying of signed and encrypted messages (PGP/GPG and S/MIME)
- Robust/comprehensive/easy-to-use UI
- Full charset support in folders, mailbox, message and compose views
- Mail folders in the left menu
- Preview of attachments in compose view
- Send attachments as links
- Option to not save attachments with sent mail
- Navigation through message and mailbox views with arrow keys
- View all messages of a thread
- HTML message composition with a cross-browser WYSIWIG editor
- Fetching mails from other email accounts to view with IMP
- Message previews in mailbox view
- Management of shared IMAP folders
- Priority settings for composed messages
- User management for supported IMAP servers
- Integrated quota support
- Support for mailing list headers
- Ability to forward multiple messages at once
- Downloading of all attachments from a message as a single ZIP file
- Stripping individual attachments from messages
- Alias and "tied to" addresses in user identities
- Graphical emoticons and country flags in message view
- IMAP mailbox subscription support
- Available in many languages
Requirements: PHP 4.3.0 or later
Ingo 3.2.1
Ingo is now a generic and complete filter rule frontend that currently is able to create Sieve, procmail, maildrop, and IMAP filter rules. more>> Ingo 3.2.1 is designed as a generic and complete filter rule frontend that currently is able to create Sieve, procmail, maildrop, and IMAP filter rules. Ingo, the "Email Filter Rules Manager", started as a frontend for the Sieve filter language, and is now a generic and complete filter rule frontend that currently is able to create Sieve, procmail, maildrop, and IMAP filter rules.
The IMAP filter driver translates the filter rules on demand to IMAP commands, executed via PHPs IMAP extension and has replaced IMPs internal filtering code. It is now the default filtering agent in IMP H3 (4.x).Ingo is able to create and eventually run server as well as client filter scripts. The filter script API is flexible enough that any number of filter drivers can be written and "plugged in". Each filter driver exposes its capabilities to Ingo, that in return adapts its UI to display only those rules and features that the driver can actually handle.
It supports a set of "special" rules that are either translated to their native counterparts of the filter script backend or emulated through filter script commands. These rules are Blacklist, Whitelist, Forwards, and Vacation. Maybe they will replace the existing Horde modules Vacation and Forwards of the Sork suite in the future. These are much older than Ingo and currently support dot-forward, LDAP, SQL, qmail, Mdaemon, and SOAP backends.
Ingo abstracts storage, script, and transport backends. That means that the filter rules in Ingos internal format can be stored in several places. Currently only Hordes preferences are supported, but SQL or LDAP storage drivers would be easy to write.
The transport backends are responsible for uploading the generated filter scripts to the filter backends, for example to Cyrus timsieved daemon or through Hordes VFS (Virtual File Storage) API via FTP to the users home directories or into a SQL database. System administrators are able to switch to a different filter system or script storage at any time and the users filter rules will persist.
- Page: 1 of 1
- 1
