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

David H. dh at UPTIME.AT
Thu Dec 18 17:38:02 GMT 2003

Hash: RIPEMD160

John Rudd wrote:
> 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
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.

> 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 :)

> (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.

- -d
Version: GnuPG v1.2.3 (Darwin)


More information about the MailScanner mailing list