Subject: Re: clarification on consensus call for compromise

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 21:18:42 +0800

Some compelling reasons for a single DNS record which does not specify algorithm scope:

1. It allows all algorithms to play equally.

2. If we do not reach concensus, Microsoft might just go create their own non-interoperable (with other algorithms technically or legally) standard for DNS records.

3. The hardest thing to get done, undone (if we choose wrong or act too late), and maintain, are the publishing of the DNS records on wide scale.  We better not get the DNS record wrong, be too late to be relevant, proliferate fragmentation, or exclude parties which can promote it to success.

4. The anti-forgery algorithms we are considering now may ultimately have the least relevance in the end game of anti-spam.  For example, I expect the PASS case to be much more important to a viable anti-spam algorithm than the other result cases.  Thus in the anti-spam algorithms I envision, the more algorithms that can generate a PASS case, the better the final performance.

5. If we design a DNS record that can interopt with known algorithm proposals, then it will have a better chance of interopting with all algorithms, than if we design separate records that go off in proprietary directions.

6. Simplicity breeds success.  Other engineers know this as "KISS" (Keep It Simple Stupid).  Also known as 80/20 rule.

7. We can not force an algorithm in reality (because we haven't provided a 100% solution with proposed algorithms), thus #5 is needed.

8. Waiting until we have a "end all" algorithm means we may be too late.  There are important cases that can be solved today with the current proposed algorithms.

I could probably think of more.  Can anyone think of compelling reasons to convince ourselves we can force an algorithm on the DNS record (even though IMO we can not in reality)?

-Shelby Moore

---

From: wayne <[email-masked]>
Date: Fri, 10 Sep 2004 08:44:56 -0500

In <4.1.20040910205740.03a2e980(null)> AccuSpam <[email-masked]> writes:

> [snip]

This is all well covered stuff that was decided months ago.
I don't think it is a productive use of this working group's time to
re-raise issues that have already been decided just because someone
new has joined the working group.

Reading the complete archive will help you understand why the
decisions were made.  You may not agree with those decisions, but so
be it.

-wayne

---

From: David Woodhouse <[email-masked]>
Date: Fri, 10 Sep 2004 15:21:13 +0100

On Fri, 2004-09-10 at 21:18 +0800, AccuSpam wrote:
> I could probably think of more.  Can anyone think of compelling
> reasons to convince ourselves we can force an algorithm on the DNS
> record (even though IMO we can not in reality)?

I can think of reasons why we should ensure that there is a clear
distinction between those addresses which are considered to be an
acceptable RFC2821 reverse-path, and those addresses which are
considered to be acceptable in RFC2822 headers.

220-ZenIV.linux.org.uk ESMTP Exim 4.41 Fri, 10 Sep 2004 15:16:59 +0100
220 Be gentle with me
helo me
250 ZenIV.linux.org.uk Hello me [2002:c35c:f9fc::1]
mail from:<[email-masked]>
250 OK
rcpt to:<[email-masked]>
550-Verification failed for <[email-masked]>
550-Called:   2002:c1ed:8229:10:2c0:f0ff:fe31:e18
550-Sent:     RCPT TO:<[email-masked]>
550-Response: 550-This address never sends messages directly, and should not accept bounces.
550-550-Please see http://www.infradead.org/rpr.html or contact
550-550 [email-masked] for further information.
550 Sender verify failed

220-canuck.infradead.org ESMTP Exim 4.42 Fri, 10 Sep 2004 10:15:52 -0400
220 Be gentle with me
helo me
250 canuck.infradead.org Hello me [2002:c35c:fd02::1]
mail from:<[email-masked]>
250 OK
rcpt to:<[email-masked]>
250 Accepted
rset
250 Reset OK
mail from:<>
250 OK
rcpt to:<[email-masked]>
550-This address never sends messages directly, and should not accept bounces.
550-Please see http://www.infradead.org/rpr.html or contact
550 [email-masked] for further information.

-- 
dwmw2