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 ConfigParser.py 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
[DEFAULT]
offline=1 #this goes from NT-service specific key
[webmail]
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.
-
adv_config Path to file to load as advanced config. Primary for use
in service-specific Parameters.
-
cached Set this to yes or no to select which frontend to use.
Default is 1.
-
allow_mailbox_creation 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.
-
offline 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.
-
local Set to yes or no to affect auto_check flag behaviour
(see below).
Default is 0.
-
mailboxes 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
-
backend 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.
-
email 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.
-
server required for pop3 backend. Use format host[:port].
-
user required for pop3 backend.
-
password 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).
-
service 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.
-
auto_check can be yes, no, local or global. First two is
for constant check last choises are affected by local flag
(see above).
-
login user name to use for POP3 login. By default email is used.
-
access_password password to use for POP3 login instead of password to WebMail account.
Top-level tools
Stand-alone WebMail
- wgetmail.py
Client only command-line tool with expected commands:
list, retreive, delete. Use wgetmail.py -h for details.
WebMail-POP3 gateway
- wgetpop3.py
POP3 daemon (server)
- wget_nt.py
POP3 daemon wrapped as NT service
- wget_gui.py
POP3 daemon with attached manager
- pop3mgr.py
Manager for POP3 daemons
can manage over POP3 protocol any flavor of daemon
(i.e. any of wgetpop3.py, wget_nt.py, wget_gui.py)
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.
- wmail_sa.py
stand-alone server (using webmail.server.cgi_server.apache_emulation)
- wmail_nt.py
Same as wmail_sa.py wrapped as NT service
To-do
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.
|
