On Wed, 11 Aug 2004, John Glube wrote:
Dean -
The main issue John is disputing above seems to be whether
junk mail mostly comes from virus infected machines (as I
suspect) or whether it comes from commercial emailers
breaking the law (as I think John thinks). This is
basically a quibble.
Actually, the underlying issue from my perspective was your
reliance on a report which you claim was published by the
Federal Trade Commission containing a set of statistics
which you claim supports your conclusion as to UBE sources.
My problem? I can not find this report to verify your
conclusions and you have not provided a working link to
the Commission report you claim supports your position.
Ahh. I looked for my reference; my bad; it was Email Labs, not FTC:
http://www.emaillabs.com/article_CANSPAMAudit.html
The Email Labs study was in January 2004. Searching just now, I didn't
find anything by the FTC on CAN-SPAM compliance, which I thought strange.
The Act requires the FTC to report on its effectiveness...
Let me explain why I do not propose to go further with the
debate.
The time and place for this debate was when the IETF
decided to form this working group.
I was not invited to discuss this when the IETF formed the working group.
Further, the purpose of a working group is to research the questions put
to it, and the answers to questions such as feasibility can't be answered
ordinarilly at the outset. Though, in this case, information theory does
indicate that it is impossible to create a protocol that can't be abused,
so the notion of MARID is a priori infeasible, in the same way that
perpetual motion machines are infeasible. Physics departments are thus
able to avoid researching schemes that amount to perpetual motion
machines. Similarly, we _ought_ to be able to avoid researching schemes
that require violations of information theory.
To go further would be to wander far from the purpose of
this list given the working group's charter.
Feasibility, impact on other protocols, impact on business activities are
always relevant issues to any working group's task.
Finally, you go on to write:
The authentication and accountability aspects of SPF are
illusory and are not achievable in the SPF proposal as it
stands, nor can DNS be used to achieve these goals. This
subject has been discussed at length on the DNSOP and
DNSEXT lists, and it is generally agreed that DNS cannot be
the basis of authentication.
Dean, this is a most serious charge. However, it is made
without specific proof or example.
Without specific proof? That is a pretty credulous claim on the subject on
DNS authentication. It is very well known and generally agreed by the
experts in these DNS working groups that DNS is itself insecure and can't
form the basis of an authentication mechanism. There are well known DNS
security exploits such as the BSD R-command exploits that improperly
relied on DNS for authentication. Further, there is a specific project
called DNSSEC to address these problems. It has unsuccessfully worked on
the problem for many years (about 10 years I think).
Indeed, the DNS authentication issue is so obvious that I did not list it
in my list of 9 serious problems. I was genuinely surprised by your
mention of it. There is clearly a serious disconnect if people in this
working group think that DNS can be used for authentication and
accountability.
At the behest of myself and others, the WG chairs are
soliciting operational and security reviews of the marid
draft proposals (with a focus on the PRA algorithm) from
the graybeards, based on the various specific concerns
raised on this list and during the formal meetings of the
MARID WG.
I don't know who, specifically, you are referring to by "graybeards", but
it clearly should be reviewed by responsible persons who are impartial to
its approval/disapproval.
Also, the WG chairs have arranged for tests to be conducted
of Sender-ID and CSV (not Sender-ID versus CSV) by a large
American ISP with the results to be reported back to this
WG.
I think this is rather insufficient, in just the same way as the diebold
voting machine tests were insufficient. Diebold ran its own tests saying
the voting machines counted correctly---well, __of course__ they count
correctly when no one is trying to hack them. We __expect__ them to work
properly under __ideal__ conditions. It is real world conditions that we
are interested in testing, and where we expect them to fail.
"A large American ISP" might have an ulterior interest in SPF, because of
the previously described harms to email outsourcing. Even if SPF has no
effect on spam, but harms outsourcing, it might still be in the interest
of "a large American ISP" to promote SPF. So there is a conflict of
interest that is unacceptable.
A proper test requires a hostile environment, such as likely to be
encountered in the real world. A proper test also needs to be carried out
by someone without a conflict of interest in the outcome of the test.
I write Sender-ID, because the concepts behind SPF and
Caller-ID have been merged and a new design was brought
forward in mid-July, to be titled Sender-ID.
Ok, I'll have to review that. Might I propose S-ID as a suitable
abbreviation for Sender-ID?
--Dean