response 385 of 547:

May 29 03:07 UTC 2003

We finally received our OpenBSD CDs today - it took them 16 days to get here
from Calgary.  Stickers were included.

response 387 of 547:

May 29 13:43 UTC 2003

I don't know what his plans are, but I'd be surprised if he didn't seriously
consider alternatives.  I think the port to OpenBSD is going to be a bit of
a "start over" for him even if he decides to stay with sendmail, because
moving all his modifications into a current sendmail release is going to
be nearly as much work as switching to a different program.  I don't think
he's really all that fond of sendmail.

response 389 of 547:

May 29 17:05 UTC 2003

I use Exim, and it's certainly easier to configure than sendmail.  It
has a good, flexible filter language, too.  It doesn't have the same
privilage seperation features as Postfix, though -- it's still a
monolithic binary.

response 391 of 547:

Jun 3 07:14 UTC 2003

Major overload here.  Hm.

Regarding old hardware.  Even when we switch over, we'll want to keep
the old stuff intact for at least a bit in case of some sort of truely
disastrous problem with the new hardware.  Once we're comfortable, then
we can decommission it.  The disks, being slightly newer, may have some
slight use for other small projects.  Much of the data on them doesn't
really matter, but for mail, spool, user files, swap, and /etc, we
certainly want to scrub those before using them for other purposes or if
we decide to sell or give away any of them (even to my basement
collection).  Scrubbing them *is* going to be an easier way to ensure
reasonable security than destroying the disks.  This is because
sufficient physical destruction has its own issues.  Disassembling
things then bashing them with a hammer and using a bulk eraser may make
data recovery more difficult, but it may still leave traces of data that
could be recovered by the same sort of determined adversary that could
recover data from a "single overwrite of all 0" drive.  If that is the
level of security you want, then physical destruction would require
either a fairly good acid bath of all disk surfaces, or probably better
yet incineration of the aluminum platters.  No doubt we have pyromaniacs
would would enjoy doing this, and there are certainly services that will
do this (for a fee), but we'd probably be better off reserving these
drives for future small projects (such as offloading mail processing,
kerberos, etc.) or doing a multiple overwrite scrub procedure then
selling them on ebay.

Regarding kerberos.  Cross and I clearly have a unreconciable difference
of opinion here.  I'm clearly not going to change his opinion, there
seems little likelyhood he'll change mine, and I doubt most others share
even my level of paranoia or care all that much.  So I don't want to
waste time arguing this.  Cross (and any others who care) is welcome to
change his password just before & after switching to kerberos, which
should cover any personal concerns he may have.  Root & other passwords
will almost certainly change or be addressed by new mechanisms - this is
almost inherent in any switchover in any case.  Once we switch to k5,
baring unexpected changes to the standard, changing one's password will
likely result in a standards compliant k5 key at least potentially
useful from other machines.

Regarding mail.  Hm, I think some of this scrolled off.  Yes, we want to
keep hierarchical mail boxes.  The 4 possible mta's include exim,
postfix, current sendmail, & legacy/hacked sendmail.  Unfortunately,
mail is an area where we have significant functional requirements, which
means any stock solution out of the box will almost certainly prove
unacceptable.  One functional requirement is mailbox quotas, which at
least has simple design parameters.  Another functional requirement is
anti-spam logic, which is both controversial and important.  A final
functional requirement, unfortunately, is that this all needs to come up
in some finite amount of time.  I intend to look at exim & postfix, with
a view that one of these should a good enough base to support the
functionality we want.  As a fallback position, I am at least somewhat
willing to consider installing the current legacy/hacked sendmail, with
the understanding that it's both temporary and very very undesirable.  I
hope to spend time coding to avoid this possibility rather than
composing lengthy responses defending whatever choices I make here.

Hm.  Surely I've said at least half of this somewhere already?  Is this
useful?

response 393 of 547:

Jun 3 08:10 UTC 2003

(re: anti-spam logic:  I agree that a procmail/spamassassin combo would be
a good move.  nearly all of the spam that I receive at my Grex account is
sent via open relays, which both SpamAssassin and SpamCop [via reporting]
recognize and flag as such.  whatever Grex is currently using, obviously,
does not.  given Grex's culture, I understand the reluctance to outright
block mail from open relays, but I'd like to think that, with Next Grex,
we should have sufficient processing capability to flag such mail.) 

response 395 of 547:

Jun 3 17:02 UTC 2003

That begs the question, why bother with Kerberos at all, then?

I don't understand how other, much larger sites get away with stuff like
using spamassassin on all incoming mail, and otherwise working on stock
anti-spam solutions, but grex can't do it.

Regarding timeframes; well, grex has already blown its one year timeframe.
Given that, it seems most profitable to just use the BSD login API to
deal with the custom hash algorithm and skip Kerberos for a later day.

response 397 of 547:

Jun 3 18:34 UTC 2003

I think the problem he has with spamassassin is more the principle of it.  We
still have to accept the mail, we can't slam the door in the spammer's face. 
With the new system the extra processing penalty of having to accept the
whole message before deeming it spam is probably not as important.

I've seen some really poor spamassassin results on a few mailing lists I've
been on, but part of that may have been poor configuration.  On one list in
particular spamassassin seemed to flag every message sent from Mozilla as
spam, while missing a lot of *real* spam.  I've kind of shied away from it
for that reason.

response 399 of 547:

Jun 3 21:45 UTC 2003

(my vague recollection is that Kerberos will allow Grex to offload mail
processing to another machine in the future.)

response 401 of 547:

Jun 3 22:40 UTC 2003

(The problem we are trying to solve, if I recall correctly, is network
bandwidth, NOT CPU/disk/etc.  In that sense, the door is being closed
fairly quickly:  my understanding is that the mail is being rejected
before the SMTP 'data' command.)

response 403 of 547:

Jun 4 05:53 UTC 2003

Kerberos does 3 things for us: gives a more graceful way to deal with
our existing password hash data, allows us to start developing
distributed applications (such as file service, mail, conferencing,
etc.), and eventually (if standards and availability permit) may allow
us to offload client side stuff to user workstations.  The first is
immediately useful to us all on its own.  The 2nd could be useful in the
next 1-5 years.  The 3rd is "pie in the sky" for now, but not
impossible.

response 405 of 547:

Jun 4 17:11 UTC 2003

Again, I think it would be easier to use the BSD login API to deal with
the custom hash algorithm now, and find some other way to transition to
a standard Kerberos KDC.  Particularly if you're not considering moving
to distributed services for another 1 to 5 years.

response 407 of 547:

Jun 5 02:31 UTC 2003

The first is the reason to do kerberos now rather than wait another 1-5
years.  The second is the reason we want to do kerberos.  The third is
the biggest but longest term and least likely win.

kerberos 5 does do md5.  But the md5 there has nothing to do with Unix
md5 password hash.  The unix md5 password hash was an early example of
"computationally expensive" hash logic -- see above.