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