--Bob Poortinga <spf(_dot_)10(_dot_)bobp(_at_)antichef(_dot_)net> wrote:
SPF in its current form implements a method for domain name administrators
to express policy through TXT records in the domain name space. SPF
could reasonably be extended to express policy for IP space administrators
through TXT records in the IN-ADDR.ARPA name space, e.g:
1.168.192.in-addr.arpa. IN TXT "v=spf1 -all"
would mean that *no* hosts in 192.168.1.0/24 are authorized to initiate
SMTP sessions.
I actually agree with Bob that this is a good idea (i.e. putting policy
records in in-addr.arpa domain similar to SPF for normal domains).
There is a fundamental difference, since it is not really associated with a
domain, it's more of a "usage policy of this network" and not a policy for
the domain name. My guess is that some other "policy framework" would be
good for this. It's probably outside the scope of SPF as we know it, but
some of SPF's mechanisms might be good for this-PF too.
The general idea might be some policy like, "This is residential end-user
space, and users in this range are not allowed to run their own servers.
Mail should not be trusted unless you authenticate the user to your own
server."
It could also be expanded to "users should not be accepting http, ftp, DNS
requests"
One other thing that I forgot to mention in my first post is that using
SPF in the IN-ADDR.ARPA space would also provide SPF for domainless email
addresses of the form: user(_at_)[192(_dot_)168(_dot_)1(_dot_)1]
Yeah, actually, I hadn't thought of that, but it's true. Does SPF
currently handle mail from user(_at_)[ip(_dot_)nn(_dot_)nn(_dot_)nn] right now? would it be easy
to make it look in in-addr.arpa for the spf data? Does anyone ever send
mail from @[ip] anymore? Do we want to spend the energy to make SPF work
for MAIL FROM: <user(_at_)[192(_dot_)168(_dot_)1(_dot_)1]>? Probably would be minimal work...
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>