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