On Sun, Nov 12, 2006 at 05:43:12PM +0000, K.J. Petrie (Instabook) wrote:
Summary:
Using "To:", "Cc:" and so on creates a loophole.
Using DNS is very inefficient.
Creating another protocol besides SRS may actually harm both.
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.
Clear, and frequently discussed.
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.
As I said before: you don't need access to the root account. What is
needed is some kind of input, where you are able to tell Dirtcheapbroadband
what your forwarders are. And of course Dirtcheapbroadband needs to use
this list and not perform SPF verification on such mail.
"Some kind of input" can be anything. For instance, a web interface, with
some cgi script managing the list. No root access required.
"what your forwarders are" could be done using email addresses, or host
addresses.
Last but not least: what's stopping "spammer(_at_)fraud(_dot_)example" from
publishing
an RPF record, announcing his "forwarder" (in reality his own spamhost).
A message comes in at dirtcheapbroadband, it looks at "To:", notices
"To: spammer(_at_)fraud(_dot_)example", fetches the RPF record from the
spammer's
DNS server, and dirtcheapbroadband does not perform SPF verification.
You don't want the spam, decide to bounce it (which is VERY bad, because
of your forwarder construction) et voila, another bounce is delivered to
a victim.
You just created a loophole. Anything in the body (including "To" etc)
cannot be trusted.
The only sensible thing to do is to generate a list of hosts and place
it on the email server at dirtcheapbroadband. No connection to user names
originally receiving the message, but to user names currently receiving
it (thus: yourname(_at_)dirtcheapbroadband).
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.
Right. And SPF people consider it fraud when domainparkingishere uses
other people's property (in MAIL FROM). And you, as a domainparkingishere
user, are encouraging them to continue doing so.
Either they use their name to send your mail ("forwarding") or you set
the connection up as a relay ("relaying") without authentication.
Furthermore, I have no power to affect their policies w.r.t. whitelistng, SRS
or SPF.
Yes you have. It's called "money". Even providers that deliver their
services to you for free, make money. Providers that loose customers
loose money. Some providers adapt and implement SPF, SRS, SES, domainKeys,
and what more. Others cease to exist.
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.
Not necessarily true, consider "?all".
2. Unable to receive incoming mail from any domain which has an SPF record.
provided that it ends in "-all": mostly true, and a bigger problem (for you)
than the first one. You can control if you have an SPF record or not, but
you cannot control if I have.
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.
That's an opinion, and furthermore you think the problem you mention, has a
significant influence on the adoption rate. That too is an opinion.
And even if it would be true, I don't think you can conclude that it
isn't worth it. Others may disagree.
The ultimate goal of SPF is to make itself redundant. It will never happen,
but a world without forgers, wouldn't that be nice? Of course, in a world
without forgers, nobody would feel the need to publish SPF. So the ultimate
goal of SPF results in less adoption of SPF.
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.
"Where SPF is stored": yes. But the users of this record are a completely
different set than the users of your RPF record. Users of the RPF record
know who is going to use their record, it will be their ISPs. But when
I publish an SPF record, I do not know who is going to fetch it. It most
certainly is not limited to the people I send mail to.
Who are these users:
1: RPF records: the domain owner and his ISP
2: SPF records: anyone on the internet, except for those mentioned at (1).
For SPF, DNS is a good solution because virtually everybody needs to be
able to access it. For RPF, there are much faster and cheaper solutions
possible, and IMHO your arguments do not outweigh these benefits.
N.B. SPF does not "potentially create the problem", SPF makes the problem
visible. The problem is created by the forwarder.
"Where domain owners...policies": yes, as is true for any other, standarized,
protocol. RPF or another protocol: the ISP needs to make changes. Let's
assume for a moment that they will implement those changes, they are probably
better off when accessing internal databases or even text files.
Then again, if you say dirtcheapbroadband is not going to setup a special
configuration, why do you think they will implement RPF ?
You think only you would want this "special configuration" but everybody
would use RPF ? It seems to me that it would be welcomed by the same
set of users at dirtcheapbroadband...
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.
This seems to be worth exploring. Whatever protocol/technique is the
result of this excercise, it could be argued that it is mentioned in
a future SPF specification.
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.
I'm afraid you lost me here. What's an MRU, and why would it need to
implement SRS ?
As far as SPF is concerned, only the forwarder needs to implement SRS.
It is the forwarder that is the forger, unless it implements SRS.
When domainparkingishere implements SRS, dirtcheapbroadband will
accept the messages sent by domainparkingishere (provided everything
else is OK, of course).
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.
Most systems will end up supporting both. There will always be a (hopefully
small) number of systems that will support only one mechanism, and a similar
amount only supporting the other mechanism.
Consider: one host assuming the forwarder does SRS; and a forwarder assuming
the next receiver will do RPF. I could argue that implementing another
mechanism actually increases the chance that you end up with an unworkable
situation. As soon as RPF exists, the forwarder will say "Let the next hop
solve the problem, click here for RPF documentation"
Apart from this: no argument.
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",
True, I got confused by all the text.
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.
So, instead of using "RCPT TO", "To:", "Cc:", and so on, consider using
"192.0.2.1", "mail.example.com" and so on.
In other words:
Don't skip SPF based on email addresses, but based on host addresses.
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.
Covering 100% of all cases is a delusion.
As indicated above, the overal effect of RPF as you outlined it, is a
loophole in SPF. To create this loophole, you publish your (private)
forwarder information in public DNS.
Alex
-------
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