On Tue, Aug 03, 2004 at 02:09:55PM +0200, Daniel Lorch wrote:
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.
Well, this is problematic. How should a customer find out which servers might
be used by his isp for outbound smtp? He really should call them, and ask. And
even then, what if the isp decides to reconfigure it's outgoing smtp server
farm? Without the isp providing spf records of it's own, there's no way to know
for sure & keep up with changes. Even then, allowing the isp's smtp servers
allows all customers of that isp to forge mail from the domain in question..
It would be nice if you could convince your customers that it really _is_
necesarry to send mail through your smtp server, but I realize this is nearly
impossible.
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?
Yes.
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.
The problem was that his qmail implementation was set to reject mail if spf had
a fail record and if the domain did not have an spf record it all. It was too
strict, and I think the result of lack of proper understanding of spf.
If you are going to deploy spf for your customers, you should have a thorough
knowledge of how spf works and what it's implications are (eg. get into the
forwarding issues).
Koen
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
pgpJm6l5S7WNo.pgp
Description: PGP signature