"Dean Anderson" enumerated:
On Thu, 2 Dec 2004, David Woodhouse wrote:
On Fri, 2004-11-26 at 09:16 +0000, Chris Haynes wrote:
Let me focus on the heart of the debate, and I'm doing my best to be fair
to
both sides here, and to use neutral language.
I think this is very useful; thanks. But I think you've slightly
misrepresented the 'conservative' position.
Still in the spirit of 'neutral language' , let me use the terms
'conservative'
and 'progressive' for the two positions I am aware of.
The conservatives look at the above example and say
"SPF is breaking the mail system. Forwarding has worked perfectly well in
the
past; it is SPF which is changing; it is SPF which is wrong. SPF should
not be
deployed".
That's not quite how I'd phrase it. I'd say it was more like this:
"SPF is breaking the mail system for no good reason. Forwarding has
worked perfectly well in the past; it is SPF which is changing; it is
SPF which is wrong. SPF should not be deployed because there are better
ways of achieving the same thing, without the need for such changes."
I think there was more to it than this:
1) Abuser can forge addresses at domain
2) Abuser can use stolen credential
3) DNS cache problems (more records per domain, same cache size)
4) DNS load (more records per domain)
5) Ongoing Maintenance issues
6) Migration issues
7) IP Renumbering issues
8) Lost non-spam emails
9) Lack of universal compliance.*
10) Not a basis for trust/reduced filtering
11) Makes forgery blowback problem _much_ worse
12) Patent issues
13) spam-profiteering / charges for SPF services
I've been trying to act as a neutral observer, collating lists of strengths and
weaknesses of all the offerings in the anti-spam, anti-forgery space in as
neutral and fair a way as I can.
Once again, in the spirit of attempting to be 'fair' to all, can I just please
ask for clarification of the above list of concerns.
When this thread started we were referring to the problems related to forwarding
which are inherent in (the original) SPF(-Classic).
For the benenfit of other readers, may I just remind people that there have been
three proposals in the "SPF" space, but only one was formally submitted to
MARID: the Sender-ID one containing an amalgum of SPF and Sender-ID/PRA.
The above list looks to me like a list of the concerns with that combined
effort - and I'm concerned that problems with Sender_ID may here be unreasonably
associated with SPF-Classic.
The concerns I have previously seen associated with SPF-Classic, and are also
present in Sender-ID are:
3) DNS cache problems (more records per domain, same cache size)
4) DNS load (more records per domain)
7) IP Renumbering issues
8) Lost non-spam emails
10) Not a basis for trust/reduced filtering
It is my understanding that only the above concerns should be associated with
"SPF".
The ones which appear to me to have been added by PRA (derived from Caller-ID)
in Sender-ID are:
1) Abuser can forge addresses at domain
11) Makes forgery blowback problem _much_ worse
12) Patent issues
13) spam-profiteering / charges for SPF services
And ones which probably represent universal engineering concerns:
2) Abuser can use stolen credential
5) Ongoing Maintenance issues
6) Migration issues
9) Lack of universal compliance.
although of course the way and degree to which these concerns mainifest depends
on the exact scheme in question.
Chris Haynes