rogerk(_at_)queernet(_dot_)org wrote:
Quoting Koen Martens <spf(_at_)metro(_dot_)cx>:
Besides, i don't see how getting your domain blacklisted is going
to help your customers send their legitimete email...
Damned if you do, damned if you don't. So fuck the users and their needs, eh?
Well, ignoring the flamebait... spammers and worms have already done
that for e-mail. And where you stand on the issue largely depends on
whether or not you've been maliciously joe-jobbed in the past or had to
deal with hundreds of thousands of misdirected bounces.
It all boils down that as a mail administrator you have a few options:
1) Don't publish SPF information for your domain, or make it overly
broad and permissive.
+ no additional work required
~ status quo
- your domain is just as likely to be forged as before
2) Publish a restrictive SPF record (/24 or smaller or A/MX only) and
require that all users use SMTP AUTH to submit mail through specified
servers.
+ assuming the receiving server checks SPF, the only way to forge your
domain is to break into one of your outbound mail servers or hijack one
of your user's machines
+ you can add encryption to the POP3/SMTP traffice while you're at it,
reducing the ability of someone to sniff passwords
- requires additional user training
- there are always corner cases where someone is not able to access the
SMTP AUTH server from their location
3) Do something in the middle of the two extremes.
For the company that I work for, we're publishing extremely restrictive
SPF records with a "-all" on the end. Any of our users who are working
remotely already VPN into the network to get files from the file
servers, so they're already able to talk to the outbound mail server.
If our users want to send greeting cards to each other then they can
sign up for a personal webmail address somewhere.
We've been joe-jobbed in the past (maliciously) and we're tired of
seeing thousands of bounce notices for e-mails that we didn't send.