Subject: RE: Forging (was Re: Differences between CSV and Sender-ID )

From: "Gordon Fecyk" <[email-masked]>
Date: Wed, 7 Jul 2004 09:36:39 -0500

> As I say, the Internet community is going to be a bit disappointed
> that we spent this much time and effort and did nothing to reduce
> spam.

I've said in counter to this that the Internet Community consists of a bunch
of lazy [censored] for not acting to do something about their own spam, and a
bunch of clueless [deleted] for actually responding to spam.

None of us here have the solution to a clueless and lazy community.

What we can do here is deliver incentive to complain, by demonstrating that
who claims to have sent the spam actually sent it (accountability).  IF the
community decides to act on valid information, they will, and that will be
the beginning of the end of spam.  IF not, if the commmunity chooses to be
the lazy [deleted] that they are today, then it won't.

If MARID gets used by an elite few, that's OK by me.  I will probably host a
second domain that will require senders have MARID records or their mail will
be refused.  Eventually the elite minority will grow.

-- 
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>

---

From: Greg Connor <[email-masked]>
Date: Wed, 07 Jul 2004 08:12:08 -0700

--Gordon Fecyk <[email-masked]> wrote:

> I've said in counter to this that the Internet Community consists of a
> bunch of lazy [censored] for not acting to do something about their own
> spam, and a bunch of clueless [deleted] for actually responding to spam.
>
> What we can do here is deliver incentive to complain, by demonstrating
> that who claims to have sent the spam actually sent it (accountability).
> IF the community decides to act on valid information, they will, and that
> will be the beginning of the end of spam.  IF not, if the commmunity
> chooses to be the lazy [deleted] that they are today, then it won't.
>
> If MARID gets used by an elite few, that's OK by me.  I will probably
> host a second domain that will require senders have MARID records or
> their mail will be refused.  Eventually the elite minority will grow.

Agreed.  MARID-brand LMAP probably won't noticeably reduce spam, or even 
forgery, at first, but if it creates a dis-incentive to forging MY domain 
name, I will definitely use it.  At first the easiest thing for spammers to 
do will be to forge other domains that don't have LMAP info.  Eventually, 
mail from domains with no LMAP info will start to get downgraded, but that 
will take a long time.

The view that "this won't reduce spam so we shouldn't do it" is a pretty 
short-sighted one.  Sure, everyone here would like to reduce spam, but we 
can serve other goals too.  I think we went over this in detail during the 
"which identity to check" phase, so I won't rehash everything discussed 
before, but it seemed clear that both 2821 and 2822 identities should be 
protected, for different but equally valid reasons.

--
Greg Connor <[email-masked]>

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 07 Jul 2004 13:58:33 -0400

Greg Connor <[email-masked]> wrote:
> name, I will definitely use it.

  Summarized in a carefully phrased sentence:

	MARID creates a permanent way for domains to permanently give
	dis-incentives for the transient problem of forgery.

  Domain name forgery is a transient problem, as incidents can occur
sporadically, and the incidents are caused by different people at
different times.  The only way to stop this series of problems is with
a solution which will permanently allow people to detect and prevent
these attacks.  MARID is one approach which creates a long-lived
solution for a transient problem.

  Similarly, bandages solve a transient problem, but the *existence*
of bandages is a permanent phenomenom.  No one would claim that
bandages "do nothing to reduce injuries" because the problem solved by
bandages is transient in nature.

  To put it yet another way, MARID can be thought of as a set of
distributed DNSBL's.  Each domain operates its own DNSBL (or
whitelist), which use a well-known format.  Peers on the net can look
up information for a domain via DNS, and choose to apply the DNSBL
information (or not).

  None of this is new to the net.  DNS already tells peers where to
find information (e.g. MX's), and DNSBL's are already used by clients
to obtain policies which they apply to data flows.  MARID adds very
little to this process, other than a standard for record formats, and
when those record formats are used.  Since MX's work, and DNSBL's
work, I don't see why there's such FUD surrounding MARID.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 07 Jul 2004 11:45:06 -0700

> solution for a transient problem.

Could you define what you view to be forgery?

> up information for a domain via DNS, and choose to apply the DNSBL

Listing services are often more robust than a typical DNS server. The
nature of a listing service returns a single record in response to a
single query. Do you see this model being changed with Sender-ID?

> to obtain policies which they apply to data flows.

DNS routing information is normally obtained at a connection rate as are
queries to listing services.  Isn't the information for Sender-ID
obtained at a much higher than these routing functions you compare it
to?  

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 07 Jul 2004 15:31:18 -0400

> Could you define what you view to be forgery?

  http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-01.txt

...
2.1. Unauthorized use of a domain name as "forgery"

   In the context of LMAP, SMTP "forgery" is defined as:

        SMTP Forgery: Use of a domain name in the argument fields of
        SMTP EHLO/HELO and/or SMTP MAIL FROM, by an SMTP client, when
        the owner of the domain name did not consent to that use of
        their name.
...

> Listing services are often more robust than a typical DNS server.

  If a DNS server holding MARID information isn't robust, then it will
most likely also fail for MX records, in addition to MARID records.

  I don't see how "robustness" matters more for DNS when it contains
MARID records than when it doesn't.  Sure, more records are being
looked up in DNS, but many MTA's already do MX lookups when receiving
mail "from" a domain, in an attempt to implicitly discover the domain
owners intent, even when there's no standard saying that they should
do this.

> The nature of a listing service returns a single record in response
> to a single query. Do you see this model being changed with
> Sender-ID?

  This is explained in:

	http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt

  My reading indicates that multiple DNS queries may be performed to
discover the location of one record, but the intention of the draft
appears to be that records should often be obtained via one query.

  The information in the record may indicate that other DNS queries
may be performed (e.g. MX).  Again, do you read the draft as saying
otherwise?

  Many MTA's already do multiple DNSBL lookups.  Do you see that
multiple DNSBL lookups by an MTA are substantially different/better
than one MARID record, possibly requiring multiple lookups?  Do you
see that MX lookups by existing MTA's are substantially
different/better than one MARID record, possibly requiring multiple
lookups?

> queries to listing services.

  I'm not sure what you mean by that.  I'm not even sure I can parse
that sentence properly.

  To take a wild guess, MARID lookups happen only when there are SMTP
connections, therefore any lookups happen at a similar "connection
rate" as queries to listing services.  The constant may be different,
but the dependency on connections is the same.

  Or, do you see Sender-ID as having an amplification problem?  e.g.
If MARID queries increased super-linearly with the number of
connections. If so, it would be a serious flaw in the proposal.

  Since the distribution of SMTP traffic to/from most sites is
non-linear across domains, and DNS information is cached, I would
expect that MARID queries would increase linearly with the number of
unique domains used in SMTP conversations, but (often) sub-linearly
with the total number of SMTP connections.

>  Isn't the information for Sender-ID obtained at a much higher than
> these routing functions you compare it to?

  ... much higher... what?  There's a word missing.

  I *think* you're saying that Sender-ID requires more lookups than
are currently required.  This isn't news.  For details as to the cost
of these lookups, see the list archives.  They contain posts from
others with quantitative summaries, describing the extra DNS costs of
MARID, and concluding that those costs are minimal.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 07 Jul 2004 18:20:28 -0700

>From this definition of forgery, it would appear you are not referring
to Sender-ID.  This is important as Sender-ID is changing the scope of
this protection.  The ASRG definition was based on an effort to reduce
mail traffic by examining RFC 2821 information. Sender-ID uses RFC 2822
information and, as such, will not impact mail traffic.  It also
currently allows extensions beyond current definitions which impacts
this concern raised regarding DNS overhead.  This change in the
definition of forgery changes the benefit equation, as there will be no
relief from accepting the mail to offset the load placed upon the DNS
server.  You should consider revising this draft before using it as a
reference. 

> most likely also fail for MX records, in addition to MARID records.

The rate that a Sender-ID SMTP receiver queries DNS versus that needed
to find an MX server by the SMTP sender are significantly different in
terms of both the number of queries and the serial sequence required. 
The loads and delays are not comparable to allow such an analogy to
dismiss these concerns. 

> owners intent, even when there's no standard saying that they should

Scale and Scope

The complex linked nature of these records becomes important as this is
indicative of limitations Sender-ID has with respect to scale.  An MX
record only refers to a set of hosts that "receive" mail for a domain. 
As SMTP allows this mail to be relayed, there may be many times this
number of hosts that "send" mail for the same domain.  In addition, all
other domains that may originate mail on behalf of this domain are to be
expressed by this Sender-ID record set.  In addition, these records also
reflect other domains that may also share these hosts.  An MX record is
never expected to be so expansive in scope nor is comparative to the
potential size of such a response.  This still excludes the "added"
features.  : 0

> http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt

Pg. 18:

5.4 Recursion Limitations

   Evaluation of many of the mechanisms in section 5.1 will require
   additional DNS lookups. To avoid infinite recursion, and to avoid
   certain denial of service attacks, an MTA or other processor SHOULD
   limit the total number of DNS lookups that it is willing to perform
   in the course of a single authentication.  Such a limit SHOULD allow
   for at least 20 lookups.  If such a limit is exceeded, the result of
   authentication MUST be "hardError".

   MTAs or other processors MAY also impose a limit on the maximum
   amount of elapsed time to perform an authentication.  Such a limit
   SHOULD allow at least 10 seconds.  If such a limit is exceeded, the
   result of authentication SHOULD be "transientError".

   Domains publishing records SHOULD keep the number of DNS lookups to
   less than 20.  Domains publishing records that are intended for use
   as the target of "indirect" elements SHOULD keep the number of DNS
   lookups to less than 10.

It would appear if there is a dropped query, it may result in a
"Transient Error" after the message has been fully received.  It would
also indicate delegation to other domains may easily result in a "Hard
Error" because someone somewhere added another delegating indirection. 
What average number of indirections per record is required before hard
errors are produced?  

> appears to be that records should often be obtained via one query.

What leads you to this conclusion?  I see the complexity of these
records growing as a defense against abusers when initially expressed 
as an "open" list.  Closing the list will require more information that
must be comprehensive.  The end result would be difficult to assess
while many records are simply left "open" initially.

> may be performed (e.g. MX).  Again, do you read the draft as saying

There are many possible indirections that may be asserted by the
Sender-ID record. Each of which may result in a sequential query. 

> different/better than one MARID record, possibly requiring multiple

Multiple RBL lookups are often done in parallel and each result in a
single response.  Many wait for a portion of these RBL queries to return
before proceeding, and do not expect all to return.  Again, these RBL
services are likely much more robust than the typical DNS server.  As I
said, there is no reason to expect the lookup of an MX record to entail
anywhere near the same amounts of information as that returned by the
Sender-ID record set.

> but the dependency on connections is the same.

Sender-ID record sets are examined for every message whereas the listing
service record happens once per connection.  Much abuse happens with
long-term connections that often send a large series of small messages. 
In such a case, the difference in magnitude with respect to DNS query
rates for Sender-ID compared to finding MX records or obtaining a
listing service record could be many orders of magnitude higher.

> connections. If so, it would be a serious flaw in the proposal.

Serious indeed.

> with the total number of SMTP connections.

But you are not limited to a single domain with abusive mail.  Often
abusive mail uses a wildcard technique to obfuscate their identity.  As
a wildcard record is superseded by real records, caching the wildcard
would be dangerous.  Our clever abuser may use a random fictitious
sub-domain.  Disaster!  Even worse, an innocent domain publishes an open
list using a wildcard.  This would be better than using someone else's
credit card.  The hapless domain may wonder what just happened to their
network traffic.  

> MARID, and concluding that those costs are minimal.

These conclusions vary widely.  There also seems to be a reluctance to
review the issue of suitable scale.

On Wed, 2004-07-07 at 2:37, Alan DeKok wrote:

wayne <[email-masked]> wrote:
> > Nothing proposed on this WG is going to stop spam.

>   No one is claiming it will.  Anyone claiming that MARID will stop
> spam should be educated as to how it works.
<snip>

I will say that Sender-ID will not affect the amount of spam that people
must sort and delete.  Authorization and Authentication of the sender
SMTP client used together with accreditation will impact the amount of
spam seen.  Such will also enable enforcement whereas Sender-ID will
not. 

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 09:24:37 +0700

Alan,

AD>   Similarly, bandages solve a transient problem, but the *existence*
AD> of bandages is a permanent phenomenom.  No one would claim that
AD> bandages "do nothing to reduce injuries" because the problem solved by
AD> bandages is transient in nature.

Interesting analogy.  Let's explore it a bit.

Bandages do not promote healing; in fact they reduce it. Their
legitimate job is to keep dirt out. When I was growing up, they were
used immediately whenever you got cut. Current medical wisdom is to
use them judiciously.

But the real problem with the analogy is that it entirely misses the
nature of the email tool being built and the nature of what it is in
response to.

The biggest worry about 'the nature of what it is in response to' is
that it has us chasing symptoms rather than causes. Spammers have
proved to be astonishingly and quickly adaptable and our response
times are pathetically slow. This means we will always be chasing the
latest symptom, rather than going to any core characteristics of the
"disease".

From a standards-making point of view, the bandage image suggests
selective application in quick response to special situations.
Unfortunately, that's not they way global standards get used.

Global standards are not used individually and they are not used
selectively. They are for interoperable situations. The result means
that applying a bandage becomes a required part of everyone's contact
with anyone else, everytime. That is neither selective nor
inexpensive.

And that's just for the current symptom.

And it has serious downside impact, if it constraints the transfer
paths of email.

All in all, this means that we are discussing major, strategic changes
to the email infrastructure, for minor, tactical, transient benefits.

I'd be interested in hearing of examples of useful global standards
that have had similar properties.

AD>   To put it yet another way, MARID can be thought of as a set of
AD> distributed DNSBL's.

Sorry, but CSV follows the BL construct, marid-core does not.

AD> Each domain operates its own DNSBL (or
AD> whitelist), which use a well-known format.

And each domain is supposed to maintain this list how, exactly?  Note
that the question is particularly relevant when spammers are quickly
obtaining and using new domains with clean records.

AD>   Peers on the net can look
AD> up information for a domain via DNS, and choose to apply the DNSBL
AD> information (or not).

"look up information for a domain via DNS"?  what whitelisting service
mechanism is specified in marid-core?

AD>   None of this is new to the net.  DNS already tells peers where to
AD> find information (e.g. MX's),

THat's not what MX does.  MX is a routing record, not a query record.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 09:33:00 +0700

Alan,

(part 2.  i hit send to quickly)

AD>   To put it yet another way, MARID can be thought of as a set of
AD> distributed DNSBL's.  Each domain operates its own DNSBL (or

This is exactly wrong.

BL's are accreditation mechanisms, whereas marid-core is an
authentication and authorization mechanism. The administrator of the
author/sender domain name is authorizing the operator of a client MTA
to carry its message.

These are very, very different functions.

Of necessity, typical accreditation mechanisms must be provided by
independent sources. marid-core does not do that.

d/

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 07 Jul 2004 23:45:14 -0400

Douglas Otis <[email-masked]> wrote:
> to Sender-ID.

  That shouldn't be news.  The original LMAP discussion paper was
written over 8 months ago for ASRG, before MARID was chartered.  The
latest draft was written weeks before the marid-core documents, so it
couldn't possibly have referred to Sender-ID.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 08 Jul 2004 00:00:03 -0400

(continuing... hit <send> accidentally>

  That shouldn't be news.  The original LMAP discussion paper was
written over 8 months ago for ASRG, before MARID was chartered.  The
latest draft was written weeks before the marid-core document, so it
couldn't possibly have referred to Sender-ID.

> This is important as Sender-ID is changing the scope of this
> protection.  The ASRG definition was based on an effort to reduce
> mail traffic by examining RFC 2821 information. Sender-ID uses RFC
> 2822 information and, as such, will not impact mail traffic.

  I never discussed Sender-ID until your recent question to me.
Unless I'm misreading the charter, MARID is still considering RFC 2821
information, which is where my focus has always been.  So I'm not sure
why you're suddenly trying to poke holes in my "Sender-ID position",
when I haven't publicly taken a position on it.

> It also currently allows extensions beyond current definitions which
> impacts this concern raised regarding DNS overhead.

  Please address those concerns to the authors of the Sender-ID
document.  I haven't said *anything* about it recently.

>  This change in the definition of forgery changes the benefit
> equation, as there will be no relief from accepting the mail to
> offset the load placed upon the DNS server.  You should consider
> revising this draft before using it as a reference.

  Since the document was never intended to address RFC 2822
information, I don't see why any revisions are necessary.

  I'm not going to respond to the rest of your message, as the issues
you raise would best be addressed by the authors or proponents of
Sender-ID.  Since I have never publicly taken a position on Sender-ID
(or even mentioned it, until you asked my opinion of it), I don't see
why you would be asking me to explain or defend it.

  My focus in ASRG & here in MARID has been RFC 2821 identities.  If
MARID is no longer discussing RFC 2821 identities, then that's news to
me.

  Alan DeKok.

---

From: wayne <[email-masked]>
Date: Thu, 08 Jul 2004 02:14:44 -0500

> MARID is no longer discussing RFC 2821 identities, then that's news to

It is my understanding that, according to the MARID charter, the
chairs would choose identities for this working group to focus on, and
other identities would be ruled out of scope.  See the MARID
description, paragraph four on:
http://www.ietf.org/html.charters/marid-charter.html

The identities selected were the 2821 identities, not the 2822
identities.  See:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html

The Sender-ID proposal, for example, deals with the 2821 SUBMITTER
identity, so it is in-scope.  (Or, at least that's the explanation
Andy gave me a while back.)

Now, I must admit that I am somewhat confused on this subject.  For
example, I seem to recall several hums at the very end of the May
interim meeting that changed the focus from 2821 to 2822, but they
weren't in minutes and others didn't seem to remember such a thing.
Who knows, I could easily be confused on this also.

Speaking of confusing and minutes, I know that draft minutes for the
May Interim meeting were posted to this list, but I don't remember
seeing any final minutes and I can't find them on the MARID charter
web page.

Will minutes be published for the Interim meetings?

-wayne

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 08 Jul 2004 11:01:12 -0400

> Interesting analogy.  Let's explore it a bit.

  Analogies are useful, but not a perfect mapping to what they're
describing.

> legitimate job is to keep dirt out.

  I've worked in a clean-room environment.  Bandages aren't very
useful there.  I've also worked on a farm, shovelling "fertilizer".
Bandages are a requirement there.

  Bandages are a *situational* solution to a temporary problem.  This
is exactly how I see MARID.  My situation may be helped by MARID, and
yours may not be.  That probably explains our respective positions.

> that it has us chasing symptoms rather than causes.

  Do you have a solution which addresses the cause?

>  Spammers have proved to be astonishingly and quickly adaptable

  In some situations.  In others, they are astonishingly idiotic.
Once again, the behavior is situational.

> This means we will always be chasing the latest symptom, rather than
> going to any core characteristics of the "disease".

  Do you have a solution which addresses the cause?

  If not, why do you keep repeating this, as though it's relevant?

  To address your analogy, please read a medical compendium containing
descriptions of diseases and their treatments.  In many cases, the
phrase to note is "treatment is symptomatic".

  That is, there is no cure, or the cure is too expensive, or the cure
would take more time than letting the disease run its course.
Therefore, the only relevant treatment is to address the symptoms.

  This is where your analogy of "disease" is directly on point.  We
have no cure for the "disease" of spam.  We do know how to treat
certain symptoms, and some people are starting that treatment.
Despite the known symptoms and known treatment, others appear to be
have problems with treating the symptoms, because that treatment isn't
a cure.

  I must admit I'm confused by that attitude.  Sumptomatic treatment
isn't a cure, and no one expects it to be a cure.  It's simply a
stop-gap until a cure is found.  But I don't see how treating the
symptoms in any way prevents a cure from being found.

> selectively. They are for interoperable situations.  The result
> means that applying a bandage becomes a required part of everyone's
> contact with anyone else, everytime.

  Why?  You've made a leap from MARID being used by cooperating peers,
to it being:

  a) "required" somehow, by some fiat
  b) used by everyone (even people who don't want to use it?)
  c) used always (even when whitelists make it unnecessary?)

  I'm confused as to why you keep making those claims, when the scope
of the proposals are significantly narrower than you would make them
seem.

> to the email infrastructure, for minor, tactical, transient benefits.

  I guess my examples of how MARID can have permanent benefits didn't
make it from the list to your inbox.  Or maybe you think that a
permanent way of treating symptom is useful only in the short term.
e.g. open proxies.  The symptom (abuse of open proxies) was treated by
closing them down.  Spammers no longer use open proxies in the same
volume that they used to.  But does this mean we can go back to
setting up open proxies?  Of course not... but you're making that same
argument for methods to treat forgeries.

> that have had similar properties.

  Since you've defined the situation to be a straw man of your own
invention, you are, of course, perfectly right.  No such global
standards exist.

> Sorry, but CSV follows the BL construct, marid-core does not.

  Terminology.  I was referring to the work in the MARID group, not to
a proposal.  (Which is called what, Sender-ID?  Or did the WG decide
that marid-core was the protocol we will standardize, and that we
would call it MARID?  I must have missed that...)

> obtaining and using new domains with clean records.

  I think you're missing my point.  My intent was to say that each
domain maintains a DNSBL (or whitelist) of IP's which it permits to
use it's name.  That's the basic concept behind MARID.  Having domains
maintain BL's about others is expensive and pointless.

> THat's not what MX does.  MX is a routing record, not a query record.

  The intent of MX is that it is *interpreted* as a routing record.
The MX record itself is stored in DNS, which any client may query.  I
can query for an MX record, and then never use that information to
perform routing.

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 23:15:40 +0700

Alan,

>>  Spammers have proved to be astonishingly and quickly adaptable
AD>   In some situations.  In others, they are astonishingly idiotic.
AD> Once again, the behavior is situational.

the folks who command estimated millions of compromised machines, with
a 3- or 4-tier control hierarchy, do not count as idiotic.

let's design mechanisms that deal with those guys. the rest are
irritating but they are mere noise.

>> going to any core characteristics of the "disease".
AD>   Do you have a solution which addresses the cause?

yes, but,

i've been asked to refrain from pursuing that topic for a few weeks...

AD>   If not, why do you keep repeating this, as though it's relevant?

i've explained the reason quite a few times. just so it is not missed
again:

   Effort on a global standard that deals with a transient symptom is
   certain to have minimal, transient benefit, if any, but with very
   large opportunity and on-going costs.

AD>   To address your analogy,

If you mean bandages, it's not mine.  you introduced it, as i recall.
I was simply trying to pursue it.

AD>  please read a medical compendium containing
AD> descriptions of diseases and their treatments.  In many cases, the
AD> phrase to note is "treatment is symptomatic".

Please show me a successful, global standard that has been designed to respond to
one set of symptoms, when the source of those symptoms is constantly
adapting, guaranteeing that the symptoms will become irrelevant as
soon as the response begins to take effect.

You characterize my query as using a straw man.  However it is the
conceptual summary of the current effort, from the standpoint of
standard-based intervention to fix a problem.

so it is not a 'straw man' because it is not creating a convenient
hypothetical. it is a description of the current effort. feel free to
find fault with it, preferably by citing which parts of the summary
are wrong, and how.

>> contact with anyone else, everytime.
AD>   Why?  You've made a leap from MARID being used by cooperating peers,
AD> to it being:
AD>   a) "required" somehow, by some fiat

to be at all effective, the mechanism must be used all the time and we
will never know when or if we can stop using it.  (it's in the nature
of aversion reinforcement training.)  that is tantamount to requiring
its use forever.

AD>   b) used by everyone (even people who don't want to use it?)

if they want their mail to get through, yes.

AD>   c) used always (even when whitelists make it unnecessary?)

whitelists are accreditation.

the marid-core is about authentication and authorization.

they are independent.

>> Sorry, but CSV follows the BL construct, marid-core does not.
AD>   Terminology.

no, computer science.

the difference between accreditation, versus authentication and
authorization, is basic.

AD>  I was referring to the work in the MARID group, not to
AD> a proposal.  (Which is called what, Sender-ID?  Or did the WG decide
AD> that marid-core was the protocol we will standardize, and that we
AD> would call it MARID?  I must have missed that...)

marid-core is the only working group document with a specification
currently under discussion.  whatever else folks might be mentioning,
there is no working group document for it.

>> obtaining and using new domains with clean records.
AD>   I think you're missing my point.  My intent was to say that each
AD> domain maintains a DNSBL (or whitelist) of IP's which it permits to
AD> use it's name.

the term whitelist usually refers to hosts or networks with behavior
that is deemed likely to be acceptable to the receiver, not the
sender.

no, that's not quibbling.  it goes to the difference between
authorization and accreditation.

AD>  That's the basic concept behind MARID.  Having domains
AD> maintain BL's about others is expensive and pointless.

pointless?  so spamhaus and all those other lists are pointless?

>> THat's not what MX does.  MX is a routing record, not a query record.
AD>   The intent of MX is that it is *interpreted* as a routing record.

it's the semantics of the record, not the "intent".

d/

---

From: Greg Connor <[email-masked]>
Date: Thu, 08 Jul 2004 11:51:38 -0700

--Douglas Otis <[email-masked]> wrote:

> information and, as such, will not impact mail traffic.

This point assumes that mail traffic will continue at the same level, even 
when messages are being rejected post-data.  Spammers don't want to spend 
time and bandwidth on a losing transaction any more than receivers do.  I 
assume the opposite: that when forgeries are being detected (even after 
DATA) that the traffic causing the failed messages WILL go down.  This is 
based on the idea that spammers will adapt in order to get their messages 
through.

> The loads and delays are not comparable to allow such an analogy to

I think the previous message was referring to MX records being looked up by 
the receiver (to see if the sender's MX is 127.0.0.1 for example).

I believe most MARID DNS queries will be 1 or 2 per transaction and can be 
cached easily.  I have seen nothing to suggest that the relationship is 
other than linear.  Therefore I dismiss "these concerns" which seem to 
suggest that the relationship is geometric or exponential or whatever.  It 
doesn't make sense, and is not borne out by the early adopters of SPF.

> potential size of such a response.  This still excludes the "added"

Hmm, this paragraph also seems to contain high FUD-to-fact ratio.

>> connections. If so, it would be a serious flaw in the proposal.

Hmm, in that case I would be interested to see any information that leads a 
reasonable person to believe that the relationship is not linear.  (hint: 
y=20x is a linear relationship)

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 08 Jul 2004 15:12:27 -0400

> a 3- or 4-tier control hierarchy, do not count as idiotic.

  I have two responses:

  a) please re-read what I wrote.  I said SOME are idiotic, not ALL.
     It's rude to cherry-pick a complicated scenario, and make it
     sound like I said those people were dumb.  I didn't.

  b) Don't mistake "script kiddies" for people with a clue, or for
     spammers.  Computers have things called "scripts" or "programs"
     which idiots can run to perform complicated tasks.  And idiots
     can buy CPU time on "owned" machines from smart people, and use
     that time to send spam.

> i've explained the reason quite a few times. just so it is not missed

  Shall I re-post my standard response?  I don't feel we're
communicating here.  I try to explain my position in response to your
posts, and your replies simply re-state your position.

  Did you think I didn't read your comments?  Or maybe I didn't
understand them?  I thought my responses explained not only that I
understood them, but that I disagreed.  I even gave reasons why.

> I was simply trying to pursue it.

  Uh, no.  You called spam a "disease", which is either an analogy, or
perjorative term.  My later sentences followed the disease analogy,
and didn't discuss bandages.  Perhaps you were confused that both
analogies had medical roots.

> Please show me a successful, global standard that has been designed
> to respond to one set of symptoms, when the source of those symptoms
> is constantly adapting, guaranteeing that the symptoms will become
> irrelevant as soon as the response begins to take effect.

  I could swear I had addressed that comment in my previous message.

> pointless?  so spamhaus and all those other lists are pointless?

  I am continually amazed at how what appears to me to be simple
english is construed to mean the most idiotic things.

  What I was originally discussing was ideas from this WG: domains
hosting policy information about themselves in DNS.  RMX, SPF, CSV,
and Sender-ID all fall into this category.  My comments that MARID
could be construed as domains maintaining black/whitelists were
intended to be taken in the context of this WG: domains maintain
policy information about themselves, and that information may be used
by others as input to blacklists/whitelists.  You seemed to interpret
that statement as saying that every domain would have to maintain
information about every other domain.  And when I said that was
pointless, you suddenly switched to thinking that I was claiming
DNSBL's were pointless.

  Can you explain to me how I can write simple english sentences on
this list, so you don't interpret them as being blindingly idiotic
statements?

  I'm appalled at how badly we're communicating.

  For the record, I believe I understand your opinion very well.  You
think temporary measures aren't permanent solutions.  I agree.  You
think that these temporary measures require some kind of global
coordination before they will work.  I don't see why.  You think that
we should be looking for cures, rather than temporary measures.  I
agree.

  Where I disagree with you is in the utility of the temporary
measures.  You seem to think they have no longer-term utility, and
I've tried to demonstrate why I think you're wrong.  Rather than
address my concerns, you just repeat your position.  I don't see why
this approach would be considered communication.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 08 Jul 2004 13:37:57 -0700

> based on the idea that spammers will adapt in order to get their messages 

Trojans sending much of the viruses (for more Trojans) and spam (for
revenue) are not concerned about full compliance to a specification, nor
do they implement proper states for an SMTP client.  Why attribute abuse
to malevolent intent when expediency is more likely a principle
motivation. So stopping a message after wasting the full bandwidth of
the rejected message may seem like a small concern, but there may be
another 100,000 more of these Trojans requesting service.  The extra
bandwidth to get them to leave is never recovered by their rejection. 
In addition, many of these spammers use a technique that appends a
random sub-domain resolved using a wildcarded record as a means to
obfuscate filters.  It also means data needed for a repeated visit or a
repeated message will not be in a DNS cache. A loss of even more
bandwidth on the DNS queries, possibly more than from the messages being
checked.

> doesn't make sense, and is not borne out by the early adopters of SPF.

Could you explain the premise used for this assumption?

> Hmm, this paragraph also seems to contain high FUD-to-fact ratio.

Sending hosts > Receiving hosts (increases scale and scope)
Originating domains > Receiving domain (increases scale and scope)
Receiving Domain sets > Receiving domain (increases scale and scope)

What are you disputing by making such a statement?

My premise is that abuse of published partial lists left open will
ensure either the removal of these records, or an attempt to fully
publish a comprehensive record set.  A desire to delegate to other
domains providing services runs the risk that as they add a few
indirections, this may cause hard errors and the complete loss of mail
service without the administrator of the domain having done anything
atypical or perhaps having done nothing.

> y=20x is a linear relationship.

In reference to the information added to the core document

Pg. 18:

Using an assumption that Sender-ID records are able to limit the
required queries to 10 and set the "transientError" timeout at 10
seconds, what will be the impact on network integrity?

The transport for SMTP uses TCP, but now Sender-ID interjects 10 UDP
queries per message that "must" occur or the connection suffers a
temporary error event requiring a repeat of a message transfer.  The
default for a resolver lookup timeout is typically set to 5 seconds (a
minimum of 2 seconds) as RFC 1035 recommends, where 10 seconds is
considered worst case.  Should there be a another timeout, this limit
often doubles.  The connection is tasked with making 10 UDP queries
within 10 seconds however.

Should the network suffer a 5% packet loss rate, then 1 packet will be
lost on average within these 10 lookups.  This will invoke the 5 second
timeout which then reduces the time for the remainder of the queries
(possibly leaving half a second apiece to resolve each new query). 
Depending upon the distribution of lost packets, the connection could be
lost after reception of the first message, only to be retried again
later and could make a large transfer of messages impractical.  TCP used
for SMTP could deal with this packet loss rate, but because of Sender-ID
and these many queries with a short timeout, the integrity of SMTP is
significantly reduced.

If the timeout are restored to normal limits for these DNS queries,
Sender-ID may dramatically reduce performance of the SMTP server and the
reason for imposing the hazardous time constraint.  The trade-off
becomes either a possibly dramatic reduction in performance of the SMTP
server, or a dramatic reduction in the network integrity for the SMTP
server during times of network congestion.  The use of the RFC 2822
identities for Sender-ID means messages are transferred regardless
whether they become rejected.  A loss of integrity will then add to
network congestion and thereby possibly leading to a collapse of the
network due to the non-linear effect caused by congestion, redundant
transfers by Sender-ID, and the reduced network integrity.

-Doug

---

From: Greg Connor <[email-masked]>
Date: Thu, 08 Jul 2004 15:16:30 -0700

> Could you explain the premise used for this assumption?

No.  I am not making an assumption, just dismissing yours ;)

>> Hmm, in that case I would be interested to see any information that
>> leads a  reasonable person to believe that the relationship is not
>> linear.  (hint:  y=20x is a linear relationship.
>

I interpret the above as "Given sufficiently bad networks and servers, DNS 
queries might take a long time."  Of course SenderID would be affected by 
this.  So would CSV.

This does not show the relationship is non-linear.  Do you need more 
information as to what linear means, or are you ignoring the point and 
spreading FUD on purpose?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 08 Jul 2004 17:25:52 -0700

> No.  I am not making an assumption, just dismissing yours ;)

Based upon what?  You should at least attempt to support this conjecture
as to the number of queries.  If this is a valid position, then the
draft should reflect these constraints.  You may notice, it does not.  

> queries might take a long time."  Of course SenderID would be affected by 

I did not say sufficiently bad networks and servers.  I said congestion
at 5% loss.  This rate does not change behaviors of congestion
algorithms significantly.  As you may know, UDP traffic does not have
congestion avoidance, and yet there could be a blizzard of UDP traffic
with Sender-ID.  Add to this, repeated transfers of messages exhibited
during times of congestion exacerbated by the reduced integrity of SMTP
when using Sender-ID.  Breakdown of the network throughput would be a
complex non-linear function for this scenario.

CSV would reject a connection without affecting the timeout on the DNS
query and compensate for DNS overhead by blocking transfer of all
unwanted messages.  Nor would CSV require information to be repeated.
Nor would there be such a predominance of UDP traffic with CSV.  But
this is not about CSV.  This is about Sender-ID.

> spreading FUD on purpose?

You have not offered simulations for traffic flow to counter this
claim.  You have not offered a premise for your assumptions regarding
the number of queries needed.  An effective proponent would not resort
to personal berating to dissuade critics.

"The rare happiness of times, when we may think what we please, and
express what we think." Cornelius Tacitus

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 08 Jul 2004 15:12:27 -0400

I have two responses:

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 9 Jul 2004 17:00:39 +0700

Alan,

AD>   a) ...  I said SOME are idiotic, not ALL.
AD>      It's rude to cherry-pick a complicated scenario, and make it
AD>      sound like I said those people were dumb.  I didn't.

In fact, you have been focussing entirely on the 'dumb' spammers,
whereas I have chosen to focus entirely on the smart ones.  You are
citing the dumb ones on the basis of making certain decisions for
global standards to be reasonable.

I am citing the smart ones because they will roll past any standard
that is not robust against them.

AD>   b) Don't mistake "script kiddies" for people with a clue, or for
AD>      spammers.

I wasn't.  That is why I'm citing the smart guys.  The ones with
multi-level control mechanisms and many thousands or millions of
compromised machines.

AD>   Computers have things called "scripts" or "programs"
AD>      which idiots can run to perform complicated tasks.  And idiots
AD>      can buy CPU time on "owned" machines from smart people, and use
AD>      that time to send spam.

I guess I am missing the point behind citing how dumb these guys are.

What does that fact do with respect to protocol standards decisions?

AD>   What I was originally discussing was ideas from this WG: domains
AD> hosting policy information about themselves in DNS.  RMX, SPF, CSV,
AD> and Sender-ID all fall into this category.  My comments that MARID
AD> could be construed as domains maintaining black/whitelists were
AD> intended to be taken in the context of this WG: domains maintain
AD> policy information about themselves, and that information may be used
AD> by others as input to blacklists/whitelists.

The terms whitelist and blacklist have significant and rather
consistent history.  I fail to see the benefit in redefining them for
this working group.  Besides being seriously confusing, the definition
is not written down in a working group document.

AD>   For the record, I believe I understand your opinion very well.  You
AD> think temporary measures aren't permanent solutions.

Tautologies can be humorous, but that isn't what I said.  I said that
temporary measures are highly inappropriate for global standardization.

AD>   Where I disagree with you is in the utility of the temporary
AD> measures.

And that is why I keep asking for examples of comparable efforts --
global standards that provide temporary measures against side-effects
rather than core aspects of a problem.  When has such an approach
worked?

d/

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 09 Jul 2004 11:38:53 -0400

Dave Crocker <[email-masked]> wrote:
> whereas I have chosen to focus entirely on the smart ones.

  Yes.  I know how to stop the dumb spammers, but I don't know how to
stop the smart ones.  So far as I can tell from your posts, neither do
you.

>  You are citing the dumb ones on the basis of making certain
> decisions for global standards to be reasonable.

  Because they will stop dumb spammers.  Do you believe that dumb
spammers will go away?  Do you believe that in the absence of new
measures, spammers will voluntarily stop spamming?  Do you believe
that the flaws in SMTP which enable undetectable forgery shouldn't be
changed?

  You don't address any of these issues in your posts.  You just keep
focussing on a never-never land scenario, where there is somehow a
magical way to stop the smart spammers.  But since that scenario
doesn't exist, you're stuck opposing people who are trying to work on
solutions they know how to implement.

> What does that fact do with respect to protocol standards decisions?

  Because the dumb guys won't go away until you make them go away.

> AD> My comments that MARID
> AD> intended to be taken in the context ...

> consistent history.  I fail to see the benefit in redefining them
> for this working group.

  I talked about analogies and comparisons.  You took that to mean I
was re-defining common terms.  Very cute.

  My conclusion is that your position is absolutist, and you filter
everything you read through an absolutist interpretation.  I say "may
be", and you read "is required to be".  I say "can be seen as", and
you read "re-defined to be".

  The problem is that *my* position is not absolutist, and there's
nothing I can do to convince you of that fact, or to get you to read
my statements in anything other than absolutist terms.  What's worse,
is that your absolutist view results in wild misinterpretations of
what I've said, which you then claim is my position.

> temporary measures are highly inappropriate for global standardization.

  Like NAT?  Most people would agree that it's an ugly hack, and is
highly inappropriate for global standardization.  Yet everyone also
agrees it won't be going away any time soon.

> rather than core aspects of a problem.  When has such an approach

  Do you believe that in the absence of MARID, spammers will stop
forging on their own?  Do you believe that if MARID is deployed for a
short while, spammers will forever stop forging?  Do you believe that
if MARID deployed is temporarily, that people can later stop using it?

  The problem of forgery is a permanent design flaw in SMTP.  The
problem of bounce-path verification is a permanent design flaw in
SMTP.  Methods like MARID will address these flaws, and will
permanently fix the underlying problem.  Calling forgery a "convenient
hack", and MARID a "temporary measure" is a viewpoint that is not in
agreement with the facts.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 09 Jul 2004 11:58:56 -0400

Douglas Otis <[email-masked]> wrote:
> claim.

  The original question was entirely independent of traffic flow.

>  You have not offered a premise for your assumptions regarding the
> number of queries needed.

  The relationship I originally discussed, and what Greg was talking
about, was how the number of DNS queries depended on the number of
incoming SMTP connections.

  Let's define some terms:

  N = number of SMTP connections to an MTA
  D = number of DNS queries performed by that MTA, per SMTP connection.
  T = total number of Sender-ID DNS queries performed by the MTA.

  Q: Is T = \theta(N)?

  Your response was that D was large, and would cause the net to
collapse.  I don't see how that could be construed as answering the
question.

>  An  effective proponent would  not resort  to personal  berating to
> dissuade critics.

  An effective opponent would answer questions, and would not resort
to avoiding the issue.  The alleged ad hominem was directly on point:
You were asked a question, and you refused to answer it.  Your answer
was ambiguous as to whether or not you even understood the question.

  From my reading of Sender-ID, all of the DNS lookups it performs are
initiated from SMTP connections.  Therefore, the relationship must be
that T=\theta(N), and probably T=DN.

  Your argument that D is large is a nice one, but irrelevant to the
question you were asked.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 09 Jul 2004 11:51:40 -0700

>   The original question was entirely independent of traffic flow.

Any question of network stability would, by its very nature, be related
to traffic flow.  : )

> collapse.  I don't see how that could be construed as answering the

Taking the limits recommended by the draft (as a should), there may be
as many as 20 DNS queries per message, or more!  If compared to normal
SMTP use where, as example, 100 messages are being transfered, at the
receiving SMTP server, there may be a single DNS lookup at the beginning
of the session.  Assuming an average message size of 4k bytes in this
example, where the average TCP packet payload is 1,400 bytes, this means
within about 300 TCP packets received, there would be one small UDP
query.  For Sender-ID, the number of DNS queries added if at the should
not exceed limits, would be 2000 UDP queries.  The ratio of UDP queries
to TCP packets, in this case, goes from 0.3 % to 666.0 % of TCP packets.

>   Your argument that D is large is a nice one, but irrelevant to the

The limits as to the number of DNS queries per message should have some
basis. : >  My question, I thought, was clear.  What is the basis of
this limit in terms of DNS queries per message?  This is expressed
within the draft. I simply asked what the basis of this limit was.

The next related question, of course, is what is the basis of the 10
second recommended timeout for the total of these 20 DNS queries?   

This is referencing information added to the core document

Pg. 18:

Please notice, these limits are expressed only as SHOULD.  I know a
particular vendor was hoping to add to this and may explain why these
limits are so large. : 0 

I assume these numbers were not pulled from someone's hat.  ; >

Using these limits, how does the nature of the traffic change?  These
DNS queries will be comprised of Ethernet (26), IPv4 (20), and UDP (8)
for about 54 bytes of transport overhead. Add to this the size of TXT
record with about another 56 bytes response overhead and the size of the
name referenced. Add to this the SOA field and Additional Data field. I
will assume an average DNS response to be 350 bytes (out of a  576 byte
packet limit) and about 100 bytes for the query. (The 512 byte DNS limit
allows for transport overhead.)  So for the TCP traffic of about 400
kbytes, 900 kbytes is used for the DNS queries. This recommended limit
changes the traffic ratio of UDP/TCP traffic from 0.007 % to 225.0 % at
the 666.0 % UDP/TCP packet ratio. 

Such a change to the amount of UDP traffic will impact the amount of
packet loss, as UDP does not have congestion avoidance.  I looked at a
5% packet loss to make a rough estimate of what this could mean with
respect to the timeout on these series of DNS queries being produced for
each message.  With 20 DNS queries (40 packets) and a 5% packet loss and
a 5 second DNS query retry period, the 10 second recommended timeout
forces a 450 error at the end of the data phase for first message of 4
kbytes (although completely received in this storm of DNS traffic). 
This message will be discarded and require a retransmission at some
later point as well as stopping the remaining messages.

A few points added to this was that a common technique used by spammers
was employing a random (often several) sub-domains accessing a
wildcarded record to obfuscate their identity as a ploy to thwart
filtering.  This means the DNS cache will not contain this record.  This
is an important consideration as with the Sender-ID, all traffic is
received before being discarded and a high percentage of this will be
spam.  The behavior of many spammers is not to remember the message
rejected with an error or to wait any period of time before retrying.  A
different message identity will appear, still not found in the cache,
and where the rejection process does not lessen the traffic load.

As legitimate data attempts to slog through this blizzard of UDP, they
will be dropped rather often and forced to retry as the per DNS query
set allotment ensures a reduction of connection integrity compared to
TCP. A basis for these numbers before making a serious assessment would
be expected of anyone asked to take on such a difficult endeavor.  The
impression I have is these numbers were simply guesses and do not
justify such examination until there is some expectation these will not
change again and again.

-Doug

---

From: Greg Connor <[email-masked]>
Date: Fri, 9 Jul 2004 15:17:54 -0700 (PDT)

1. Your assertion was that the relationship between SMTP connections and DNS 
requests is not linear.  This is clearly false.  You can admit that was a 
mistake, and retract it, or you can explain why you said it.  Doing neither is 
called "spreading FUD".

> 5% packet loss to make a rough estimate of what this could mean with

2. You seem to be implying that UDP packets are more likely to be dropped than 
TCP packets.  This is clearly false.

3. Any hypothetical situation prefixed by "Assume 5% packet loss" is pretty 
worthless.  5% packet loss is something to yell at your ISP about, not 
something you just assume as part of normal operation.

> For Sender-ID, the number of DNS queries added if at the should

4. A statement like "666% UDP to TCP ratio" seems to imply that an average 
SMTP transaction requires 20 DNS UDP packets, but only 3 TCP packets.  Do you 
really believe it's possible to deliver a message with only 3 TCP packets?  My 
rough guess was at least 14 and usually 20.

> So for the TCP traffic of about 400

5. You seem to be assuming that UDP packets have overhead and TCP packets do 
not.  Also you seem to be assuming that since 20 lookups is the limit, that it 
will also be the average. 

6. In practice, mail receivers already do plenty of DNS lookups, including the 
sender domain, the PTR of the IP, its corresponding A, the MX of the purported 
sender, one or more DNSBLs and/or RHSBLs.  You don't appear to be taking this 
into account.  It is unrealistic to expect an SMTP transaction to be accepted 
with "only one" DNS lookup.

I don't think it's productive for me to reply to you anymore on this thread. 
My feeling is that your "concern" is not consistent with the reality, and you 
have not produced any "real world" measurements enough to merit attention for 
any "concern".  I refuse to spend my time trying to disprove something that 
has not been supported at all (let alone proved) in the first place.  
Especially given that every time I reply to this thread I get back MORE FUD.

If you are really "concerned" your best bet is to try to explain the "concern" 
to someone else, offline, who can understand it, AND who can write about it 
clearly and concisely.  If you are not really concerned and are just spreading 
FUD because you don't like SenderID, well, have fun, but I am not going to 
play that game anymore and I expect others will get tired of it soon too.

--
Greg Connor
[email-masked]

Everyone says that having power is a great responsibility.  This is a lot
of bunk.  Responsibility is when someone can blame you if something goes
wrong.  When you have power you are surrounded by people whose job it is
to take the blame for your mistakes.  If they're smart, that is. 
                -- Cerebus, "On Governing"

---

From: Douglas Otis <[email-masked]>
Date: Fri, 09 Jul 2004 17:59:37 -0700

> mistake, and retract it, or you can explain why you said it.  Doing neither is 

Here is the offending comment that I think you are referring to:

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

: On Wed, 2004-07-07 at 12:31, Alan DeKok wrote:
<snip>
: >   Or, do you see Sender-ID as having an amplification problem?  e.g.
: > If MARID queries increased super-linearly with the number of
: > connections. If so, it would be a serious flaw in the proposal.
:
: Serious indeed.
:
<snip>

I see this as my agreeing to Alan Dekok's statement.  But what you
missed is that there was an amplification problem that Alan overlooked
because he was still using the ASRG assumptions of RFC 2821 information
used to reject messages.  He admitted this difference in a subsequent
message.  I also started this message by indicating his reference to the
LMAP discussion would be in error because of this, as it effected the
benefit equations.  To say I agreed with the statement does not mean I
agreed with his example.  I started this message making this concern
explicit.  Or so I had thought. : (

It was an example giving by Alan regarding a general concern.  I felt
there was an amplification problem that results from the use of the RFC
2822 information and an integrity problem causing repeated data.  As the
load on the network increases, a greater amount of data will need to be
repeated.  Rejection of messages subsequent to their receipt due to
timeout conditions reaching much abbreviated limits for DNS responses
will lead to this instability.  High levels of DNS traffic will
exacerbate such a problem.

The sender of the message may have done nothing wrong, but the data must
be resent adding to the network load.  As this load increases, the
amount of traffic that must be resent increases further.  I would
describe this a non-linear amplification problem and my reason for
saying "Serious indeed."

> TCP packets.  This is clearly false.

Where do I say this?  When the predominate traffic goes from a small
percentage of UDP traffic, to where UDP traffic becomes the prevalent
traffic, there will be a higher rate of packet loss.  Unlike TCP, there
is no direct means to signal a lost packet except by the lapse of time. 
Unlike TCP, UDP can not detect congestion and resorts to an
exponentially increasing timeout on retries in an effort to avoid packet
loss.  This defensive strategy is defeated if the amount of independent
UDP queries exceed network capacity. : (

> something you just assume as part of normal operation.

Yes, 5% would be a rather high level of loss, but I would not blame my
ISP if most of my traffic was mostly UDP.  : 0

> rough guess was at least 14 and usually 20.

This does not change the fact that the payload of UDP traffic went from
.007 % to 225.0 %.  Whether there are a few smaller TCP packets is of
minor importance or that the numbers were .01 % to 225 %, I think this
should provide a clear picture of the problem.

> > So for the TCP traffic of about 400 kbytes, 900 kbytes is used for
> > the DNS queries. This recommended limit changes the traffic ratio of
> > UDP/TCP traffic from 0.007 % to 225.0 % at the 666.0 % UDP/TCP
> > packet ratio.
> 

It is expressed as a limit. If there are domains permitting this number
of lookups, there is nothing wrong according to the draft.  I was
illustrating the absurd levels of UDP traffic the 20 DNS lookups per
message would entail.  I had started out using half of this number, but
it did not seem to make an impression.  Typically there are 4 DNS
retries for a query where the timeout doubles each time.  In an attempt
repair the DDoS problem, the time cap for the entire set of queries was
added to prevent the type of exposure to unknown servers as clarified in
John Levine's tests: 

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

> with "only one" DNS lookup.

Yes, there will be queries to RBLs in most cases and a few other DNS
checks.  RBL checks are to known servers that are often fairly robust.
This fully misses the concern raised however, as none of these normal
checks will cause good messages to be repeated.  Nor will these rise to
a level of UDP requests that may overwhelm network traffic with respect
to payload, as it can for Sender-ID.

-Doug