On Tue, Jan 16, 2007 at 11:48:48AM -0800, Rasmus Mencke wrote:
I worked for a company that provides on-demand software; we send emails on
behalf of our customers from their corporate emails addresses.
Past tense? Anyway, my answer assumes I am talking to someone still
working for the company that provides this software.
We ask our customers to include our SPF record in theirs by using the
include tag:
"include=hostedService.com" - the problem I am seeing with Enterprise
customers is that they do not want to include our SPF record they prefer to
include the specific IP addresses. This will cause issues if we add another
IP to our mail service and would have to communicate with all our customers
each time, not really ideal.
Indeed, you should be able to manage your infrastructure without having
to bother each customer each time. And your customers shouldn't have to
worry about changes you make on your network.
Usually using IP address is most efficient. However, as soon as administrative
boundaries are crossed, the following is probably best:
your-customer.example. TXT "v=spfX ip4:192.0.2.1 include:you.example -all"
you.example. TXT "v=spfX ip4:192.168.0.1"
Your customer should use include, and you should keep your record as
light-weight as possible. Please do remember that your SPF record does
count against the total limit. If you use up all allowed DNS lookups,
there's nothing left for them, probably resulting in a PermError.
If you create a record using only "ip4", your customer should not have
to worry about this, unless they create a huge record themselves.
"you.example" can be anything. For instance, if you are domain example.com
and you provide service "xyz" to customers, the following could make sense:
"include:xyz._spf.example.com"
and you publish a suitable SPF record at domain xyz._spf.example.com.
If you use the domain that is at the top of your zone (i.e. "example.com")
then this SPF record is also used for your own mail. In that case, you
will have to use the same servers, and you will need to end your SPF record
with "-all" or something alike.
My question is:
- Are there any plans/ideas on how to manage SPFrecords that you
include, e.g. accept changes (adding IP's)
I am not saying this is recommended, or better, or anything. I'm just
answering your question:
Your customer could 'include' (not really) your hosts by using the following:
"v=spfX ... a:outhosts.example.com ... -all".
You can change DNS for "outhosts.example.com", and put a number of IP
addresses at this domain. Your client's SPF record will now authorize
your IP addresses.
- Notification if an included domain makes changes?
Not in the protocol that I know. Why would you care; the entire
"include" mechanism is invented to avoid such stuff.
- How would I as an email administrator know that some random
server/IP has been added to the include SPF record?
- How would I know if the include domain, includes another domain to
their record?
Follow the chain by hand. But why would you? If you as a customer do not
trust your supplier, the next supplier is there --->
Alex
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735