Description Introduction History Day by day plan Downloads
PyWebMail site
To-Do list
Checker results
click here to use https Project Page
PyWebMail LJ Community
click here to use https Download area
User links
click here to use https Bug reports
click here to use https Report a bug
click here to use https Feature requests
click here to use https Request new feature
click here to use https Support requests
click here to use https Ask a question
click here to use https Users mail list
Mailing lists
Developer links
click here to use https Developers mail list
click here to use https Pending Tasks
click here to use https Bug reports
click here to use https Patches
click here to use https CVS commits
OGH :-)
click here to use https Host's Status Page
Get Firefox!

WebMail client library tools and POP3 gateway

Here is a Python library and collection of tools for working with WebMail servers like with mail server that uses other more machine-parsable protocols (like POP3 and IMAP). This library enables you to work with WebMail server like with POP3 or IMAP server. Basically there is support for connecting to webmail, listing folders, retrieving and deleting messages. In foreseeble future there will be support for sending mail (no relay due to technical limitations). Also there is gateway server that allows you to use POP3 client (like Eudora, Bat, Mozilla or :-/ MS Outlook) against these servers. Basic goal of this project includes providing comfortable mail access for users of webmail provides that doesn't supports POP3 access, and (!) for users that can't use POP3 due to technical reasons (usually firewalls). This package also includes test WebMail server.

If you don't want to gather pieces of information on configuration you should possibly read INTRO.txt.

Client infrastructure

Configuration (i.e. services info)

  • Information about services contained in separate files

  • Configuration directory scanned for "*.xml" files that contains information about one service each. These files loaded (not parsed) and md5 check-sum is counted.

  • If .wmc (WebMail Config/Cache/Compiled) file with the same name is found in the same directory check-sum stored inside (it's just a gzipped pickled file) mathes .xml file than parsed information is loaded from this cache file. If checksum does not match then XML file is parsed and information is saved to .wmc file.

Setup (.ini files and registry)

  • Using webmail.utils.xConfigParser (extention of ConfigParser from standard library with support for windows registry) a lot of webmail setup information can be customized:

    • There is a lot of configuration files that are checked: current directory, script-containing directory (not for services of cause), user home directory ($HOME and $USERHOME) and also python installation directory are searched for files webmail.ini, webmail.cfg, {script-name}.ini, {script-name}.cfg.

    • Also under Windows Software\Infoscope under HKLM and HKCU is loaded. Also if you are using NT service HKLM\System\CurrentControlSet\Services\{svc-name}\Parameters is loaded.

    • Look for in standard library for syntax details, but they are very similiar to old plain .ini files (for example in old Windows versions - you maybe saw win.ini and system.ini)

    • Every parameter also is searched for several sections of setup file [{script-name}], [webmail] and default section which is top-level key in registry and [DEFAULT] in .ini files.

    • You should remember something that concludes from this order of lookups: we first loading everything from every file and every registry key we know about, and then we searching for resulting dataset in section-priority based order.

      • You can hit following scenario:

        • You had setup some preferences (ex. offline=0 - see later) in, say, [webmail] of your .ini file.

        • Than you setup something different right under NT service Parameters keys (ex. offline=1) and you want this value to overwrite value in .ini file. There are some logic - service key is specific to service at last.

      • But above scenario ends up with dataset equival to following .ini

        offline=1 #this goes from NT-service specific key

        offline=0 #this goes from file

        and, as soon as offline=0 is in more specific section it takes priority.

      • There can be several decisions:

        • You can use less specific (ex. [DEFAULT]) section in file.

        • You can create more specific section key under Parameters of service.

        • Or you can add service-specific (ex. [PyWebMailPOP3]) section in you file.

        I prefer last way. It's generally recomended to only use adv_config in service registry key as a replacement of script-based location.

  • Following options can be setup and will affect details of webmail client services. Right now it only applies to POP3 gateway.


    Path to file to load as advanced config. Primary for use in service-specific Parameters.


    Set this to yes or no to select which frontend to use. Default is 1.


    Set to yes or no to (en|dis)able ability of user to login to new accounts (service is evaluated from email domain). Only meaningful for cached frontend. Default is 0.


    Set to no if you want to automatically start message download for accounts that marked with auto_check flag (see below). Default is 0 except for ntservice.


    Set to yes or no to affect auto_check flag behaviour (see below). Default is 0.


    Most important option. Comma separated list of (setup-specific) names of accounts to initialize at startup (and forever unless use had allow_mailbox_creation=1).

  • Setup of mailboxes listed in mailboxes option is loaded from [mailbox_{name}] sections that can consists of following information


    Optional. Specifies which backend to use. Most important backend is web (this is why all this software was written). If you skip it it will be detected depending on available parameters. If server is available then it shold be pop3, if merge is evailable it's merge, otherwise - web.


    plain user@domain string. Don't forget this is your login name for POP3 gateway and service and login name for webmail is calculated from it. Mandatory for all backends except pop3 where it will be defaulted to user@host.


    required for pop3 backend. Use format host[:port].


    required for pop3 backend.


    obvious. Mandatory, ever for backends without specific login. This is used as a password to this mailbox from POP3 frontend. You can skip this field for backends like none or smtp if you don't want it be accessible from from POP3 frontend (and you should not include it in mailboxes list).


    here you can specify name of webmail service provider. Useful only for web backend. I.e. name of .xml or .wmc file without extention. Optional.


    can be yes, no, local or global. First two is for constant check last choises are affected by local flag (see above).


    user name to use for POP3 login. By default email is used.


    password to use for POP3 login instead of password to WebMail account.

Top-level tools

Stand-alone WebMail

Client only command-line tool with expected commands: list, retreive, delete. Use -h for details.

WebMail-POP3 gateway

POP3 daemon (server)

POP3 daemon wrapped as NT service

POP3 daemon with attached manager

  • direct management has advantage in speed over

  • of cause still can be managed remotely (see

Manager for POP3 daemons

  • can manage over POP3 protocol any flavor of daemon (i.e. any of,,

  • For now only supports retrieval of statistics and starting of "auto-check" - retrieving of messages to cache

Testbed WebMail server implementation

Reads messages from "mbox" file in netscape mailbox format. Stores list of deleted messages in "mbox.del" - one UIDL by line.

stand-alone server (using webmail.server.cgi_server.apache_emulation)

Same as wrapped as NT service


Less important things

  • offline operations - no need for connection for listing. (half done)

  • static storage for downloaded messages - should be offline-transferrable if offline operations will be implemented, also store list deleted messages.

  • setup utility for service configuration.

  • automatic config generation (browser plugin or log parser)

  • SMTP gateway (i.e. message forwarding) - that's what initial project goal was, but I've encountered that POP3 is easier to implement :-).

  • SMTP relay - support for sending messages with creating message in webmail interface.

  • Dig around for language-specific differences of services.

Feedback and questions concerning this site should be directed to

Last modified : Fri Oct 6 19:01:47 2006