Thanks to everyone for giving this some serious thought. Its clear to me I
need to clarify what I (and I suspect millions like me do). I think some of
you understand my position but others aren't quite sure why I think this
matters or how it relates to SPF.
I have a domain. Let's call it example.com, and I have an ISP (call them
dirtcheapbroadband.net). Dirtcheapbroadband give me a POP mailbox as part of
the service at myname(_at_)dirtcheapbroadband(_dot_)net(_dot_) However, I want
to send and
receive mail as anything(_at_)example(_dot_)com(_dot_) So I set up an account
with
domainparkingishere.net to forward all mail addressed to
*(_at_)example(_dot_)com to
myname(_at_)dirtcheapbroadband(_dot_)net(_dot_) I send my outgoing mail through
dirtcheapbroadband.net's server, which doesn't seem to mind my From identity
not being a dirtcheapbroadband.net one.
This arrangement is affordable (if you shop around you can get the forwarding
free) and works well. I suspect millions use it. However, it's only available
because it's easy for the two companies to set up and needs little
intervention to make it work. Dirtcheapbroadband won't let me anywhere near
their root account to change configuration files. That would be very
insecure. And they're certainly not going to set up a special configuration
on my behalf.
From the viewpoint of the rest of the world, once the mail has been delivered
to the server pointed to by example.com's MX record, it has reached its
destination, and the forwarding is an internal private matter. However, it
isn't really. The sending from domainparkingishere.net to
dirtcheapbroadband.net takes place across the public Internet and so far as
those two companies are concerned is definitely an external exchange.
Furthermore, I have no power to affect their policies w.r.t. whitelistng, SRS
or SPF. If dirtcheapbroadband decides to reject all mail which fails an SPF
check and domainparkingishere decide to have nothing to do with SRS, I could
find myself:
1, Unable to use SPF to protect my domain without blocking my own outgoing
mail.
2. Unable to receive incoming mail from any domain which has an SPF record.
Yes, I could overcome these problems by spending more money, but that creates
a financial disincentive to adopting SPF or encouraging others to do so. SPF
will only be effective of it gains widespread acceptance.
So, to the specific questions:
Q. Why do I want to use the public DNS to store the records?
A. Because the forwarding is taking place on the public network and that is
where the SPF records, which potentially create the problem, are stored. It
is where domain owners have access, irrespective of what kind of forwarding
service they use, and it thus guarantees domain owners a chance to use it. It
is independent of any particular ISP's security and access policies.
Q. Why do I want to incorporate RPF into the SPF standard?
A. Because RPF's sole purpose is to modify SPF behaviour. It has no meaning
apart from SPF, and incorporating it into the standard would encourage the
adoption of both together. RPF will not work in a meaningful way if it is not
adopted at the same time and on the same MTA/MRU as SPF. Separating them
therefore makes little sense.
Q. But doesn't SRS already achieve the desired result?
A. If both forwarder and MRU adopt it simultaneously that would, and then
there would be no need to use it. However, if the two machines are
administratively independent, there may be no way to ensure that happens.
RPF is intended to allow domain owners to workaround this problem.
Q. But why provide two mechanisms?
A. If they're compatible, why not? It makes for a more robust system from the
end user's viewpoint if there are more tools available.
Q. RPF needs the DATA to complete before if can perform its tests. Classic SPF
operates before the DATA is requested. Can't we use RCPT TO: instead?
A. In the example above, RCPT TO: would
contain "myname(_at_)dirtcheapbroadband(_dot_)net",
but to look up the RPF record we would need "example.com". This is in the DATA
part of the transaction, in a To: Cc: or Received: header. So we would need
to complete DATA before proceeding with the checks. This is clearly less
elegant, and if the message is to be rejected results in more traffic.
However, I care less about elegance than the overall effect. At the end of
the day, we need something that works for E-mail users and domain owners. The
world is messy. I'd rather have something messy that works than something
tidy that doesn't. A standard that is so lean it doesn't cover all
possiblities is unlikley to be practical enough to be useful.
I hope that clarifies why I wish to make this proposal.
K.J. Petrie
-------
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