> > This is
> > also by no means the first time that something like this has been mooted,
> > and every time, it's rejected, mainly because of the enormous amount of
work
> > it requires (both to set up and to maintain).
>
> It took me 10 minutes to publish spf info for about 200 domains. I also
> do not understand your objections to how spf scales. As I know you could
> spf-allow a whole C class with a single line of configuration.
>
I read the SPF proposal, and the first question I had for implementation was,
how to handle classless IP blocks (e.g. /29), other than the painful method of
an entry for each IP. I imagine there is some clever way, similar to how
delegation of such blocks is *supposed* to be done... (*small strangled noises
suppressing off-topic rant*).
Some things I liked about the proposal:
(1) It's optional.
(2) One can publish in advance without
screwing up anything else.
(3) The onus is entirely on admins for
implementation, not users.
Some things I did not like about it:
(1) It's optional. ;)
(2) It is a bit of work to implement.
(3) It's essentially useless until it becomes
globally implemented.
(4) It stirs up debate about reverse DNS names
matching HELO/EHLO again.
(*runs and hides*)
(Just kidding, Greg!) ;)
But seriously, the real problem is convincing admins to do the extra work,
long before any actual value is added as a result. Sure, I could publish SPF
data fairly easily; but, I can't *use* SPF data until almost *everyone* does.
It's a bit like asking people to contribute time or money to a "good cause."
You might get a fair number of participants, but you won't get everyone. You
probably won't even get a majority.
I am not objecting to the underlying concept (attempting to validate that
email is coming from a machine it is supposed to be coming from). (Although
SPF is not a particularly secure method, as the paper itself admits). I'm
just saying there are realistic obstacles.
Jim Roberts
Punster Productions, Inc.
