FAQ wiki page for AngleMail?,

The standard Email application for eGroupWare.

Who maintains this FAQ

Anyone who has something to contribute. I, angles, will begin adding content soon. It is anticipated this will be a work in progress, with the good stuff eventually going into some type of document management software.

---

Where's the spellchecker? Is there a php4-pspell deb?

The php needs to be compiled "--with-pspell" and maybe also "--with-ispell", this
spell extension must be statically compiled into php at compile time.

Then the spell capability (the php compiled-in "pspell extension") is automatically
detected by anglemail, if your php "can spell" then you get the spell check button,
if php "can not spell" then you so not get the spell check button.

The ispell stuff is slowly being replaced by the pspell stuff, see pspell.sf.net for
more info. RedHat? php rpms are compiled with "--with-pspell", however I have heard
of some older php sources on some older Debian boxes not compiling when
"--with-pspell" is specified (or compiling but not working correctly?). Debian does not provide an official php4-pspell module, see the HOWTO a few lines down to use unofficial debs, which are very stable (and more recent).

Use the phpinfo() command and look for "pspell", also you may want to visit:
http://www.php.net/manual/en/ref.pspell.php

Also, if your server is Winbloze, those docs currently indicate the pspell
"extension is not available on Windows platforms".

Debian php4-pspell HOWTO: (this doesn't seem to work if you're using postgresql .. you will have to compile php)

• add the following lines to your /etc/apt/sources.list

#Unoffical PHP4

deb http://kalug.linux.org.tw/~chihchun/debian/php4 ./

deb-src http://kalug.linux.org.tw/~chihchun/debian/php4 ./

deb http://kalug.linux.org.tw/~chihchun/debian/pdflib ./

deb-src http://kalug.linux.org.tw/~chihchun/debian/pdflib ./

• Run the following commands

# apt-get update

# apt-get php4-pspell

# apt-get install libc-client-ssl2001-dev

(Note i will whinge about a dependency problem

- ignore it - the dependencies in the package are wrong )

# apt-get install iamerican (or whatever language you want to use)

# apt-get install libpspell-ispell1 }

• Enjoy a working spell check in Email again :)

---

When is a sent folder really is a sent folder?

If your preferences do not have the "use sent folder" checked, then AngleMail can never say you are looking at your "sent" folder. Even if the folder name is "sent" and you're looking at a list of messages in your folder named "sent", if that preference is not checked, it is not considered your "sent" folder.

In testing the sent folder stuff I would make folders named "Sent", "Sent Mail", "Sent-[BS]", etc... and alternate the preference for "the name of your sent items folder" between these. The problem is when you uncheck that pref that says to actually use the sent folder, then you do not really have one. Therefor the message list in that folder shows you who the messages are "From" and not who you sent them "To" because it is not officially your sent folder according to the prefs you do not
use one.

That option can become "unchecked" if you switch from IMAP to POP3 back to IMAP. Since pop3 does not have folders, a the prefs unset the "use sent folder" pref because it is not possible in pop3. But if you switch back to IMAP, it is not obvious that you need to goto the preferences page and re-check that preference, but until you do that you do not have a sent items folder, even it there is a folder named "Sent", if that pref item is not checked to "use sent items folder".

---

I get an error while trying to add an attacment on email, what gives?

• Look at this page: http://www.php.net/manual/en/features.file-upload.php and see where it says:

"See also the file_uploads, upload_max_filesize, upload_tmp_dir, and post_max_size directives in php.ini", Check into each of those values.

• Note that the change on GLOBALS as of PHP 4.1.0 is not an issue, AngleMail handles both types, although I think phpgw requires register_globals = on.

• On that same page, also see this user comment:

michaelpearl at mac dot com
04-Mar-2002 03:05
When uploading very large files (greater than the default 8M) I found that I had 
alter not only the "max_file_size" input and the php.ini max_file_size limit, but 
ALSO the "post_max_size" variable in the php.ini file.
Because I was submitting the file via a POST request, it would hit this limit 
and deny the upload.

• And see this user comment:

jeroenHATESSPAM at NOSPAMvogelpoel dot com
16-Apr-2002 05:50
Don't forget to allow file uploads by other users for the directory you 
use as file-upload destination. Same thing for the temporary-file directory. 
Just CHMOD the directories to 777 and it should work, granted the PHP code 
itself is working okay.

• And see this user comment:

kurmie at wanadoo dot nl
17-Oct-2002 08:59
Uploading huge files still remains a problem, even after you've set 
upload_max_size and post_max_size to reasonable sizes (in my case respectively 
the defaults 2M and 8M).
MAX_FILE_SIZE is often ignored and php doesn't cut in to stop the transfer, 
so if you're using Apache (i'll bet you are) try limiting transfers with 
LimitRequestBody. Be advised that you don't set this directive too low, or 
Apache will return a document without data.

• And see this user comment:

g dot kakanauskas at paciolis dot lt
30-Nov-2002 12:40
If you are planning to upload large files and use the script used in the 
description, do not forget to set max_execution_time in php.ini to a 
reasonable value, because it seems like the script is running until the 
upload is over and you will get Fatal error: Maximum execution time 
of xx seconds exceeded.
The error occurs only AFTER the file is uploaded and I believe it's 
because php wait's for $_FILES variables to appear too long...

• And see this user comment:

travis dot lewis at amd dot com
04-Dec-2002 01:58
If you we dumb like me you installed Redhat 8.0 and kept the default 
install of packages for Apache 2.0 and PHP4.2.2. I could not upload 
any files larger than 512kB and all the php directorives were set to 32MB or higher.
memory_limit = 128M
post_max_size = 64M
upload_max_filesize = 32M
[snip]
However, the insiduous php.conf (/etc/httpd/conf.d/php.conf) file used by 
default RPM install of Redhat httpd has a LimitRequestBody set to 
512kB ("524288" ). Adjusting this to 32MB ("33554432") got things going for 
the larger files. Here is my php.conf file in its entirety. Hope this 
helps someone. L8er.
[snip]

---

Do I need anything special to run AngleMail on RedHat??

Summary: Email does not need any special rpm depends.

Email can work without the imap extension (on RedHat? that is the "php-imap" rpm) but only POP3 is working with pure sockets (no php-imap = sockets).

The spellcheck only works if pspell is compiled into the system's php, this is not really an RPM dependency, Email still works without it.

The internationalization support of foldernames uses the "utf7" functions in the php-imap extension. But since only POP3 works in sockets mode, and POP3 has no folders, this is not really an issue. Also, there has got to be some code somewhere that can do the utf7 stuff in simple php, it is not that much different than uuencode, just replacing char sequences.

Email in the CVS prior to the import of AngleMail into the CVS probably worked with php3. Anything "anglemail" needs php4, there's too much good stuff in there, faster array functions and such, I had to drop support for php3.

---

What's the deal with AngleMail and caching?

Here's the difference between the session caching and using the phpgw_anglemail table (installable via the setup app).

1) sessions_db
If your phpgw install uses session "db" then AngleMail uses the table phpgw_app_sessions for its caching. The main problem with this is that the data is limited by the "content" field varchar(255). Quite often the msgball list (the list of messages in a folder) for larger folders (1000+ messsages) does not fit in the table. That means that the Email app must get this list from the mailserver EVERY TIME it needs it, probably one or more times per page view.

• the content-field is even for 0.9.14 of phpgw-type text (longtext on mysql) -- RalfBecker

2) php4 sessions
If your phpgw install uses php4 session then AngleMail uses that php4 session mechanism for its caching. The problem with this is that Email caching is probably an "overuse" of something which apparently is meant to store a more limited amount of information. What this really means is that with every pageview ALL the Email cached data is loaded into memory, whether it is needed at that moment or not. This is how php4 sessions work. Also, for what it is worth, php4 session data is stored in a tmp dir that may or may not be easier to view than the data stored in the database.

• don't know why, but php4 sessions are very limited in the space they can provide, much more then our db-sessions.

3) table phpgw_anglemail
Installs via the setup app, so it is user friendly. It is not *required* at this moment, so if an admin forgets to run the phpgw setup app to upgrade stuff, AngleMail still works as before using the session cache. It is not limited to varchar(255) of content so the larger msgball lists will be cached, and only loads cached data into memory if it is something that the Email app needs and has requested from the database.

Summary
It is highly recommended that you install the AngleMail phpgw database table, you can do this using the eGroupWare setup application, it will look like a database upgrade, the same as for any other application.

Although you can use AngleMail without the AngleMail database table (using either sessions_db or php4 sessions), this will NOT activate the more advanced features of AngleMail and its caching. Only by installing the AngleMail table do you get the increased performace, and eliminate the limitations associated with the simpler session-only data storage.

---

How does Email know what password to use for the mail server?

In the Email prefs, if you uncheck "Custom E-Mail Settings", (assuming it had been
checked so that you may uncheck it), when you submit, AM detects the "Custom E-Mail
Settings" is not checked and it wipes all those custom prefs from the prefs DB for
email, so all the settings get picked up from the phpgw api setting instead.

Then, later if you check "Custom E-Mail Settings" and fill in a few things but NOT a
custom pass, AM will continue to pick up the pass from the phpgwapi prefs, at some
point if you do check "Custom E-Mail Settings" and also specify a custom pass, the
only way to wipe it is to uncheck "Custom E-Mail Settings" and submit.

Also, (cw)? notes that if you're using mail auth in phpgw then the api will never
read the password field in the phpgw account table.

NOTE: this answer applies to eGroupWare version 0.9.14, the preferences system may change for eGroupWare version 0.9.16, which may effect this answer, (or may not!).

---

How do I make another image theme for AngleMail??

The icon themes are now groups of images in their own subdirectory. The subdirectory name is the name of the theme, in that directory the images all have common naming scheme. Right now Email has these themes (and image subdirectories): "moz", "evo", "noia", and "aqua".

New icon themes are made by doing this:

• select a group of images you like, enough to fill all the places where images are supposed to be, and have available larger and smaller versions of these images.
• think of a name for your icon theme, for example "winbloze"
• make a subdirectory called "winbloze"
• look at the existing images naming conventions used for the images, and rename your images appropriately
• add your "winbloze" theme to the Email preferences array. For phpgw version 0.9.14 look in file Email inc class.bopreferences.inc.php and see the example there. For your installation you could even change the default to "winbloze" too.

If you make a new template theme for eGroupWare as a whole, your template can also have its own icon theme (group of images) be one of these image themes available to the Email application, by following these steps.

In the future, when Email preferences are updated for phpgw 0.9.16, admins can force a certain Email icon theme for all users, if they like. For eGroupWare 0.9.14, this can be done by editing the preferences array as noted above.

For phpgw version 0.9.14, the phpgw api has yet to be amended to handle images in subdirectories, so I have a temporary function called "_image_on" in file class.mail_msg_display.inc.php that I use as a substitute until the api is edited.

Also, that replacement "_image_on" function prefers "gif" images, but you should provide both png and gif versions, because the newer api will probably be able to prefer either of these.

---

Look in this file:
email/inc/class.mail_send.inc.php

Scroll down till you see this:

// START CHANGES JF
// lets assume for the purpose of testing that these variables were already set up somewhere.
// That still needs to be done properly.
// angles: this is a temp handler until it gets in the email site setup page as site option
$smtp_auth_login_required = False;
//$smtp_auth_login_required = true;
$mylogin = "xxxxxx";
$mypassword = "xxxxxxxxxx";

CHANGE TO THIS:
//$smtp_auth_login_required = False;
$smtp_auth_login_required = true;
$mylogin = "your_smtp_login_here";
$mypassword = "your_smtp_passwd_here";

---

---

If you add more to this that is a "good thing"!

---

back to eGroupWare applications / Email