spf-discuss
[Top] [All Lists]

Re: Extending SPF to IN-ADDR.ARPA space

2004-03-24 05:22:52

On Tue, 23 Mar 2004, Greg Connor wrote:

--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.

Actually it may well be made withing SPF framework, in fact based on what 
I saw its actually a lot better to do both IN.ADDR and mail-from domain
dns authentication togeher as they can compliment each other and fix some 
problems for each other. I talked about this exact thing (incluing using
SPF for an example) privately with Alan DeKok in the beginning of March in 
regards to some other ASRG items. Meant to put up webpage about it with 
exact proposal but still has not got around to it (but planning on doing 
it for ietf wg, I'm just short on time).

The main idea is to allow single record from either in-addr or domain 
spf record to override another more general on of the other type. That 
means for in-addr record, the domain spf record can specify one or more 
of specific ips (but only specific ones not as a range) that are allowed 
to use it (this is meant to combat when isp is slow to enter spf record 
for in-addr) and for other side a in-addr record for specific domain can 
be used to override regular domain spf record which is to be used for 
forwarders and for mailservers (which was always my main concern 
with RMX/LMAP and similar proposals).

Below are the extract of my email to Alan (here ">" are from Alan's email,
most of it I did not include as it was not related), please feel free to 
go through it but be warned that its rather rough and work-product. In 
addition there are number of issues with using in-addr txt records that 
need to be properly addressed and which I did not mention - like for example
RFC2317 classless delegation (which is actually a bad RFC in my view, they
should have done with with single NS per reverse rather then with CNAMEs).

On Wed, 3 Mar 2004, Alan DeKok wrote:
...

  The alleged "roaming user" is probably the single largest source of
spam out there, from what I'm seeing.  I say "alleged" because the
spam sources behave much like legitimate roaming users, but they're
not.  There are 10^7 MUAs sending spam, and only about 10^5 MTAs
receiving it.

Correct. Roaming must be taken under control. We started dealing with it
when open-proxies were baned, but number of these users then just moved to
sending emails directly from their MUA bypassing MTA proxying all 
together. We must finish what was started and get people to use AUTH and 
proxy through their proper MTA server when roaming.

  Addressing that imbalance is one of the goals of LMAP.  Solving that
imbalance will make the spam problem much more managabie.  If there's
a better system for this than LMAP, no one has proposed it.

LMAP will not solve it, it addresses different issue of forging of
envelope-from identity (not to say that its bad - I've been a victim of
joe-jobs 4 times now and not too happy about it). However as people are
willing to put so much support into LMAP, we might as well use this
for in-lddr zones to fight zombies. I think SPF with its fairly extensive
syntax can be adapted there quite well. I've read its draft today and see
the following possible way to do it:
 1. If SPF is used to authenticate by envelope-from and the record specifically
    includes ip address of the connection, there might not be necessary
    to check IN-ADDR.ARPA record.
      Positive: Allowing envelope-from spf to override IN-ADDR spf may allow
    for those users that setup their  mail servers on their dsl lines and
    where their isp are not very cooperative in helping them in properly
    adjusting in-addr record to indicate mail server resides on that dsl.
      Negative: Not checking it does leave with possibility that spammer would
    setup new domains, add SPF records to their domains and add list the
    proxies they use there; however it is  likely that considering number
    of proxies they usually use, this might not be practical.

 2. If there was no SPF record for envelope-from or if the record resulted
    in failure, the check on in-addr ir done. Note that almost all mailservers
    will already try to get PTR record for ip. This is done first and if the
    result is that it seems ISP does not have working reverse dns zone, then
    do not bother any futher. But if one of the reverse servers responded (even
    if result is negative for PTR), then first try to get 1.1.1.1.IN-ADDR.ARPA
    For "1.1.1.1.IN-ADDR.ARPA IN TXT "v=SPF1 -all" connection is denied.
    But if the in-addr record is specifically positive like
    "1.1.1.1.IN-ADDR.ARPA IN TXT "v=SPF1 +all", this will override domain SPF
    record. Additionally if "1.1.1.1.IN-ADDR.ARPA" did not have SPF-like TXT
    record then lookup "_spf.1.1.1.IN-ADDR-ARPA IN TXT" which will allow to
    support one record per /24 without necessity to enter record for every ip.
      Positive: This will make life of forwarding services easier as they
    do not have to immediatly change their software to do proper rewriting
    of envelope from and may take time to properly change their code.
    Additionally this will allow those airport webiterminals to exist.
    (I'm personally most worried about how LMAP or variant may effect
     forwaring this is my primary concern in opposing it)
      Negative: Spammers may choose to specifically add SPF records for
    the ip blocks they fully control and then forge the sender (however
    this would probably be against thn law and since we know its their
    block, its easier to block this and a lot easier to track the spammer
    and prosecute him).

What seems to be missing:
 1. Ability to add actual domain records into in-addr SPF (i.e. to specify
 which domains are allowed to with envelope-from in given ip address)
 - possibly can use 'a' and 'exists' and specify that for in-addr SPF no
   match by ip is done and instead direct match by name of sender-domain
 2. Ability to add requirement of certain authentication type, i.e. like
 "1.1.1.1.IN-ADDR.ARPA IN TXT "v=SPF1 require=
 (SMTPEXT AUTH KERBEROS_V4 && SMTPEXT STARTTLS)"
 The same would also be quite usefull when authenticating by EHLO name.

---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net