ietf-mxcomp
[Top] [All Lists]

RE: How is SPF different from RMX?

2004-08-03 16:19:22



On Mon, 2 Aug 2004, Hallam-Baker, Phillip wrote:


I have asked repeatedly for a specific fault in Sender-ID. The only response
that has been given is a repeat of the vague claim that the protocol is
flawed and cannot work.

Wrong and misleading as well. I have given you a large number of specific 
faults: (I'll summarize)

        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.*

[* I didn't use this name before. This is the in-addr problem I referred
to earlier. It is unlikely that entire net will comply, just like attempts
at using in-addr for antispam. Too many sites worldwide don't have it.
Unless everyone does it, it isn't any good for anyone. And like in-addr,
having it doesn't mean it isn't spam, anyway.]

I think there might be more. But #1 is the show-stopper. You haven't
solved any problems involving email abuse.  Commercial emailers aren't
aren't forging emails.

Perhaps if you'd actually read my emails it would help.

The fact that other people have proposed broken solutions to the spam
problem and have failed is irrelevant. None of the specific reasons for
failure appear to be relevant in the context of Sender-ID.

The very long list of previous failed proposals is relevant because we are 
no longer interested in "just trying something" that ___might___ possibly 
stop spam.


The requirements that Sender-ID seeks to meet are very precise. It provides
a means by which legitimate users of a domain name may authenticate
themselves to recipients in a limited set of circumstances. It is understood
that failure to authenticate cannot be considered proof that the sender is
false.

It doesn't meet this goal. Senders can still forge email from other users 
at a domain.

Other authentication mechanisms to meet an extended set of circumstances are
pending completion of this work. 

No "authentication mechanisms" can stop viruses from using stolen 
credentials. Strong, public key per-user authentication systems have been 
proposed and dismissed as failing to solve the problem.  Lesser 
authentication mechanisms won't solve the problem any better.