Karl Prince [spf(_dot_)pobox(_at_)princeweb(_dot_)com] wrote:
On Fri, 7 Jan 2005 09:12:41 -0500, Scott Kitterman wrote:
[...] When we tell people [to] put the ? in front of shared MTAs that
don't prevent cross-customer forgery we explain why and tell them that
they ought to talk to their provider about it. Eventually, this is
going to be a competitive discriminator. That's when it gets done.
I have given this issue much thought ever since the early days
of SPF, and I have considered to be an issue that needs to be
resolved if SPF is to become truely universal.
To expect a shared MTA owner to manually check the authority of
each of it's users to relay email from a domain (or address)
that is different to the one provided with the account, is
going to be onerous. Also what about removal of authority at a later
date.
I have the start of a possible solution in mind, but a full tech spec:
If within the SPF record (via include) extra records were
provided using expansion features, I think it would be possible
for MTA owners to automatically verify the right of it's users
to send emails for non local domains.
The record could be an expansion of the login account name for
the MTA, known to both the MTA owner and the user, or another
agreed unique identifier, we are assuming AUTH here of course
Alternatively a fixed IP address could be used for a non AUTH scenario.
This extra SPF record is in the control of the domain owner,
and therefore the authority is given (or removed) by the domain owner.
[...]
It could be combined with another suggestion I've heard (from
Jim Hill and another I afraid I can't remember), which is for
relaying MTA's to SPF check against themselves before delivery
is attempted, even better if it was done pre data with the originator.
The classic application of SPF is inbound checking, which is done to
protect oneself (or one's users) from forgers. What you describe
basically is so-called outbound SPF checking, which is done to protect 3rd
party recipients from forgers.
In the end, all anti-forgery technologies are about protecting the
recipients. But I am making the distinction because it makes clear that
outbound SPF checking needs to be advertised differently from classic
inbound checking. Doing inbound checking is in your own best interest,
which makes it easy to sell. _You_ doing outbound checking only benefits
others, but of course you can benefit from _others_ doing outbound
checking.
Obviously this will require a change in MTA software, and the
domain will need a half decent DNS provision.
Inbound SPF checking requires changes in the same category as outbound
checking does, so that should not be a fundamental problem now that
inbound checking is becoming more widely implemented.
A problem with the current SPF specification is that it centers too much
around inbound checking. Perhaps it would be better if the spec first
defined what an SPF record means ("what IP addresses are allowed to send
from a given domain") and then showed what can (and should) be done with
this information. That is, inbound as well as outbound checking.