On Wed, 15 Nov 2006, K.J. Petrie wrote:
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
A MUA doesn't *have* a domain. It connects to mail stores (imap/pop) and MTAs.
administrators have full control over its policies and don't need any
external means of communicating them.
The MUA "administrator" is YOU. The exception to this is a webmail MUA.
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
The MUA is *not* related to the the RCPT TO domain. The RCPT TO causes
the mail to be delivered to a mail storage system. Your MUA accesses/copies
the mail from the mail storage system.
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.
No, there are other policies besides the one you are thinking of
that need all the results.
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,
It is only appropriate with 3rd party mail storage providers.
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]
That's your example, not mine. I suggest you look at the examples and
see how you could use the proposal. To use your names, The RPF
record would be
3rd-partymailstore.com TXT "v=rpf1 ip4:6.7.8.9"
Assuming that the forwarder used IP 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"
I'm sorry, but that won't work. I realize that was your original proposal,
and others on this list have tried to explain to you why it won't work
with varying degrees of kindness. What I have done is taken your idea
and turned it into something a little different that will work. The catch is
that you must use a 3rd party mail store that will let you use your own domain.
I.e. you cannot use gmail.com to do what you want to do.
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
Please see if you can use the modified scheme I suggested. There are
plenty of 3rd party mail stores that will use whatever domain you tell them.
None of them are free, but many are quite cheap.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
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