JSP/SERVLET
2022.06.05 / 23:58

jwma (java webmail app) version 4.2

ŹÃÄ
Ãßõ ¼ö 192

jwma (java webmail app) version 4.2

JWMA uses the jakarta mail (rebranded from javamail) api to provide access to an imap email store. Multiple users can authenticate, read, send and manipulate email storage and persist a list of contacts, email identities and their own individual preferences. It has been tested on Debian with dovecot as imap server and exim4 as mail exchanger. Earlier versions were also tested on Fedora and with james (aka the Java Apache Mail Enterprise Server) rather than dovecot and exim4, so in principle it should also work on a windows server although that has never been tested.

It will work with messages in either mbox or maildir format, or stored in a derby database embedded in james. In all cases it supports two logical levels of nesting beneath the INBOX. A java runtime and webapp server are requirements, all testing was done with tomcat 8.5 and compiled and run with openJDK 11. It probably will work with java versions before 11; if you use java 17 you need to be running tomcat 10. To date it has never been tested with other webapp servers such as glassfish, jboss, jetty etc. If you want to try this the developer section may gives some clues.

The server administrator configures basic options by editing a simple config file. Here are set protocol (imap or imaps), ports, mailbox format (mbox or maildir/derby) and the default language that's offered to users. Individual users can separately choose the language of the interface and select from a few other options. By default these user settings are persisted as serialized objects, but the administrator's config file also has options for database storage (postgresql, mysql or embedded derby).

For the server administrator

Installation

This assumes a machine running a suitable imap server, mail exchanger and java webapp server. To make dovecot / exim4 or james and tomcat jwma ready see this write up and the pages it links - the perfect email server.

Download jwma from sourceforge. The zip archive includes a ready to run binary, although you may want to try building with your own version of java. There are build files to make this a quick (few seconds) and simple process, see the developer section. Although it will run on java 17 with tomcat 10 (with an extra bit of fiddling) this version will not compile on java 17 - see the developer section.

However obtained, the webmail.war is moved to the appropriate place for your webapp server (webapps for tomcat 8) and it will start up and load the login page, but if you're upgrading from an earlier version please first check out the next section. If you are using java 17 you should create a directory webapps-javaee in the base of the tomcat install and put webmail.war there, rather than in webapps. Tomcat will automatically migrate it to Jakarta EE spec and move the result to the webapps directory. There is further info on this process here.

If you have an account on the imap server and it's offering an imap service on port 143 with mbox storage, you should be able to login and access your email. From this point on you can jump to the user guide section.

Upgrading

On first run under tomcat, jwma creates a jwma home directory CATALINA_BASE/.jwma (jwma on windows) containing the jwma.config file. This changed both during the development of the 2.x.x and later, but is unchanged in the 4.x series. If you used earlier versions you can either delete the existing jwma home or edit the existing jwma.config to have the eight settings as shown below. If you used serialization to persist user settings you can copy the existing .jwma/data directory and use that to replace the new one created on first login. Note that this assumes tomcat is started with the bin/catalina.sh start command issued from the base of it's install.

############
#jwma.config
############

#access_protocol - the mailbox access, either imap or imaps
access_protocol = imap

#access port, probably either 143 for imap or 993 for imaps
port = 143

#available interface languages
languages = de,en,es,fr,it

#the login screen language and the default choice for users
language = en

#users config & contacts persistence - one of serialize, postgres, mysql or derby
persistence = serialize

#1 - session is kept alive or 0 - it times out after 30mins unless compose message page is open
keep_alive = 1

#log level one of ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF
log_level = DEBUG

#mailbox format, either mbox or maildir
mailbox_format = mbox	
If you intend to switch to database storage of user configs and contacts (serialization remains as default) and you used database storage with versions 0.98 - 1.01, existing databases must be dropped and recreated. There's also some work to do before switching to embedded derby.

Configuring

If you make changes to the config file, you need to reload the webmail app or restart tomcat, to have the changes picked up.

  • access_protocol - this can be changed to from imap to imaps, if you do this you will need to insert a certificate into the jvm's store; see this article describing the setup of java based webmail.
  • access port - this will probably need to be changed from 143 to 993 if you switch to imaps.
  • languages - currently there are five European languages available. You could add to these (see Internationalization) or even remove from the comma separated list if you don't want to support them.
  • language - the default language, one of those that appears in languages. This will be used at the login screen, but individual users are able to select a different languages once they are logged in.
  • persistence - this must be set to serialize (the default), postgresmysql or derby.
  • keep_alive - if this is set to 1 the session never times out, changing this to 0 allows time out after 30 mins of inactivity on the server, except when the compose message window is open.
  • log_level - default setting is DEBUG, you can reduce log verbosity by changing this to a lower setting. This only works where the web server explodes the war file (as does tomcat) and settings below WARN are not recommended.
  • mailbox_format - defaults to mbox with maildir as alternative, this also being the correct setting if you're running james with it's embedded derby database. All software (imap server, smtp server and jwma) must use the same mailbox format.
In most cases the default config will be ok unless the system uses maildir, when there will be some perculiarities. No per user configuration is necessary other than there must be an pre-existing imap account. Jwma passes login details through to the imap server and a jwma account is automatically created for each user the first time they log in. With the default persistence setting, preferences and contacts for each user are stored in two separate files, inside the .jwma/data directory. Before switching to database persistence see the next section.

Data storage

Some clarification - jwma can persist user settings to a derby database and if you're running james as imap server, emails can also be stored in its derby database. These are seperate configuration issues and the same derby instance is never used for user settings and their emails, since both jwma and james use derby in embedded mode

Pro and con:-
  • No additional installations, setups or configuration changes necessary with serialization.
  • Easier to remove all trace of an ex-user with serialization - after removing the imap account just delete two files from .jwma/data.
  • If you have a lot of users, database storage avoids a shed load of files being created in .jwma/data.
  • But the same could be said (shed load of files) about using the derby database.
  • Database storage is an attractive option on a server with an existing postgres or mysql install.
  • Employing either of those database systems simply for jwma is overkill - jwma merely persists a few user settings and the contact's email addresses.
  • Serialized files are not guaranteed to be transferable across different versions of the JVM (they usually are though!).
  • The jwmaDB folder that stores a derby database can be moved around servers and JVM versions (maybe so!).
Before editing the persistence field in jwma.config and restarting tomcat, you must create the database and also supply a suitable jdbc driver for your version of postgresql or mysql. For java versions below 1.8 this can be put in the tomcat lib directory, but later versions seem to require this is placed instead in webapps/webmail/WEB-INF/lib/. To use derby, the embeddable derby.jar is still put in the tomcat lib directory. You need that single file from the lib directory of a release, although I use the one supplied with james.

The supplied empty postgresql and mysql database schemas assume that dovecot will use system users names as login credentials. If your set up requires user@domain style user names (james requires this), the 20 allowed characters may not be sufficient. The schemas can be edited before you insert them. Further individual database documentation can be found in the docs folder of the jwma download, the prepared schemas are in the database directory.

Internationalization

jwma is a genuinely internationalized app; the system administrator can configure the default language, but please note that supplied translations from English are almost certainly flawed - see the developer section - you can help even if you have no programming skills. All users can make their own selection which is recorded in their preference settings, see User Configuration. They do this entirely independently of other users and the default language, although this is always presented at the login screen.

Security

Authentication is managed by the imap server with jwma merely passing details through to it. Since it's running on the same machine as the imap server, I don't believe that passing these in plain text is an issue. Nevertheless, there are features built into jwma that have security in mind and also configuration changes that can be made with the same objective.

The user name, but not the password, is stored in the session object. Databases are protected from malicious input, by checking and sanitizing user input for their configuration settings.

Logs

jwma writes and rotates logs files which will include evidence of any nefarious activity; all login attempts are recorded, together with the source ip address if authentication fails. With tomcat or another app server that runs the app from an exploded .war file, these will be in the .jwma (or jwma on Windows) directory. If the app server runs the app from the war file itself, it's not possible for the code to manipulate settings in the log4j.properties file and I'm not sure where the logs will be. Try looking in the directory from where the app server runs.

As with any web-based service on a public network, it is good practise to monitor these logs; I suggest logwitch for help with this. If you're responsible for a system with a lot of users, it's worth looking out for WARN and ERROR entries such as these:-

ERROR JwmaExceptionHandler - net.sourceforge.stripes.exception.ActionBeanNotFoundException: 
Could not locate an ActionBean that is bound to the URL [/Admin.jwma].

2016-08-05 18:09:07,215 WARN  JwmaAuthenticator - login FAILED for david
2016-08-05 18:09:07,216 WARN  LoginAction - FAILED login from 94.2.235.163
A single pair of entries similar to the second example may simply be due to a typo, but if you see something similar to the first example I'd recommend having a word with the user in question (there is no Admin.jwma page).

You may wish to make use of the ability to set logging levels in the config file; once you are satisfied that jwma is running smoothly, you could reduce log verbosity. I'd suggest not going any lower than the WARN setting. This option is only effective if your web app server runs jwma from an exploded war file, as does a standard tomcat install for instance.

https and imaps

Presenting the login screen over https avoids the risk of passwords being sniffed. There are a number of ways to set this up, the best way being to link tomcat with an apache2 front end and make use of its SSL implementatiom. They are dealt with in this general webmail writeup, as are issues around switching to imaps.

That (imaps) is another config change that should be considered from the standpoint of security. The java environment must have knowledge of a certificate supplied by the imap server, this being described in the webmail writeup, with links to the specifics of both dovecot and james configurations. From the jwma side the change is pretty simple:-

#access_protocol - the mailbox access, either imap or imaps
access_protocol = imaps

#access port, probably either 143 for imap or 993 for imaps
port = 993

the Session

The default web.xml file specifies a session length of 30 minutes, but with the standard keep_alive = 1 in jwma.config this is overriden by javascript pokes from client browser to server. A session is created when a user logs in and we rely on a logout for it to be closed.

This situation is probably fine where there are only a few, educated users and it is also a nice feature to have the INBOX update automatically and indeed pretty essential that the session does not time out while a user is writing a lengthy email. If this is unlikely to scale too well on your install, you can change the setting to keep_alive = 0. The session is still kept open if the user is composing a message (despite typing on the client not registering on the server!), but if other screens are left inactive the session will be closed after 30 minutes.

Miscellaneous

imaps

Unlike debian dovecot, on fedora dovecot is imaps ready and the certificate is at /etc/pki/dovecot/certs/dovecot.pem. There may be a problem of SSL/TLS incompatibility between the java version and the openssl version used by dovecot, but this is unlikely if you stick with distro versions.

file system access

If users find that operations such as deleting messages and creating mailboxes fail silently, without a warning in red coloured text, this is probably due to insufficiently permissive access controls to parts of the system involved in mail handling.

It's important to remember that with a system using mbox mail storage, the users INBOX may actually be a file under /var/mail or /var/spool/mail rather than being located in the home directory. On a recent Debian install deleting messages from the INBOX fails:-

root@raylor # ls -l /var/
/\/\/\/\/\
drwxrwsr-x  2 root mail  4096 Oct  6 06:25 mail
\/\/\/\/\/
Changing permissions fixes this:-
root@raylor # chmod o+w /var/mail/

root@raylor # ls -l /var/
/\/\/\/\/\
drwxrwsrwx  2 root mail  4096 Oct  6 06:25 mail
\/\/\/\/\/

directory = $home/Maildir
maildir_format
maildir_use_size_file

For the user

Log in

On a desktop machine if you browse to the address given you by the administrator, you'll get the login screen where you can authenticate with your imap username and password to access your email.



If you tick the Remember box a cookie is written to your browser. Depending on the browser's configuration, the Username field may be pre-filled next time you access the app. The link on the top left is there in case you arrived here using a small screen device; it will take you to the mobile interface, although hopefully that should have happened automatically. Jwma makes the assumption that you will mainly use a computer to manage your email with the mobile interface there to access the main features whilst you are away from home or office.

Main Page

This is where you land after a successful login and where you can quickly return to from the left most link onthe navigation bar. What you see, to some extent depends on the underlying system used for email storage. First, here's jwma running on a mbox system:-



From top working down, you see that the INBOX has 3 messages, one of which has not been read. The already mentioned navigation bar takes you to the other parts of the app as well as returning you here. Below that, on the black bar next to the small folder image there is a forward slash (/) character. This is the path separator for the particular system that these messages are stored on. It's helpful to know this if you want to create nested mailboxes ie mailboxes hidden from the main view.

Next the pre-exisiting folders and mailboxes are displayed. Folders, which can contain mailboxes are shown on the left and mailboxes which contain individual messages on the right. Although they can't be seen, it's likely that the archive folder contains some nested mailboxes. These would be revealed by clicking the folder name and the layout would remain similar to the one shown, but just listing mailboxes inside the folder rather than those logically directly inside the INBOX. If instead of clicking a folder, you click a mailbox, which includes the INBOX you are taken to a Message list for the particular mailbox.

Below here are options to delete selected folders or mailboxes, move mailboxes from their logical position inside the INBOX to another folder and create new folders or mailboxes. Finally the icon at bottom right shows that the Trash folder is not empty. In this state the icon is a link that takes you to a list of deleted messages.

Be aware that deleting a mailboxes moves all its messages to Trash and if you delete a folder all mailboxes nested in it will also be removed. As with deleting an individual message (see Message lists), the Trash mailbox represents a second chance, but if you delete messages from this mailbox, they really are gone. The same applies when you logout, unless you deselect Automatically empty Trash in the Settings menu.

If instead of an mbox storage system the administrator has set up a maildir system, what you see will look more like this:-



There is no Folder as opposed to Mailbox distinction as all folders can contain both messages and other folders nested within them. In both systems, jwma limits nesting to 2 levels, ie messages are logically stored directly in the INBOX or either one or two levels beneath it. Note that on this maildir system the folder separator is a period/dot/fullstop (.) and that when the screen shot was taken although the INBOX and Trash were empty, the sent folder contains a single message.

Clicking the nested Folders link reveals the whole mail storage layout, not just the Mailboxes nested within a single folder as in the mbox system.



Finally, since this type of system does not distinguish mailboxes from folders, the Create new button does not need to offer that choice. It is only in this first main window that there is any difference apparant to the jwma user between the two email storage systems it presents.

User Configuration

Select Settings in the navigation bar and you'll be taken to this screen, which initially displays the default settings for each user.



You'll want to replace the Mail identity with one or more of your own email addresses. Note that you cannot delete the default until at least one alternative is in place. This is because it's not possible to send email without this setting.

If you select a different language all the screens (except the login page) will be translated accordingly. Note that by default Trash messages are automatically deleted when you logout; if you stick with this, although deleting messages from other mailboxes actually moves them to Trash, on logging out, they really will be gone.

By default, sent mail is not archived to an Outbox and there is no Draft folder for saving messages (even if there is a mailbox of that name); you'll probably want to select mailboxes for these roles, possibly creating them first back in the app's Main page.

Message display options:-

  • 1. geek - plain text only display including the structure of the message
  • 2. plain text - the default, a standard plain text display
  • 3. block images - html messages displayed, but images blocked
  • 4. in line images only - as above, but with in line images displayed
  • 5. allow all images - remote images fetched and included in the display.

There are changes here compared to earlier versions of jwma for html display; none of the settings 3 to 5 now leave a stylesheet in place. Any javascript is also removed and I actually don't recommend setting 5, which does still allow remote images to be fetched (more on this later). My preference is for the use of setting 1 or 2 as you can quickly switch from a plain text view to settings 3 and 4 for individual messages. In settings 3 and 4, any remote images that have been blocked are listed as clickable links at the bottom of the display. The descriptors for these links are the actual filenames that have been blocked.

You must press the Update button to make changes stick. Don't forget to do this after changing mail identities.

Message lists

IMPORTANT! - any problem with deleting messages failing silently (no warning in red text) is probably due to this issue. The same applies to an attempt to create a mailbox or folder failing without warning.

Here's an mailbox with 3 messages; looking directly below the navigation bar you see this is the INBOX, but listings of all the mail boxes will have similar appearance.





You can Select all messages for a mass Delete or Move to; that can also be done on an individual basis by checking boxes on the left as appropriate. Delete is actually a move to Trash except for messages already there, when it really is a delete. Looking at the three individual messages, you see that the first has not been read N, the other two have been read and the third has been answered as well AR. This third message also has an attachment, which is indicated with *.

The sorted by setting shown is not the default (rather Date oldest first), when this is changed the selection sticks automatically for all mailboxes and is remembered even if you logout.

Search allows you to create a list of messages from the current mailbox which contains your search term in the body of the message. Clicking on the subject of a message displays it for reading and to the right, delivery date and message size are displayed.

Reading messages





The appearance of messages depends on the display style chosen in Settings.

This mail (not shown full length) is in the INBOX folder, that being a link which would take you back to its message list. As it's #1 in the folder, it's the oldest, as chosen sort order has no bearing on this. To the right there are widgets for cycling through the messages in a folder and for presenting the message in a screen suitable for printing . Also a head and shoulders icon which will reveal and conceal the email headers. The current message display setting is option 1. geek so there is information about the structure of the message as well as its content.





This email (above) is displayed with option 2. plain text, so information about message structure is not included. Notice that there is a plain text/html toggle link, not present in the first message because this message has an html part. If we click that toggle, the display changes:-




This is equivalent to having selected 3. block images. Since this email has in line (rather than remote) images, we can click to either display or download them.




If we chose the former, this is the same display as would be had if we selected 4. in line images only

With that same setting made, here's a different message that has remote images:-





You see a list of links to those images at the end of the display. Look at those filenames! My guess is these images have a tracking purpose and if accessed they confirm the email has been read. In this screenshot, unlike earlier ones, the bottom of the browser window is visible with the buttons that allow you options to delete, reply to or forward the mail or move it to a different folder.

This message has rather more innocent looking remote images, shown here with setting 5. allow all images:-





The appearence of messages that you click on is not dependent on the folder containing them, with one exception. If you designate a draft folder in settings, its messages will be opened in a compose rather than display window; the assumption is that these messages have been part written and then saved rather than sent and so await further editing.

Sending Messages

As standard Jwma creates and sends messages as plain text




The rich text link replaces the text area with an embedded html editor to allow the creation of html messages.




If you use the Browse button to add a file attachment, two further file selectors will appear automatically, giving the option to attach up to three files. If an attachment is an image file many email clients (including jwma if Setting 4 or 5 are used for reading messages) will display the image as well as creating a download link for it. Although an attached image file is treated as an inline image, it's not possible at the moment to place it in a particular position; there's further explanation (and work!) in the developer section

Save Draft allows you to save a partially complete message into the folder you configured as described in the User configuration section. If you have not done this a warning is displayed. It is not functional if rich text was selected or if a file has been attached to the message. A work around is to write and save a plain text message; when you reopen it from the draft folder you can switch to rich text and apply the markup as you want.

No attempt is made to display forwarded messages before they are sent on; you see that the subject and recipient have been rewritten and a preamble stating that this is a forwarded message. You can edit this preamble before sending, but if you are forwarding a message with an html part, there's no guarantee the recipient will see this. Reason being that any preamble goes into a plain text part which may not be displayed.





Contacts





This allows you to store a list of contacts with email addresses. Clicking on the email address takes you to the compose window, with the To field pre-entered. Selecting a checkbox and pressing the Email contacts button has similar effect, but this has the additional function of placing a list of recipients in the To field if more than a single checkbox is selected.

The list can be filtered by surname using the selector, which will initially be labeled * to indicate that the full list of contacts is displayed.





Delete contacts operates on entries whose checkbox has been selected. Create contact does its work when the firstname, lastname and email fields have been completed.

Managing folders and mailboxes

To create a new top level mailbox type a name such as test in the input field adjacent to the drop down list and press the Create new button. As explained in the Main page section above, some of the following is underlying system specific.

On both mbox and maildir systems you can use the mailbox store separator character, shown on the black bar of the Main page to create a nested mailbox or folder. On a mbox based system test/test in the input field, will create both a new folder and a new mailbox within it, or just a new nested mailbox if the folder already exists. You can create an empty folder without creating a mailbox at the same time by selecting Folder from the drop down list. On a maildir system test.test will only work if there is already a folder test.

On both systems that already have test/test | test.test, after pressing Create new with test/another | test.another in the input field, the single test folder will now contain two mailboxes or folders. You must always use the correct file separator of the underlying system or the result will not be what you expect.

Folders and mailboxes are deleted by checking the appropriate box and pressing the Delete button. Care is needed as without warning all mailboxes | folders nested within a folder are removed As described here, all messages within all deleted folders | mailboxes will be moved to Trash.

Mailboxes and maildir folders with all the messages they contain can be moved around the hierarchy by checking the appropriate box, selecting the folder from the drop down list and pressing the Move to button.

The small screen interface

If you access Jwma using your smart phone, you should be automatically directed to an alternative interface, but as a fall back the login screen of each interface allows you to switch manually. Compared to the desktop interface there are optimizations both in layout and in a reduction of the feature set.

These screenshots where taken from a galaxy 2 running cyanogenmod; the mobile interface looks pretty much the same on the iphone.

 

A successful login takes you directly to the INBOX rather than a folder listing. The mailbox list is accessible in the same way as on the desktop interface (the first left navigation icon) a major difference being that folders and any mailboxes nested within them (mbox system) and nested folders (maildir) are not accessible. Other differences include the absence of a save draft option, no option to create html mail, message lists are displayed in recent first order and message display being set to plain text (option 2).

There is no contradiction between the two interfaces in that their settings do not clash. Any folders, nested mailboxes (mbox) and nested folders (maildir) you created via desktop access remain untouched by small screen access and if you normally read messages using some setting other than plain text, that setting will remain in place for desktop access.

For the developer

If you'd like to contribute in any way please get in touch; especially if you want to do something major that you would like included in future releases. All patches that add or improve functionality or squash bugs will be considered and you'll be credited for your work. I'll help you get started, in particular with getting up to speed with the stripes framework.

Jwma was rewritten (start v2.0) using this framework which is also discussed here . You'll need a java development environment, a java webapp server and imap server. The imap server needs to be configured with a username and password and needs to accept authentication from a webmail front end in plain text. A running mail exchanger is not necessary for most development work.

It's very easy to build jwma from the source code with java 11, you can use ant, the linux shell or windows powershell (though this has not been tested). Simply move the appropriate script/build file out of the build_scripts directory and run it (or ant) from the base directory. Although the build.xml (ant) and build.sh (linux) produce slightly different binaries they are functionally identical.

The ongoing development of jwma has given the lie to the old write once run anywhere java mantra. There was activation.jar flitting in and then out of standard java, which meant at one time you did not need to add that as a seperate library. Now we hava jakarta-activation so it looks like jwma will need to supply that for the foreseeable future. There is also the curious case 0f imaps crypto; you can check this out in the JwmaAuthenticator.java code around line 31. At one time we could use baked in crypto, now we must include the sunjce_provider library. I can't remeber the versions, but there was a situation where we could compile and run on one version of java, also run on a later java, but not compile on that version without the new crypto library.

So if you want to run jwma on a different webapp container or latter java version, be warned there may be some work to do. If you have a success story, please let me know. To get jwma to compile under java 17, the first thing is to replace all imports from the javax package with corresponding jakarta equivalents. The source code supplies servlet-api.jar taken from the tomcat 8 release. This library is required for compilation, but is not needed in the binary war file at runtime. If you're working with java 17 and tomcat 10 replace it with the jar from that version of tomcat. Other coding changes will be necessary, please let me know if you pull this off!

To add another language, copy a StripesResources properties file in /webmail/web/WEB-INF/classes to StripesResources_xx.properties (where xx is something suitably representative), translating the right hand side of = on each line of the file. Add the appropriate xx to the languages list in jwma.config and rebuild as above. The war file will appear in the base directory. Follow a similar procedure to improve the supplied files (mis)translated from English. Please submit a copy of your file for inclusion a future release.

It's been brought to my attention recently that jwma does not support Content-Id; it still does not, although it does now accept the cid: attribute as valid. It (and images in email generally) is not an area that greatly interests me; the java-cid project looks relevant, at least for displaying email. As I now (think I) understand, cid: is used to place an uploaded image at a particular point in the document, rather than have it tacked on at the end.

That nicely leads to the topic of writing html email, which greatly disinterests me :-). This was previously offered by embedding the wyzz editor; I've replaced it in this version with nicEdit. There are dozens of these javascript based embeddible editors out there and I tried a good few of them. Most of them readily produce code that gmail (my gold standard!) does not consider to be html - even a 'specially for webmail' version of tinymce is guilty of that.

In the editors directory there are everything you need to quickly replace nicEdit with either wyzz or tinymce should you want to try that; in general though it's not difficult to swap out nicEdit for a number of other alternatives, whether it's worth doing is another matter. A possible way forward is for a javascript/jquery expert to pick on one and hack it into shape where it aggressively produces code that gmail, hotmail, mega_provider X (and jwma!) agree to markup as html and also handles Content Id. This need not of course be tied into jwma, but could be a stand alone effort. Another possibility is to do it all in java rather than javascript and make further use of the excellent jericho-html library.

Gmail takes a different approach to multipart email than does jwma; it displays everything, a plain text part and also any html part, either marked up as such if it approves of the code or just the tags and content as further quasi plain text and that looks like a real dog's dinner. You may think you've crafted a fine html message that will display very nicely for all your customers with gmail addresses. What you may not realize is that behind the scenes jwma does "the right thing" and adds a plain text rendering of your content and gmail will display that above the html version. You should be able to stop that behaviour if you must with a bit of source code hacking. The file to alter is SendMessage.java; comment out lines 224 to 226 and also 230 and you may as well also remove line 4.

Is it possible to replace the intricate html tables in the JSP files with grid-template and css retaining the appearance as is? I've twice set about this task, with some determination the second time, but comprehensively failed.

Other stuff

Credits

Not necessarily in order of merit:-
  • the original jwma team, who produced a stylish webmail app with appropriate functionality
  • but excluding David Matthews, who merely tinkered around the edges, although he did go on to do the stripes rewrite
  • Afreen Khan, who back in the day did some testing on Windows and Eclipse
  • Louis Caudwell for his readiness to help out with anything icon or powershell related
  • Rick Grashel who provided much needed advice regarding stripes and java and tomcat versions

License

Earlier versions of jwma (from 0.9x to 1.x) were covered by a BSD style license, which still applies to those files that the program has retained - for instance the files in the images directory. A copy of this file is included in the license directory in the file LICENSE.

Starting with version 2.0, the java source code files were completely rewritten and these are now covered by the GPL3 license a copy of which is included in the same directory in the file GPL.

The licenses of all bundled software including stripes, jakarta mail, jquery, jericho-html, log4j and nicEdit are acknowledged.

Old documentation

The documentation for the orginal versions (99.x to 1.0) is still available here.

version 2.0
version 2.1
version 2.2
version 2.3
version 2.4
version 2.6
version 3.0
version 4.0