spf-discuss
[Top] [All Lists]

Re: [spf-discuss] RPF explanation and examples

2006-11-15 11:50:52
Sorry I haven't replied to this earlier. I was too busy answering the 
questions on the thread I'd started to notice Stuart had started another one. 
I think this might have caused some confusion, especially as when I got 
Stuart's original "I think you might be on the right lines" comment, I had 
already abandoned the RPF proposal because of the problems others had 
demonstrated. Also, if I read Stuart's proposal correctly, I think he has 
misinterpreted mine, which doesn't help either. So I think I should comment 
on this in an effort to set things straight if I can.

On Monday 13 November 2006 18:59, Stuart D. Gathman wrote:
RPF (Receiver Policy Framework) is a proposal to use SPF like records to
communicate receiver policy from a domain owner to a 3rd party mail store
(imap or pop service).  It is directly useful when the envelope RCPT TO
given to the mail store is the domain with a Receiver Policy.  It is not
directly applicable for mail providers that use their own domain (e.g.
gmail.com).

Not quite. The envelope RCPT TO will always match the domain of the MUA, whose 
administrators have full control over its policies and don't need any 
external means of communicating them.
The idea is that the 3rd party mail store checks SPF on all
incoming mail - modified according to a "v=rpf1" record which is
checked first.  RPF records are evaluated just like SPF, using the
MAIL FROM domain for evaluation, not the RCPT TO domain used to fetch
the RPF record.
If the RCPT TO domain is used to fetch the record, the record would have to be 
set up by the MUA administrators, who already are in a position to configure 
their own machine. The domain which needs its own special policies is the one 
in the DATA To: (or  Cc:, or Envelope-To: [not to be confused with Envelope 
RCPT TO], or perhaps a Received:...for...  - this is where it gets 
complicated and insecure, and why others have persuaded me it's not the way 
to go), which would be used to fetch the record. The record would be evaluate 
against the local machine's IP address (Yes, the one actually running the 
check). It wants to know "am I one of the machines that should not SPF-check 
mail addressed to the recipient domain?" That's the small user's domain. The 
non-default policies are to be applied to incoming mail, so it's where the 
mail's going that matters at this stage, not where it came from MAIL FROM 
would never be used for RPF, that's for SPF, later on.
An RPF pass means to accept the message and SKIP SPF 
checking. RPF neutral means to check SPF normally.  RPF fail means to
REJECT the message without checking SPF.  Softfail means to check SPF, but
generate some kind of warning feedback to the domain owner suitable for
debugging should the SPF result be FAIL or SOFTFAIL.
No, anything other than a PASS was to result in SPF checking as normal.

Although RPF records represent internal policy, using DNS records is much
easier to program for the 3rd party mail store than, for example, a web app
to support similar configuration options.  The key point is that the
3rd party mail store and their customers are separate administrative
entities.
Almost. It was to be a standard way for the small domain owner to program the 
policies, which did not rely on the 3rd-party mail store making any specific 
provision. The idea was that if RPF were in the standard, it would 
automatically be incorporated into all future SPF software, so the facility 
would automatically be available,

For these examples, "example.com" is a small domain using a 3rd party
mail store.

Example 1: non-SRS forwarders targetting example.com

A forwarder forwards example(_at_)forwarder(_dot_)com to 
user(_at_)example(_dot_)com,
No, the mail is addressed to user(_at_)example(_dot_)com, but it's forwarded to 
username(_at_)3rd-partymailstore(_dot_)com [6.7.8.9]
but 
does not rewrite the sender (forging the sender domain).  The forwarder
sends outgoing mail from 1.2.3.4.

To tell the mail store to accept the forwarded mail without SPF checks:

example.com   TXT "v=rpf1 ip4:1.2.3.4"
No, it would be
example.com     TXT "v=rpf1 ip4:6.7.8.9"

Example 2: use DNS blacklist

Example.com wants the mail store to use a DNS IP blacklist:

example.com   TXT "v=rpf1 -exists:%{ir}.someblacklist.com"
exists is not a valid RPF field. DNS IP blacklists should be specified in the 
SPF record for example.com.

Example 3: local domain blacklist

Example.com maintains a list of domains they wish to reject all mail
from in DNS.

example.com   TXT "v=rpf1 -exists:%{d}.blacklist.example.com"

ditto
Example 4: disable SPF

Example.com does not wish to do any SPF checking for whatever reason.

example.com   TXT "v=rpf1 +all"
all is not a valid RPF field. -all is always implied. Otherwise, it would be 
possible to specify that no server was ever to do SPF checking on mail for 
the domain, but it would be a security disaster, effectively rendering SPF 
useless. Only ip4, ip6, and possibly a and mx would be valid fields. I didn't 
specify which fields would be in the subset, because I thought that would be 
open to debate, but I did specifically exclude all, because it would be so 
destructive.

Example 5: forwarder debugging

Example.com wants to whitelist a known forwarder, and be notified of any
forwarders they may have missed.

example.com   TXT "v=rpf1 ip4:1.2.3.4 ~all"
ditto

Example 6: 3rd party spam filter

Example.com needs to tell the mail store that incoming mail first
goes through a 3rd party spam filter (the MX records for example.com
point to the spam filter, not to the mail store).  Mail from any other
source should be rejected.

example.com   TXT "v=rpf1 A:out.spamsoap.com -all"
No, rejecting is for SPF to handle. RPF was about accepting mail that did not 
need to be SPF checked in circumstances where SPF would make no sense. 
However, it had numerous problems, which caused me to abandon the idea once 
these were explained to me. The plethora of headers in the DATA which would 
have to be checked to find the desired domain was one. How would one identify 
the correct header and domain? In pactice every domain mentioned in an 
appropriately-looking header would have to be checked, A forger/spammer could 
check the RPF record to find out where the mail would end up and then Cc: to 
a domain with an RPF record designed to turn SPF off. (Not sure how realistic 
that was, given that a different domain and RPF record would be needed for 
every MUA set-up to be spammed, but it is technically possible.) The other 
major problem was that RPF had to happen before SPF, but needed Data which 
would not normally be available until after mail was accepted following SPF, 
so SPF would need a major revision and would become much less efficient in 
bandwidth and processor overhead terms.

My concern is to prevent the small domain owners running into difficulties 
with, say, a forwarder who refuses to implement SRS and a MUA who insists on 
SPF-checking everything, and having great trouble trying to find an 
affordable alternative for one of these, perhaps only to fall victim to a 
change of policy shortly after making a move. Moving suppliers is also 
disruptive, and likely to lead to lost messages, and it would be better to 
avoid these problems if possible.

However, I am now convinced that, rather than a complex software fix, 
recommending that "large domain" owners make facilities available to their 
users to configure SPF behaviour on their own accounts would address the 
problem better. Again, if it is part of the standard, it should be normal for 
it to be adopted at the same time as SPF, which is all we need to happen.

Again, I apologise for not picking this up sooner, especially as Stuart's 
well-meaning attempt to put flesh on the bones was actually so misleading 
about my original intention. It was, perhaps, a difficult concept to get 
across in a single post, and I suppose the details were easily misread.

All the best to all,

KJP

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