Re: [MLUG] postfix + SPF

[Herbert Wolverson <EMAIL:PROTECTED>]

On Wed, Aug 18, 2004 at 03:15:49PM -0500, Mike Miller wrote:
> On Wed, 18 Aug 2004, Rick Buford wrote:
> 
> >Has anyone running postfix (1+ or 2+) tried implementing SPF yet? I'm 
> >curious about any experiences good or bad.
> 
> No, but it sounds like a good idea.  I would be concerned that a DNS 
> failure might cause a delay in message delivery.  That has nothing to do 
> with Postfix though.  Has anyone used SPF at all?  (This is the first time 
> I ever heard of it.)

I published SPF records for the domains I control, largely because Hotmail
are indicating that at some point they will drop mail from non-SPF publishing
domains. My clients would kill me if they couldn't email their Hotmail friends!

I use qmail_ldap for mail here, and the SPF patches are a pain in the butt to
add to our existing (patched to hell and back) qmail codebase. I'm waiting for
the next release of SpamAssassin before checking it at all, and then it will
only be as an advisory flag. The more flags our spam filter has to go on, the
better!

In general, though, I don't like SPF very much. TXT records were never
intended for this, and I had to redo part of our DNS infrastructure to
make use of them (not least because brain-dead SPF implementations were
getting confused by my including comments in our domains; so I sacrificed
easy maintainability in the name of making SPF work). SVR records WERE
designed for extensible services like this, but many providers don't let
users modify their SPF records - so the SPF people decided against using
them. SPF also makes life difficult for people who don't have the option
of maintaining their own DNS records (for example, a lot of cheap web
hosts). That puts the user at the mercy of their hosting provider,
probably meaning "use our crappy SMTP server, or have your mail flagged
as spam everywhere". It is also impractical for travelling users who
run an MTA on their laptops to have everywhere they might possibly go
listed, although you can get around this by having a listed authenticating
smart host. SPF really breaks mail forwarding (a biggie for anyone
who offers the service), requiring either an envelope-rewrite hack, or
a switch away from forwarding. Finally, I don't think it'll do much
against spam at all; most spam is sent by 0wn3d zombies, and it wouldn't
be hard to pick up a lot of domains (bulk domain buying by spammers is
nothing new) with SPF-permit rules covering entire banks of zombies.
Spammers aren't stupid, they are pretty good at getting around things!
(I don't buy the source-IP spoofing argument against SPF; TCP is very hard
to source-spoof, and unless that changes, I don't see much forged mail
being sent that way).

I'd prefer a system involving crypto-signing mail (if it isn't signed, you
didn't send it), but that's probably impractical. A compromise, whereby
domains can publish a public key in their SVR records, and authenticated
clients are automatically signed against the relay servers private key+the
public key of the destination might be possible (for validation, like PGP,
with the recipient server's private key and the sender's published public
key). You wouldn't be able to send from non-authorized hosts without a
login to the authorized relay(s), and without their private keys you couldn't
sign mail correctly. Of course, that'd just put a premium on 0wning mail
servers....

-- Herbert.
_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members