SPF was->(Re: Yahoo Developing Open Source Server Software For Spam-Resista nt E-Mail)

[John Rudd]

On Dec 18, 2003, at 9:38 AM, David H. wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> John Rudd wrote:
> <snip>
>>
>> For insecure authentication methods, provide SMTP+SSL, allowing the
>> authentication information to be protected by SSL if it's not being
>> protected by a secure SASL.
>>
> This is exactly what I mean. It introduces hassels which are almost
> impossible to deal with in a very large setup. Especially with SSL on
> multiple Server. Each Server _should_ have a properly signed SSL
> Certificate.
> Self-signed Certificates might be an option in an enviroment where no
> trust is needed, but in this setup, I want the users to also trust the
> SSl Certificate they are seeing.

I can see saying that getting an SSL cert might be expensive (for a
small provider ... but it should be inconsequential for a large one),
but a hassle?  I don't see it.  Managing SSL certs is trivial.  The
only "hassle" is that you sometimes have to wait a little while for the
first one to arrive.  After that, you just have to remember to apply
for your renewal about 30 to 45 days before the current one expires.
You deal with that once per year.  No big deal.

Even if you're putting them on to each mail server by hand, one at a
time, that's still not a big deal for your example of 20 machines.
But, that's what you get for not automating and centralizing your
administrative model.  CVS auto-updates and/or cfengine would be a good
start to automate those sorts of updates.  Even rsync (which isn't as
dangerous once you're using kerberized rsync) is better than nothing.

(in our case, CommuniGate Pro provides centralized administration of
our mail cluster domains, so I update the cert on one machine and it
automatically gets applied to all of them)


>> For password synchronization, use kerberos and multiple KDCs to
>> distribute the authentication load.  Hopefully both via plain text
>> SMTP-AUTH (because there are too many MUAs that don't support
>> kerberos)
>> and via GSSAPI-SASL for SMTP-AUTH (for good MUAs).
> Once more. Storing such data in LDAP or Kerberos is of course no
> "technical issue" but it quickly becomes an issue in very large setups.
> a) Who will be the administrator
> b) Who covers teh additional costs
>
> and so on. The problem whith prevention measures against SPAM is, that
> they cannot outweight the costs caused by bad Email.
>
> If it costs me 10K to stop Spam at a 99% level with MailScanner but it
> costs me 35K to run and administrate SPF, guess who will always win :)

Our kerberos infrastructure has cost us less than $10k in hardware, and
that's because my bosses prefer us to use full blown Solaris machines
for it.  I could have used ultra-cheap freebsd machines and spent
probably 1/4 the money on it (and with that money, I'd probably be able
to double, or more, our number of secondaries, as well).

In administrator time, I've spent maybe 20 hours of my time on our
actual kerberos servers in the 4 years I've been here.  Some people
would tell you that kerberos has a steep learning curve, but in my
experience it's only on the development side, not on the administrator
side (and there's a small and shallow learning curve on the user side).

The _most_ difficult part of kerberos is actually finding commercial
vendors that have embraced it.  PAM is a god-send in that respect, if
your OS PAM infrastructure is decent (Sun's kerberos-5 PAM module is
pretty pathetic, but there are open source ones used for Linux and
FreeBSD that are good).  On the server side, UW-IMAP, Qpopper, and
(Cyrus I think?  the one that came out of CMU) can all do Kerberos.
UW-IMAP and Qpopper will also do PAM (cyrus probably will, too, but I
don't know as I've never used it).  CommuniGate Pro (smtp, imap, pop,
webmail, mailing lists) will can do Kerberos or PAM via its external
authenticator (plain text password only, not tickets nor SASL).  I'm
not sure about sendmail, qmail, postfix, or courier.

On the client side, pine, apple mail, eudora, and fetchmail can all
work with kerberos tickets.  And, if you've got a PAM module, or an
external authenticator type module, on the server side, any client that
can do plain text passwords can work with your kerberos password.

I expect things will get better with vendor support now that MS has
adopted Kerberos ... and, IIRC, it's also a requirement for NFSv4 that
the platform support GSSAPI/Kerb5 in its secure-rpc infrastructure.


>> (here at UCSC, our new mail servers are using SMTP+SSL and plain text
>> SMTP-AUTH, that is checked against the user's kerberos password; the
>> MTA
>> is CommuniGate Pro using an external authenticator that checks against
>> kerberos
>> )
> How many point of failures do you see in that setup ? Once more an
> issue
> I pointed out above. The likelyhood thats omething goes "wrong" is
> increased by the complexity of the system.

We have 3 KDC's, one of which is a safety (it receives the key
database, but doesn't serve it out to users).  Last year, our primary
KDC crashed hard (total failure of disk drives).  It took me 30 minutes
to promote the secondary to primary status, and then just some time for
a DNS change so that "kerberos.ucsc.edu" now pointed at the secondary
machine instead of the primary machine.  During the time that took, the
only thing you could do was: create new principles (user and host
data), change passwords.  The reason for that is that the primary runs
the "kadmin" daemon, which is where all administrative stuff happens.
Promotion from Secondary to Primary is literally just the process of
setting up and bringing up the kadmind and then making the CNAME for
your primary point to the new machine (you probably also want to remove
the kpropd from your inetd.conf, as that's how secondaries receive the
key database from the primary).

If it happened again, it would take less than 30 minutes -- originally,
I didn't put all of the necessary information on my secondaries, so I
had to remember a few things in order to promote our secondary.  Since
then, I put all necessary information on all of the KDCs, so that it
really is just a matter of starting kadmind, disabling kpropd, and then
doing the DNS change.

In terms of user authentication, there wouldn't be any interruption.
Kerberos automatically fails over to the secondaries if it can't
contact the primary.  The first indication anyone outside of the
sysadmin group had that the kerberos primary KDC was down was that
someone tried to change their password and couldn't.  And that was just
during the DNS delay.  We, in the sysadmin group, noticed it was down
immediately because we monitor our hosts in BigBrother (though, we're
moving to BigSister).