[3904] in Release_7.7_team
Minutes of 2003-07-02 release team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jul 2 14:39:44 2003
Date: Wed, 2 Jul 2003 14:39:42 -0400
Message-Id: <200307021839.OAA15782@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Attending: ghudson zacheiss wdc rbasch miki amb jweiss
1. SMTP authentication
Greg and Jonathon attended the 2003-07-01 SMTP auth meeting in N42.
Here is the summary:
* The primary goal is to reduce the potential for using the MIT mail
hubs as spam relays by authenticating all user-generated mail.
* A secondary goal is to give users a way to work around ISPs
filtering port 25, as RCN is currently doing, but only if they use
SMTP authentication. The network group hopes to use ISP filtering
as a hook to get people to change over voluntarily, although only
a minority of the user base will be affected.
* Currently they are supporting SASL authentication on port 587
(STARTTLS or GSSAPI) and SMTP over SSL on port 465. They also
appear to be offering KERBEROS_V4 on port 587 and GSSAPI and
KERBEROS_V4 on port 25, but those appear to be mistakes based on
what was said at the meeting. The recommendation is to use port
587 if possible.
* Their target date is to have all user-generated mail switched over
to SMTP authentication by 2004-07-01.
Ideally, this is what we'd like to do in 9.2 in order to go along with
this plan:
* For user-generated mail, sendmail should attempt to submit the
mail to outgoing using GSSAPI authentication. If submission fails
for any reason, an error should be reported back to the calling
process, rather than queueing the message.
Costs:
- If outgoing is down, mail cannot be queued and delivered
later.
- Mail cannot be sent while off-net; MUAs will have to be
responsible for providing any kind of disconnected operation.
(This means the local sendmail daemon we run on disconnectable
machines is no longer of value.)
- Mail cannot be sent if your tickets have expired.
* For system-generated mail, sendmail should deliver the mail
directly.
There is no good way to differentiate between system-generated mail
and user-generated mail; the best test is probably to look for
Kerberos tickets in the environment. That probably requires a
front-end script. Garry will look into implementing this stuff.
2. Solaris dad-134 update issue
miki is working on this, but it continues to be mysterious. The next
patch release will include a safety measure in update_ws to prevent
affected machines from trying to update.
3. Status of the release
We have many bugs which weren't found during beta. Hopefully all the
showstoppers have been addressed in the forthcoming patch release,
which should go to the dev cell today or tomorrow and to the athena
cell next Monday.
The release is currently scheduled for July 14, assuming we can get it
in working shape by then.
We don't have KNFS yet, but miki will try to have it ready before the
14th.
4. Mozilla
Bob has prepared a patch for the byte-order problem, but would like it
approved upstream before applying it locally.
Bob will look into upgrading Mozilla to 1.4, although he has some
doubts about the timing. (There are sometimes problems with recent
releases on Solaris, as was the case with 1.3.1.)
5. Red Hat Enterprise Edition
Red Hat is apparently moving to a model where their free product is
faster-moving and less stable, and their expensive product (Red Hat
Enterprise Edition) is slow-moving and more stable.
We are very reluctant to use Enterprise Edition as a base because it's
less well-known on the net (in terms of being able to download RPMs
for popular software, for instance) and among non-Athena Linux users
at MIT. If the situation with regular Red Hat becomes intolerable, we
will have to reconsider. (There is also, of course, the option of
ditching Red Hat altogether, though that would be traumatic at best.)
6. Status report
Sent under separate cover.
