Hi
We would like to deploy SPF in a shared hosting enviroment. The main problem
we're facing is that customers are hosting their domains with us and are
strongly advised to use our SMTP (with -AUTH or -after-pop), but quite often
they're not. Instead, they're using their ISPs SMTP server.
One idea we came up with was to allow the customers to identify the
mailservers they are using in their control panel, which are then written
back to their domain's TXT records. However, before we can deploy this
solution we first have to implement it and train our staff (especially in
troubleshooting scenarios. I am convinced SPF will cause trouble when it's
not properly configured - customers listing wrong servers, "forget" to update
their SPF records etc..). However, the overall gain is much higher and with
the advent of SA 3.0 stable we are very much inclined to adopt SPF as early
as possible.
In our situation the best we can do for now is to publish "whitelisting only"
records, i.e. if the mail originates from one of our mailservers others can
consider it to be legitimate. According to the SPF specification i can prefix
mechanisms with "?" to make them neutral. If I had a domain "example.net" and
a TXT record like this:
"v=spf1 mx ?all"
do I understand this correctly that this will allow mails to originate from
all servers listed as MX in example.net (that's the intended whitelisting)
and do nothing if it originates from another server?
Are there any known compatibility issues with SPF implementations? Someone
recently did a post on an SPF implementation in qmail which was apparently
set up wrongly and started to reject legitimate mails. Such problems should
be avoided. I'd prefer if SPF could be implemented as smoothly as possible.
Another issue I can see is that SA 3.0 does not give a lot of negative points
if the SPF record is valid (probably because of the assumption that spammers
will just by new throwaway domains and set up valid SPF records). From
50_scores.cf:
#
# SPF
# Note that the benefit for a valid SPF record is deliberately minimal; it's
# likely that more spammers would quickly move to setting valid SPF records
# otherwise. The penalties for an *incorrect* record, however, are
large. ;)
#
ifplugin Mail::SpamAssassin::Plugin::SPF
score SPF_PASS -0.001
score SPF_FAIL 0 0.000 0 0.875
score SPF_SOFTFAIL 0.500 0.842 0.500 0.500
score SPF_HELO_PASS -0.001
score SPF_HELO_FAIL 0 0.405 0 0.001
score SPF_HELO_SOFTFAIL 0 1.002 0 3.140
endif # Mail::SpamAssassin::Plugin::SPF
Any other thoughts? Am I overlooking something? Experiences?
--
Kind Regards
Daniel Lorch
System administration
Hostpoint GmbH | The Data Residence |
Zürcherstrasse 2 | 8640 Rapperswil | Schweiz
Tel +41 55 220 0404 | Fax +41 55 220 0409 | www.hostpoint.ch