Subject: RE: How is SPF different from RMX?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Aug 2004 16:41:08 -0700

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.

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

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

	Phill

---

From: Dean Anderson <[email-masked]>
Date: Tue, 3 Aug 2004 19:19:23 -0400 (EDT)

> that has been given is a repeat of the vague claim that the protocol is

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.

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

> that failure to authenticate cannot be considered proof that the sender is

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

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 4 Aug 2004 09:46:34 +0100

> that has been given is a repeat of the vague claim that the protocol is

http://www.imc.org/ietf-mxcomp/mail-archive/msg02817.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg02818.html

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.