<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Dear Colleagues,<BR><BR>The Eudora Release Team and the Software Release
Team (SWRT) have received a few emails inquiring into our plans for Eudora 6.x.
Most of these emails <BR>highlight Eudora 6's new spam filtering capabilities
and recommend that we release it to the MIT community. Some of the emails even
expressed confusion as to why we haven't started a release effort already. Given
our dedication to customer service and keeping our customers informed about new
software and the reasons behind our decisions whether to pursue a release effort
for them, we decided to take the atypical course of action and update the
community on a product that, as of yet, is not slated to be released to the MIT
community.<BR><BR>First of all, I would like to point out that we released
Eudora 5.2.x within the last three months. This version of Eudora contained the
crucial new functionality of enabling SMTP authentication via both Kerberos and
username / password combo over an SSL encrypted connection. Recently, we saw the
necessity of having this functionality in place when AOL temporarily blacklisted
MIT from relaying mail to its servers because MIT permitted the relay of
unauthenticated messages. Fortunately, we worked to appease AOL and made some
changes to our email servers that although not requiring authentication (a
change that would have meant denying all unauthenticated relay requests, whether
valid or not, and would undoubtedly have confused many customers due to the
suddenness of the change) did address spammers' use of spoofed MIT email
addresses. Fortunately, however, had AOL required that we require
authentication, we had a client capable of doing so.<BR><BR>Over the past three
months, we have identified three problems with our version of Eudora 5.2.x.
First, the registration does not always properly function on an upgrade, so
Eudora sometimes prompts users for the registration information after the
upgrade. Second, on Mac OS X the server port for SMTP authentication was not set
properly during an upgrade from 5.2 to 5.2.3, so users received an error when
attempting to use SMTP authentication. Third, under OS 10.3 (Panther), users
must manually enter their personal certificate in order to authenticate with our
mail servers. To address these problems, the SWRT decided to release an updated
installer of Eudora 5.2.x. We are currently working on making these changes and
plan to have an updated installer ready by early January.<BR><BR>This decision
obviously invites the question: why not bypass updating the Eudora 5.2.x
installers completely and just release Eudora 6.x? The main reasons for
proceeding with this release are: </DIV>
<DIV>a) junk mail filtering looks promising for MIT community members who do not
access their email through the MIT email servers or who want more control over
junk mail filtering rules. Testing is needed, however, to verify the
benefit of this feature. </DIV>
<DIV>b) content concentrater can reduce the amount of time necessary for parsing
through threaded discussions </DIV>
<DIV>c) HESIOD once again works for Windows users. </DIV>
<DIV> </DIV>
<DIV>However, despite these promising additions, Eudora 6.x also has its
downsides. When Qualcomm initially released Eudora 6.x, the SWRT and Mac
Development Teams reviewed the product and found that the interactions between
MIT's spam filtering and Eudora's junk mail filtering produced non-intuitive
results. The interactions, in fact, were quite complex, and we deemed them too
complex to benefit the average user without his investing a number of hours
reading over the documentation for the the junk mail settings and gaining a
better understanding of Spam Assassin. Furthermore, we have yet to determine how
much value the built in junk filtering would provide, even if we could get
it to work with Spam Assassin in a relatively simple and straightforward
way. As for the content concentrator and HESIOD support--given the
complexities of the junk mail system, we did not consider the content
concentrator a compelling new feature on its own, and the HESIOD support we only
discovered recently (within the past week--the bug fix was not listed in the
release notes). Thus, despite a feature list, particularly the native junk mail
filtering settings, Eudora 6.x proved to have its downsides that made us
question the large incremental cost (in time, effort, and resources) of
releasing Eudora 6.x over a modified installer of Eudora 5.2.x. The difference,
in time alone, is roughly 2-2.5 months.</DIV><FONT face=Arial size=2></FONT>
<DIV><BR>Now, having made the previous conclusion, the future of Eudora 6.x
looks dismal. But, because of customer feedback, we have decided not only to go
ahead with a release of an updated Eudora 5.2.x installer, but to also continue
looking into Eudora 6.x to see if we can demistify the junk mail settings for
the average user, confirm that the content concentrator is useful, and ensure
that HESIOD works consistently. Furthermore, we plan to investigate enhancements
to IMAP functionality to see if they too can help bolster the business case for
releasing Eudora 6.x. This investigative process will occur over the next month
and will either lead directly into an accellerated release process or to an
email explaining the reasons we decided against its release.<BR><BR>If you have
any questions regarding these decisions and/or our plan of action, please feel
free to email the Eudora release team at <A
href="mailto:eudora-release@mit.edu">eudora-release@mit.edu</A>. We appreciate
any feedback you may have.<BR></DIV>
<DIV>All the Best,<BR>Bryant C. Vernon<BR>Eudora Product Release
Coordinator<BR>Software Release Team<BR></DIV></BODY></HTML>