After working with the Eric Shanbrom of the Message Support Team at Ipswitch
on Monday (10 April, 2006) afternoon, to resolve some problems relating to
the directory permissions the installation of Imail 2006.3 on a new server,
I am satisfied with that I have installed and configured the latest version
of Imail, version 2006.3, to with the best possible configuration possible
to give both the maximum security under the circumstances.  Thanks for your
great support work, Eric!


SERVER CONFIGURATION:

 - Dell Poweredge 2850 Rack Mount Server
 - Dual 3.4 GHz Xeon processors with 2 MB cache and 800 MHZ FSB
 - 4 GB Ram
 - 1 Raid Level I drive for OS - 2 mirrored 146 GB, 10K SCSI drives with
data transfer rate of 320 MBs
 - 1 Raid Level IV for data, consisting of 4 146 GB, 10K SCSI drives with
data transfer rate of 320 MBs
 - Dual 10/100/1000 nic
 - Redundant power supplies
 - Windows 2000 with all service packs


INTRODUCTION:

Given the complete change in the manner in which the software is now
operating, ie: all of the programming is no .NET based and fully able to
integrate within a standard webhosting server while allowing other websites
to run simultaneously, there were/are bound to be some issues with the port
of the software, and I think Ipswitch will be able to pull Imail out of this
temporary hole that seems to have grown up around all of the problems that
many of us have experienced during our transitions.

After having a chance to poke around my new installation a bit, I have come
to the following conclusions regarding Imail version 2006.3:


ENHANCEMENTS:

 1. The new Imail software appears to have significantly increased the
ability to properly scan messages for spam according to the anti-spam
settings within the software.  It also appears to have repaired the
Whitelists feature that allows incoming messages from domains or addresses
that are white listed to bypass the anti-spam features according to the
selection made by the top level administrator of the system.

 2. The new software alphabetizes all of the lists, white listed domains and
all of the other types of lists when the full list is requested to the
screen.  Note that even on an extremely fast, multi-processor server, this
new sort ability DOES slow down the appearance of any such list to the
screen when the full list is requested, and requires patience on the part of
the person doing administrative updates to any such list.

 3. The new software allows a list administrator to do a partial SEARCH for
an e-mail address.  This is a SIGNIFICANT improvement.

 4. The new software allows a search to return a result irregardless of the
status of caps within an e-mail address.  ie: if an e-mail address within a
list is "FirstLast @ domain . tld" and a search is done for "firstname", the
address is properly found and returned.  Partial searches are allowed.  Case
is no longer sensitive.  Again, this is a SIGNIFICANT improvement over the
previous version (8.22) of the list handeling portion of the software.


PROBLEMS:

 1. Because of the manner in which the ADMINISTRATIVE portion of Imail
2006.3 works, it is no longer possible for  a customer to maintain their own
lists and users.  IE: To have full WEBADMIN access to a domain that is
hosted on one of our servers by someone who does not have a LOCAL MACHINE
ACCOUNT with administrative access means that they will be constantly
interrupted by the LOCAL MACHINE LOGIN that persistently pops up requesting
a LOGIN USERNAME. PASSWORD and the DOMAIN NAME for the machine on which the
e-mail is hosted.  For security purposes, we cannot grant every customer a
local login to the machine.

This means that someone who is supposed to have WEBADMIN access to be able
to either:

 - Maintain users on a particular domain
 - Maintain lists

cannot do so without having a LOCAL MACHINE LOGIN account that has FULL
ACCESS.  Again, giving someone a LOCAL MACHINE ACCOUNT with FILL ACCESS is a
high security risk.


 2. The ability to set the WEB BASED e-mail interface to PLAIN TEXT as
DEFAULT does NOT EXIST.


 3. The ability to force all incoming e-mail to be converted to PLAIN TEXT
is no longer available.  This tool is being used more and more frequently by
customers with a corporate policy that does not allow HTML BASED e-mail to
be received by users.  Examples of agencies who currently enforce this
policy are the State of Illinois, the University of Illinois MANANGEMENT
E-MAIL GROUP - not the student e-mail accounts, the University of Chicago
Hospitals, etc.  In our case, we host e-mail for 4 surgery centers and they
want PLAIN TEXT ONLY E-MAIL for ALL INCOMING and OUTGOING messages to
eliminate the possibility of pictures and scripts being embedded within the
messages.  The possibility of converting all incoming messages to PLAIN TEXT
was introduced in 8.22 and, apparently, has been removed in 2006.3.

NOTE: I fully expect that several members of this list will now attack me
based on the fact that this type of filtering is "inappropriate".  I can
only remind them that we respect our CUSTOMER'S WISHES.  Whether you agree
with this manner of filtering or not is irrelevant and I will ignore any
attacks.  If my customers want their incoming messages converted to TEXT
BASED MESSAGES with all HTML CONTENT stripped out, that's what they will
get.


 4.  While this issue may be related to a permissions issue, all of the
accounts I am using under my administrative logins have FULL access, and I
am still experiencing problems with updating the LDAP information for any
but the MAIN domain.  It appears that no matter what I change a field to
read, the system returns the field back to what was previously in the fields
as the DEFAULT data.


 5. It is no longer possible to make a CHANGE to an e-mail address in a
list.  You must now DELETE the old address and enter a NEW address to make a
CHANGE.  In the prior versions of the list maintenance software, making a
change was easy because you could locate the address to be modified, make
the change and then save the updated information.


 6. I may have missed this, but I was of the understanding that the DOS
attack counter and the ability to set the ALTERNATE PORT (587) and FORCE
AUTHENTICATION on that port were going to be part of the DOMAIN
CONFIGURATION within 2006.3.  If I missed the location of these features,
would someone please point out to me where they are located?  If they are
not included, I hope they will be included within the web interface in a
future release.


NOTES:

 1. The DEFAULT administration address for, administration when working at a
LOCAL CONSOLE session, is now http://127.0.0.1/IAdmin or
http://localhost/IAdmin.  To use this address for the default administrative
address on a new server that also does regular webhosting under IIS 5 of IIS
6 is not allowed because the ADMINISTRATIVE and HELP websites for IIS 5 and
IIS 6 use those addresses (without the IAdmin directory) as the web based
configuration utility for IIS.  The Imail installation also appears to
modify permissions on the DEFAULT WEBSITE DIRECTORY no matter where Imail is
installed to on the server.  This situation of modifying permissions on the
DEFAULT IIS WEBSITE DIRECTORY should be removed from the installation
program.  The only place anything should be modified is to the ACTUAL
INSTALL directory and NOT on the DEFAULT IIS directory.  There also appears
to be another bug in the installation program as well - ie: even if you tell
the installation program NOT to modify the IIS permissions, the installation
program still modifies the IIS permissions.


SUMMARY:

 - All-in-all, a reasonably good job, considering the immense amount of work
required to make the changes between the two types of programming in the
port of Imail from 8.22 to 2006.3

 - The permissions issue still needs to be addressed.  Even with the
creation of a special IMUSER_LOCALMACHINENAME account to be used for
anonymous access by those who are just checking e-mail via the web
interface, I am still not completely comfortable with the fact that an
anonymous access account has FULL access to a directory on a production
server.  Given Microsoft's penchant for producing buggy code to begin with,
this could be a potential security loophole that might be exploited in the
future.

 - The ability of WEBADMINS for specific domains to update the USERS and
LISTS should probably be moved to the ICLIENT portion of the program to
allow WEBADMINS to make changes to their users and lists.

 - Even with the permissions properly set, there still appear to be problems
with LDAP.

 - The list server portion of the mail server still needs to be rewritten to
allow DOUBLE OPT-IN subscription to lists and the handeling of BOUNCES.
When that is done, it would be nice if there parameters for the bounces were
settable within the software.  It would also be helpful if those settings
were an OPTIONAL item for ISP owners to either ALLOW or DENY users with
WEBADMIN to make changes to the settings.

 - The instructions for the installation of 2006.3 are somewhat lacking with
regard to the integration of Imail 2006.3 with IIS 5 and IIS 6.
Specifically, there is a lack of information regarding the necessity of the
setup of VIRTUAL WEBSITE NAMES within the IIS configuration that will allow
users to access webmail via a commonly used web URL, ie:
mail.domainname.tld.  Given that this is a new setting for most Imail
owners, this should probably be more detailed, along with the necessary DNS
entries required to allow access to what might be new URLs.

 - Overall, Imail (2006.3) appears to be both stable and integrate well with
IIS and allows the ability of a server to now handle both e-mail and
webhosting.  This will have the net effect of allowing small ISPs and
businesses to save money as they upgrade existing equipment to take
advantage of faster multi-processor capabilities, expanded hard drive
storage and faster redundant networking configurations.  Once the issues of
the permissions and maintenance of both users and lists is resolved, this
will be an excellent product.


Bruce Barnes
ChicagoNetTech Inc
Chicago IL

To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

Reply via email to