Subject: extensibility as an attack vector

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 23 Jun 2004 12:46:02 -0500

What is the possibility that an attacker could list a (SID|SPF) record
with references to ~thousands of domains, forcing my SMTP server to spend
large amounts of time and/or processing power validating the junk data?
What other similar kinds of attacks are enabled by infinite extensibility?

There is also still the argument that 513-byte records affect a DDoS
attack against my domain.

The more I think about this, the less I think that extensibility is a good
idea in general. I actually think that constraining the authorization data
to addresses, mx, and domains is probably best, and requireing everything
else go into an external policy document that I will only check in certain
other cases.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 23 Jun 2004 17:05:15 -0400

On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote:
| 
| What is the possibility that an attacker could list a (SID|SPF) record
| with references to ~thousands of domains, forcing my SMTP server to spend
| large amounts of time and/or processing power validating the junk data?
| What other similar kinds of attacks are enabled by infinite extensibility?

These attack scenarios have been raised in the past.  Seen
from the point of view of "don't spammers want their mail to
get through?" they seem unlikely, but if we counter "but
spammers may want to attack the integrity of the entire
system as a whole" they make more sense.

In fact, your attack scenario can be constructed independent
of extensibility considerations.  The moment you introduce a
new behaviour (a MARID dns lookup) you are able to attack it
(a slow SERVFAIL will consume resources).  Extensibility
amplifies the attack in degree but not in kind.

We are moving from an "assumed innocent unless proven
guilty" model of email to an "asumed guilty unless proven
innocent" model.

I see this as a simple matter of hygiene in the big city.
If the crazy homeless guy on the street offers me a
bloodstained driver's license, I won't even get as far as
looking at its expiration date; I won't even take it for
fear of disease.

In the same way, the best defense against the attacks you
suggest is to perform the reputation lookup *before* the
authentication lookup.

If the reputation lookup says "bad guy" then the
authentication lookup is moot.

If the reputation lookup says "good guy" then you have
reason to believe the query won't crash your system.

If the reputation lookup says "no reputation, but
accredited" you can provisionally assume "good guy".

If the reputation lookup says "unknown and unaccredited",

  If you are being very cautious, you may wish to greylist
  and return 4xx without doing the auth lookup at all.  A
  distributed reputation system should obtain information
  fast enough to be useful the next time the query happens.

  If you are being less cautious, you can do the auth lookup
  anyway, and if it fails to resolve within a reasonable
  amount of time, you can abort the lookups and feed a
  grumpy opinion into your reputation service.  The next
  time the attack occurs, you'll know not to do the auth
  query.  Introduce noise into subsequent iterations
  according to game theory to create opportunities for
  forgiveness.

Some MTA admins I know are looking at the OS fingerprint of
the incoming packets and rejecting any mail that comes from
a Windows OS.  This blocks a lot of viruses at the cost of
cutting out legitimate Windows MTAs.  I mention this as an
anecdote only.

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 23 Jun 2004 23:32:12 +0200

On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote:
> idea in general.

No. This is not a problem of extensibility. 

This is an attack outside the threat model. 
All these caller authorization methods are designed against 
an attacker who does not want to reveal his identity (=domain).

An attacker who attacks you while not hiding his own domain is 
a different kind of attack. Such an attacker could also simply
allow mail from 0.0.0.0/0, thus authorizing all IP addresses in 
order to allow spam. 

This has already been discussed more than a year ago in ASRG and 
addressed in RMX and other proposals. It is up to you to define
a policy about domains you're willing to accept mail from. 

E.g. you could choose to not accept mail from domains authorizing 
more than 50 IP addresses. Thus the interpreter could reject messages
from domains with such a record with thousands of references without 
performing a single query. And you should do it. 

Imagin this attack: An attacker is sending millions of spam with 
his own sender address   @attacker.tld   
His MARID record is generated dynamically with thousand references 
of the type  randomnumber.victim.tld

Thus the victim's DNS server will have to serve billions of queries. 
You need limits. 

But, if this happens, you know at least the domain the attacks came
from. It is similar to the case where the spammer simply used his 
own domain as a sender address (=does not fake). Fake protection is 
useless against attackers who do not fake. You still need 
blacklisting, but now blacklisting is possible. And you need 
whois entries which allow to identify the person responsible for 
the domain.

regards
Hadmut

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2004 15:57:04 -0700

> amplifies the attack in degree but not in kind.

By attacking and breaking the MARID mechanism in the channel, assurances
offered recipients become easily spoofed.  The result of the attack
could allow a bonanza of fraud displaying the highly promoted MARID seal
of approval.

> guilty" model of email to an "assumed guilty unless proven
> innocent" model.
> 

If the name of the domain is used, there would be no protection
afforded. Reputation based upon address is difficult to accurately vet
and thus is not as comprehensive.  An address also provides no history
other than was once known to have been abused.

> If the reputation lookup says "bad guy" then the authentication
> lookup is moot.
> 

This would suggest that a "good guy" address list be created as
protection prior to SPF/CID authentication techniques.  This would be
difficult to vet and would be prone to false negatives.  The service
would not see the domain it references.  With all this, it sounds as if
you are advocating DNS be mirrored privately.  

Attacks may be staged by selecting diverse and real, but complex and
convoluted records.  Heavy loads on these name servers could provide
erratic responses without a need to engineer this behavior.  The SPF/CID
process will continue through the entire list as a result.  Add to this,
the use of hostile name servers offering maniacal records that do
authenticate.  Frankly, either approach could bring down this complex
SPF/CID system regardless of the use of these hygienic precautions.

> accredited" you can provisionally assume "good guy".

This implies yet another category.  New to the "good guy" list perhaps? 

> cutting out legitimate Windows MTAs.  I mention this as an

Authorizing and authenticating the MTA can happen at the same moment a
query is sent to reputation services, if this authorization and
authentication only require return of a single record as illustrated in-

http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-00.txt

With this approach there would be little exposure to a threat without
reliance upon a reputation service.  In addition, use of the HELO domain
would enable a means to follow-up on abuses needed by authorities.  For
absolute protection from joe jobs, promote the use of the Fenton
proposal for critical communications such as those used for commerce. 
Perhaps make it criminal not to use this Fenton mechanism when
advertising.  This Fenton process can safely take place at the MUA and
not negatively impact either SMTP or DNS.  This krs approach is
extensible if desired as it can be scaled.  Have it add a photo, voice,
or video to help prevent mistaken identifications of the human kind. 
Importantly, these alternatives would not break the current way mail is
used. 

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2004 16:44:05 -0700

> an attacker who does not want to reveal his identity (=domain).

If the attack simply provides the wrong name, it may take a prolonged
period to discover this falsehood.  The hostile intent is to disable the
channel checks for MARID.  If the lie is perpetrated many times to
different destinations, then the hapless name server would be expected
to become erratic.  (MARID=DDoS)

> allow mail from 0.0.0.0/0, thus authorizing all IP addresses in 

Nothing so brazen is needed. Real open lists provide the same avenue for
committing fraud.  Without requiring an absolute acceptance of
accountability, as perhaps with EHLO, the system remains prone.  This
absolute is not possible if based upon other identities.  It must
reference the domain currently sending mail.

> a policy about domains you're willing to accept mail from. 

I doubt there is such a safe area with SPF/CID.

> more than 50 IP addresses.

If my domain points to AOL as an outside provider and they have this
number, then my mail becomes rejected?  How can such a policy apply
uniformly without millions of exceptions?

> Thus the interpreter could reject messages from domains with
> such a record with thousands of references without performing
> a single query. And you should do it. 

Whatever limit you define, that will become known to the attacker
learning to fly below your radar.

> Imagine this attack: An attacker is sending millions of spam with 

The standard needs limits. For EHLO checks, it could be just one.

> from.

How?  If the attacker referenced an open list, there was never any
positive identification.

> It is similar to the case where the spammer simply used his 
> useless against attackers who do not fake.

This was in regard to an attack where even real records offer a means to
obfuscate the identify of the host sending mail.  With perhaps millions
unwilling to close lists due to a loss of an ability to use alternative
access, those wishing to abuse the system are afforded ample means to
hide their identify and evade being categorized. 

> You still need blacklisting, but now blacklisting is possible. And you
> need whois entries which allow to identify the person responsible for 
> the domain.

How does blacklisting become more effective if the identification
remains unknown?  SPF/CID create valid reasons for retaining open
lists.  Their existence doom any scheme that relies upon positive
identification.  Outside the use of the EHLO domain, where can
identification become strict without breaking SMTP?  

-Doug

---

From: Roy Badami <[email-masked]>
Date: Thu, 24 Jun 2004 00:58:41 +0100

Given the momentum behind SPF, and the desire of Microsoft to do
something similar with Caller ID, I think that something very similar
in spirit to draft-ietf-marid-core is going to be defined and
implemented anyway one way or another, whether blessed by the IETF
standards track or not.

I think it would be beneficial for this effort to happen within the
IETF rather than without.

CSV/CSA takes a very different approach, and is also of benefit.
Whilst it would be possible to validate the HELO identity using an SPF
or XML syntax, the requirements of CSV's problem space make that
overkill.

The two approaches seem complementary to me; is there any reason why
this WG can't advance both to PS?

The charter does says:

    This working group will develop *a* DNS-based mechanism for
    storing and distributing information associated with that
    authorization. [emphasis mine]

Does this have to be interpreted strictly, or is it possible for the
WG to develop *two* DNS-based mechanisms, without being required to
conflate them into a single mechanism, if (as I believe it might be)
it's technically beneficial to specify them independently, and not try
to unify them in any way?

    -roy

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 23 Jun 2004 23:50:01 -0400

On Thu, Jun 24, 2004 at 12:58:41AM +0100, Roy Badami wrote:
| 
| CSV/CSA takes a very different approach, and is also of benefit.
| Whilst it would be possible to validate the HELO identity using an SPF
| or XML syntax, the requirements of CSV's problem space make that
| overkill.

"Overkill" is relative --- if the evalute_spf function is
already available, might as well apply it to the HELO name
and get back something useful.

I have been calling this approach "Unified SPF" --- it
embraces the CSV and the MTAMark/SS semantics using the SPF
syntax and lookup, just as SPF has embraced the CallerID
semantics with SenderID.

People have been mentioning Unified SPF on-list a little bit
lately but I thought I should probably put it forward
officially and see what people think.

| The two approaches seem complementary to me; is there any reason why
| this WG can't advance both to PS?

I explain in more detail at
http://spf.pobox.com/slides/unified%20spf/

Comments are welcome.

meng

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2004 22:28:05 -0700

> http://spf.pobox.com/slides/unified%20spf/

Complexities of the SPF/CID records cause potential exposures needing to
be mitigated.  If the address is immediately expressed to match against
the EHLO domain, this risk can be circumvented if mandated as an
absolute requirement.  Alternatively, adding an SRV record provides this
function without a need to parse textual information and correlates with
SMTP host names rather than mail domains.  If only employing the EHLO
check, the SRV record would be simpler to implement and requires fewer
changes to the SMTP server.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jun 2004 19:00:45 +0800

Meng (and everyone else),

I'd like to ask that we step back and consider something rather basic.

MWW> I have been calling this approach "Unified SPF" --- it
MWW> embraces the CSV and the MTAMark/SS semantics using the SPF
MWW> syntax and lookup, just as SPF has embraced the CallerID
MWW> semantics with SenderID.

When I first heard about SPF, I thought I knew what it was. Over time,
I have become quite sure that I don't. The text of your note, "Unified
SPF" eliminated any doubt that I might have had. A specification that
increasingly is described as being able to do everything is one that
always confuses the heck out of me.

So I would find it extremely helpful to hear some precise descriptions
of what this thing called SPF really is and what it really does.  When
we have a clear and consistent understanding of it, the community can
reasonably assess what is reasonably appropriate to count within SPF
and what should be counted as outside it.

Knowing what is NOT in a mechanism is often more important than
knowing what is IN it.  For all discussions over recent months, it
appears that every feature for spam and spoofing control can be
incorporated in SPF.  This should give us some pause. Offhand, I
cannot think of a successful Internet protocol that has demonstrated
this degree of flexibility.

By way of pursuing this off of a previous, related thread:

MWW>      SPF is extensible.  Multiple mechanisms can be defined.  While other

 Extensibility is always appealing, but it also often is surprisingly
 risky, both in the near-term and the long-term. Referring to it can
 be a mantra for avoiding careful analysis in the near-term and for
 deferring considering of essential issues. Of course, in the
 long-term it can fail to support the promised enhancements, at the
 least resulting in massive opportunity costs.

 Here, it raises a rather basic question: What, exactly, is SPF? What
 mechanisms does it provide? What incremental value-add does it
 create?

 My reason for asking such a basic question is that I think it is
 important for the community to be clear about proposals, so they know
 what they are "buying". The alternative is that they will have
 unrealistic expectations and wind up at least disappointed, and
 possibly far worse.

 (The delays in issuing the recent version of our own CSV proposal was
 that we felt it essential to hold it to this strict standard of
 clarity. It turned out to be remarkably difficult to be sufficiently
 clear about describing the details of functionality, even amongst
 ourselves.)

 A number of different answers about SPF are possible. I suspect my
 own list of choices is woefully incomplete, but here goes:

    LABEL: SPF is a a suite of essentially independent tools, brought
    under a common label. Taking the example of the extension you
    suggest for DomainKeys, SPF does not "do" DomainKeys, Rather, it
    "refers" to it. What does it actually mean to say that SPF
    "supports" DomainKeys? At the least, this means that the cited
    mechanisms need to be evaluated independently, to consider their
    independent behaviors and merits.

    CAPABILITIES: SPF is a means of publishing email reception access
    control capabilities. Hence it permits sending SMTP clients to
    know what tests they will be subjected to and, by implication,
    what tests they need to facilitate, such as doing their own
    publishing of relevant information, marking of individual
    messages, etc. It is worth noting that the DNS is only one, useful
    means of getting information published on the net. In fact there
    are some IETF "capabilities" standards that support alternative
    means of permitting such publishing through different channels.

    POLICES: SPF is a means of publishing email reception access
    control capabilities, as well as detailing parameters for the
    behavior of the supported mechanisms. Given the current meaning of
    the "P" in SPF, this might seem the obvious choice, but public
    discussion usually describes SPF as "doing" the control
    mechanisms, rather than only "describing" them.

    PLATFORM: SPF is a means of performing a series of email reception
    access control tests. It provides an common, integrated platform
    for these test, leveraging common component mechanisms for
    efficiencies such as simpler software and easier administration.
    Including something like DomainKeys would suggest that that this
    choice does not apply, since DoimainKeys is an entirely
    independent mechanism.

 The reason this question is important was underscored at the SPF BOF
 at Inbox event: a room full of staunch supporters also thought the
 question important enough to discuss and participants gave
 significantly different answers. Even supporters are not very clear
 about the details of the job that SPF does.

 For a specification that has been around this long, that kind of
 uncertainty is worthy of note and repair.

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>

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: John Leslie <[email-masked]>
Date: Thu, 24 Jun 2004 09:07:42 -0400

> and get back something useful.

   The problem with this approach is subtle.

   Indeed, for a receiving SMTP server which already incorporates SPF,
the additional coding to call the subroutine one more time is trivial.
But that has little to do with whether it's "overkill", and even less
to do with whether it's the right tool for the job.

   Throughout the SPF design process, there has been a conscious choice
to load processing tasks onto the receiving SMTP server in order to make
the process of advertising SPF records as simple as possible. (This is
based on a belief that it will be easier to convince a few dozen coders
of MTA software than to convince millions of domain owners.)

   Missing from this analysis is the question of convincing hundreds of
thousands of MTA managers to enable the SPF function (already programmed)
on each MTA. Perhaps I'm more paranoid than I need to be about what the
spammers will do. Or perhaps I'm not paranoid enough...

   But I definitely see spammers upping the ante: they have available
millions of zombie computers on "fast" connections, and the managers
of those "fast" connections seem determined to do nothing to stop this:
merely to limit (some of) these computers to 500 emails per day.

   Thus, I believe we need a truly "lightweight" mechanism to separate
whether we're dealing with an unauthorized zombie computer. SPF is
simply _not_ lightweight enough.

   Please understand: for what it sets out to do, one could argue that
SPF _is_ "lightweight". But it sets out to do so much that we cannot
place upper bounds on the processing that might be required.

   If we reach a situation where turning on the SPF feature brings
each MTA to its knees, the feature _will_ be turned off quickly. And
the management of that MTA won't be inclined to turn it on again. And
the word will get out.

   For our own interests, we want to guard against something like this.
We want to protect ourselves from a ten-times increase in activity by
zombie computers. For this we need a tool whose processing load is
bounded. This is specifically what CSV was designed for.

   To tackle the RFC2822 header issues, we need the complexity of SPF;
to screen out zombie computers, we don't.

> syntax and lookup, just as SPF has embraced the CallerID

   There's another issue I suppose deserves mention yet again: that
reaching consensus in the MARID WG is just one step towards an IETF
standard. (I'll let others judge how close we are to consensus.)
SPF is (IMHO) absolutely dependent on the use of TXT records in areas
of the DNS tree where other TXT records are likely to be found. We
_know_ we're going to face a lot of flak from DNS experts over this
issue. This cannot fail (IMHO) to slow down the process of becoming
an IETF standard.

> officially and see what people think.

   I think, frankly, that SPF has to stop changing if there's ever to
be any hope of progressing to an IETF standard.

   (It's possible, I suppose, for it to achieve "market-share" without
settling down; but that's not what the MARID WG is for.)

> http://spf.pobox.com/slides/unified%20spf/

   Here, Meng advises folks to not worry about the difference between
HELO and RFC2822. Inevitably, that will lead to a large number of
domains advertising relatively open SPF records, and those relatively
open records being used to "authenticate" HELOs of MTAs which the actual
domain never had the slightest intent of trying to control. And, since
all of this is publicly available in DNS, spammers will quickly compile
a list of these.

   But it gets worse: Meng actually advises bypassing further checks
if the HELO passes SPF checking and the domain passes reputation checks.
(Think about it, Meng: I'm sure you'll relent.)

   Whereas CSV is designed for exactly the purpose of authenticating
and authorizing MTAs: there will be no confusion whether we're talking
about taking responsibility for the actions of the MTA or trying to
control the path which may be used to send email from the domain.

   Think it through, Meng: ease of advertising should never be sought
at the expense of _accuracy_ of advertising.

--
John Leslie <[email-masked]>

---

From: "John Leslie" <[email-masked]>
Date: Thu, 24 Jun 2004 15:24:00 +0200

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 24 Jun 2004 06:57:50 -0700 (PDT)

> http://spf.pobox.com/slides/unified%20spf/

First, thank you for adding lookup at the PTR name, I now feel that MARID 
live meeting was indeed a usefull event for me to have come to...

For technical comment, I think it would be good if SPF had scope modifier 
where it could be set which identity (or more then one if necessary) is 
this record for. For example:

v=spf1 id:mailfrom { ip4:192.168.0.1/16 } id:submitter { ip4:192.168.0.20/24 }
v=spf1 id:mailfrom+submitter ip4:192.168.0.1/16 id:ehlo mx id:all -all

This may possibly be as an operator that changes scope of the identity for 
record that follows to only cover certain specified identity type, if what 
is being verified is of different identity type, that data is ignored
until another modifier is found that changes the scope back to either all 
or identity type that is wanted.

---
William Leibzon
Elan Networks
[email-masked]

---

From: "william\(at\)elan.net" <[email-masked]>
Date: Thu, 24 Jun 2004 16:05:59 +0200

---
William Leibzon
Elan Networks
[email-masked]

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 24 Jun 2004 10:25:50 -0400

On Thu, Jun 24, 2004 at 06:57:50AM -0700, william(at)elan.net wrote:
| 
| For technical comment, I think it would be good if SPF had scope modifier 
| where it could be set which identity (or more then one if necessary) is 
| this record for. For example:
| 
| v=spf1 id:mailfrom { ip4:192.168.0.1/16 } id:submitter { ip4:192.168.0.20/24 }
| v=spf1 id:mailfrom+submitter ip4:192.168.0.1/16 id:ehlo mx id:all -all
| 
| This may possibly be as an operator that changes scope of the identity for 
| record that follows to only cover certain specified identity type, if what 
| is being verified is of different identity type, that data is ignored
| until another modifier is found that changes the scope back to either all 
| or identity type that is wanted.

A macro to represent scope is probably cleaner than a scope modifier.

I want to state up front my assumption that most publishers
will never need to distinguish between scopes: most domains
should be able to simply set-join all the four scopes into a
single record, and apply local policy from there.

That is to say, if the policy for HELO names is

  v=spf1 A -all

and the policy for PRA names, if different, is

  v=spf1 B -all

the joint policy can be

  v=spf1 A B -all

However, if it really is important to distinguish the two,

            domain.com   v=spf1 redirect=%{scope}._spf.%{d}

  helo._spf.domain.com   v=spf1 A -all
   pra._spf.domain.com   v=spf1 B -all

This solution provides the desired functionality of "which
identity?"  scoping.

In practice the %{scope} would really be a single character
not chosen yet.

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 24 Jun 2004 10:49:46 -0400

On Thu, Jun 24, 2004 at 09:07:42AM -0400, John Leslie wrote:
| 
| 
|    Thus, I believe we need a truly "lightweight" mechanism to separate
| whether we're dealing with an unauthorized zombie computer. SPF is
| simply _not_ lightweight enough.

The question of the relative weight of block vs factored
records has been addressed in the past.

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

In my discussions with Microsoft and AOL, I have gathered
the impression that large mail receivers favour block
records because they are more easily cached and more easily
transformed into a representation native to their internal
antispam engines.  Factored records which require a new
lookup for every cache negative are, in their world, not
lightweight by comparison.

I should have shared this input sooner as a justification
for block records.

|    If we reach a situation where turning on the SPF feature brings
| each MTA to its knees, the feature _will_ be turned off quickly. And
| the management of that MTA won't be inclined to turn it on again. And
| the word will get out.

This is an important caveat, and one which we should all
do our best to avoid.  The folks at sendmail.net are
researching this very point as part of their testing and
analysis; I expect our speculation about the relative burden
of each approach will soon be informed by better data.

| HELO and RFC2822. Inevitably, that will lead to a large number of
| domains advertising relatively open SPF records, and those relatively
| open records being used to "authenticate" HELOs of MTAs which the actual
| domain never had the slightest intent of trying to control. And, since
| all of this is publicly available in DNS, spammers will quickly compile
| a list of these.
| 
|    But it gets worse: Meng actually advises bypassing further checks
| if the HELO passes SPF checking and the domain passes reputation checks.
| (Think about it, Meng: I'm sure you'll relent.)

In the next revision of the website I will try to be very
clear about the ways in which receivers might put SPF
records to use, and how senders can accommodate the
different scenarios.

| 
|    Think it through, Meng: ease of advertising should never be sought
| at the expense of _accuracy_ of advertising.
| 

Yes, this is very true and important.

I will also write up some text to explain in detail exactly
what the deal is, and what people are buying when they buy
in to the system.

---

From: Roy Badami <[email-masked]>
Date: Thu, 24 Jun 2004 16:41:14 +0100

>>>>> "Meng" == Meng Weng Wong <[email-masked]> writes:

    Meng> In my discussions with Microsoft and AOL, I have gathered
    Meng> the impression that large mail receivers favour block
    Meng> records because they are more easily cached and more easily
    Meng> transformed into a representation native to their internal
    Meng> antispam engines.  Factored records which require a new
    Meng> lookup for every cache negative are, in their world, not
    Meng> lightweight by comparison.

But, AIUI, CSV in it's current incarnation involves doing an SRV
lookup on the domain name; how is this more heavyweight than doing a
TXT lookup.  CSV looks just as cacheable to me as SPF, but uses more
compact records...

	 -roy

---

From: "Roy Badami" <[email-masked]>
Date: Thu, 24 Jun 2004 17:53:46 +0200

-roy

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 24 Jun 2004 13:46:46 -0400

On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote:
| 
|     Meng> antispam engines.  Factored records which require a new
|     Meng> lookup for every cache negative are, in their world, not
|     Meng> lightweight by comparison.
| 
| But, AIUI, CSV in it's current incarnation involves doing an SRV
| lookup on the domain name; how is this more heavyweight than doing a
| TXT lookup.  CSV looks just as cacheable to me as SPF, but uses more
| compact records...
| 

I was mainly comparing cache negatives.

Scenario: 5 spams that all say MAIL FROM:<[email-masked]>

Let each spam come from a different IP.

  client ip         factored query         block query
  ---------   --------------------------   ---------------
  192.0.2.1   lookup(aol.com, 192.0.2.1)   lookup(aol.com)
  192.0.2.2   lookup(aol.com, 192.0.2.2)      cached
  192.0.2.3   lookup(aol.com, 192.0.2.3)      cached
  192.0.2.4   lookup(aol.com, 192.0.2.4)      cached
  192.0.2.5   lookup(aol.com, 192.0.2.5)      cached

In this scenario, factored queries do not benefit from
local DNS caching.

So, the theory is: a spam run against a single receiver
domain may originate from X distinct IPs.

That spam run may forge Y distinct domain names.

If X >> Y, a block format is better than factored.

If Y >> X, block and factored formats are equivalent within
one order of magnitude.

Scenarios in which factored formats beat block formats hands
down tend to be contrived.

The current threat model is lots of zombies, hence lots of
IPs.  True, there's nothing to stop them from forging lots
of domains, too.  That's where the MTAMark design proves
useful --- it scales well, because only one network owner
has to add records.

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 24 Jun 2004 13:59:17 -0400

OK, speaking of CSV in its current incarnation, can anyone
give me a concrete example of how the
authentication/authorization procedure operates?

In SPF, authentication is simple: you do the SPF TXT lookup,
you get back the SPF TXT record, the computer thinks a bit,
and you get a well-defined PASS or FAIL or NEUTRAL, etc
response.

In CSV, http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11
suggests that you do authentication by doing a A lookup of
the HELO name;

(if an SRV lookup against _client._smtp.DOMAIN returns "2",
AND
 (the IP address of the SMTP client is one of the A records of the HELO name,
  OR
  the IP address of the SMTP client was returned in the SRV
  response's Additional Data section,)

THEN that is equivalent to an SPF "PASS".

Is that correct?

I would request that the next draft of the CSV proposal
contain some examples and walkthroughs.

---

From: Roy Badami <[email-masked]>
Date: Thu, 24 Jun 2004 19:16:44 +0100

I still don't see how it's different.

In draft-ietf-marid-core, the first of the above will do a TXT query
on _ep.aol.com and aol.com.  Each of the subsequent lookups will use
the positively or negatively cached results.

In draft-ietf-marid-csv-csa, the first of the above will do a SRV
query on _client._smtp.aol.com.  Each of the subsequent lookups will
use the positively or negatively cached results.

    -roy

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 24 Jun 2004 15:56:55 -0400

On Thu, Jun 24, 2004 at 05:53:46PM +0200, Roy Badami wrote:
| 
| But, AIUI, CSV in it's current incarnation involves doing an SRV
| lookup on the domain name; how is this more heavyweight than doing a
| TXT lookup.  CSV looks just as cacheable to me as SPF, but uses more
| compact records...
| 

OK, if CSV's authentication procedure is "does an A lookup
on the HELO name describe the client IP" then yes, it is
just as cacheable.

If an ISP wants to set a policy where it always says

  HELO isp.com

instead of 

  HELO mx-1.isp.com
  HELO mx-2.isp.com
  HELO mx-3.isp.com

then the CSV authentication procedure may not be sufficient.

---

From: Roy Badami <[email-masked]>
Date: Thu, 24 Jun 2004 21:38:32 +0100

>>>>> "Meng" == Meng Weng Wong <[email-masked]> writes:

    Meng> OK, if CSV's authentication procedure is "does an A lookup
    Meng> on the HELO name describe the client IP" then yes, it is
    Meng> just as cacheable.

No, an SRV lookup on the HELO (then an A lookup on the result of that).

I think it works like an SPF record containing a single 'a' mechanism.

    Meng> If an ISP wants to set a policy where it always says

    Meng>   HELO isp.com

    Meng> instead of

    Meng>   HELO mx-1.isp.com HELO mx-2.isp.com HELO mx-3.isp.com

    Meng> then the CSV authentication procedure may not be sufficient.

Normally you'd be expected to have something like:

mx-1.isp.com.			IN A		1.1.1.1
mx-2.isp.com.			IN A		2.2.2.2
mx-3.isp.com.			IN A		3.3.3.3

_client._smtp.mx-1.isp.com.	IN SRV		1 2 mx-1.isp.com.
_client._smtp.mx-2.isp.com.	IN SRV		1 2 mx-2.isp.com.
_client._smtp.mx-3.isp.com.	IN SRV		1 2 mx-3.isp.com.

But if you really want to use HELO isp.com, then in CSA I think it is

mx-1.isp.com.			IN A		1.1.1.1
mx-2.isp.com.			IN A		2.2.2.2
mx-3.isp.com.			IN A		3.3.3.3

_client._smtp.isp.com.		IN SRV		1 2 mx-list.isp.com.

mx-list.isp.com.		IN A		1.1.1.1
				IN A		2.2.2.2
				IN A		3.3.3.3

Though the A record could end up getting big for a large ISP -- I
think the draft makes the point that ISPs may wish to change their
HELO strings to avoid saying HELO isp.com

     -roy

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 24 Jun 2004 16:49:33 -0400

On Thu, Jun 24, 2004 at 09:38:32PM +0100, Roy Badami wrote:
| 
| No, an SRV lookup on the HELO (then an A lookup on the result of that).
| 
| I think it works like an SPF record containing a single 'a' mechanism.
| 
| Normally you'd be expected to have something like:
| 
| mx-1.isp.com.			IN A		1.1.1.1
| mx-2.isp.com.			IN A		2.2.2.2
| mx-3.isp.com.			IN A		3.3.3.3
| 
| _client._smtp.mx-1.isp.com.	IN SRV		1 2 mx-1.isp.com.
| _client._smtp.mx-2.isp.com.	IN SRV		1 2 mx-2.isp.com.
| _client._smtp.mx-3.isp.com.	IN SRV		1 2 mx-3.isp.com.

If this is true, then CSV is logically equivalent to a block
record, and my comments about factored records are not
relevant.

More relevant is my suggestion that doing an SPF lookup
against the HELO name can offer the same semantics.

Which one is more lightweight becomes a question of whether
you already have an SPF library at hand :)

---

From: John Levine <[email-masked]>
Date: 25 Jun 2004 03:52:15 -0000

>In my discussions with Microsoft and AOL, I have gathered the
>impression that large mail receivers favour block records because
>they are more easily cached and more easily transformed into a
>representation native to their internal antispam engines.  Factored
>records which require a new lookup for every cache negative are, in
>their world, not lightweight by comparison.

That's definitely how the Exchange group feels, since Exchange is a
single long-running large program with threads handling the SMTP
sessions.  In this case, it's faster to slurp up all of the domain's
info once and cache it inside the application.

Most Unix MTAs including sendmail, exim, qmail and (I believe) postfix
fork off a process per SMTP session which exits at the end of the
session.  In this case, any effort beyond that to validate the single
IP used in the session is wasted, and the local DNS cache is where the
info will be remembered.  My impression is that there are a lot of
large sites whose MTAs work this way.

The reason I concocted FSV, which as you may recall "panders to all
factions" is that there are significant communities which do it each
way.  FSV could serve up block records for people who want block
records and factored records for people who want factored records.

I realize that there's other ways to deal with this situation.  For
example, you might have a special purpose DNS cache which fetches
block records, but then responds to factored queries from local
clients.  I know how I might write one of them, but until we try it, I
wouldn't want to guess how well it'd work in practice.

What this all tells me is that we're still nowhere near ready to
standardize anything, because we don't have experimental data to tell
us about performance issues, how the bad guys will counterattack, or
any other real world problems we'll run into if we actually try to use
this stuff.  Publishing SPF records isn't enough -- people have to use
them to filter mail or at least log info about what happened when they
fetched the SPF data and what would have happened if they used that
data for mail filtering.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: wayne <[email-masked]>
Date: Fri, 25 Jun 2004 00:12:24 -0500

> place upper bounds on the processing that might be required.

You can place an upper bound on SPF processing, although I think that
much stricter limits need to be placed in the standards.  (Yes, I have
argued with Meng over this subject, I should probably push him again
since it has been over a week. ;-)  I have also done DoS attack
studies on SPF, both from the point of view of attacking the receiving
MTA and from the point of view of tricking receiving MTAs into
participating in a DDoS attack on someone else.  Obviously I can't say
there aren't any problems, but this is a security issue that I have
certainly investigated.

> issue. This cannot fail (IMHO) to slow down the process of becoming

I have posted data and analysis of the sizes of SPF records and the
types and sizes of pre-existing TXT records to this list before.  I
can give you pointers if you can't find them.  (I just posted a short
update using the same subject line, "Some stats on TXT usage in domain
names") 

If I could wave a wand and make the problems of using a different RR
disappear, I certainly would.  However, from my studies, I can't find
a serious problem with SPF's use of TXT records.

> all of this is publicly available in DNS, spammers will quickly compile

I understand your concern, but I think the problem will be
self-correcting.  If spammers run out of domains that haven't
published SPF records, and decide that using their own domains is too
much of a problem and therefore start trying to use domains which
aren't tight enough, I think the domain owners will quickly tighten
them down.

As Meng mentioned in another post, there are a couple of ways of
providing per-scope rules, when they are really needed.

> (Think about it, Meng: I'm sure you'll relent.)

Uh, Hmmm...  I'm not Meng, but I have thought about it.  I see no
problem with an email receiver being able to whitelist anyone they
want.  Whitelists need a verifiable identity, and using SPF to verify
that makes sense to me.

-wayne

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Jun 2004 00:31:59 +0100

On Thu, 24 Jun 2004, Roy Badami wrote:
>
> I think [SRV] works like an SPF record containing a single 'a'
> mechanism.

It's a bit more subtle than that. A SRV lookup give you an IP address list
(the result of an A and AAAA lookup on the SRV target domain name) as well
as some auxiliary data. CSV uses the auxiliary data for authorization
information (yes, no, dunno) and the addresses for authentication. SPF
doesn't distinguish authentication and authorization.

However the end result is roughly the same, but CSV is more efficient.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LOUGH FOYLE TO CARLINGFORD LOUGH: NORTHWEST 5 LOCALLY 6 GRADUALLY DECREASING 2
OR 3 AND BECOMING VARIABLE, LATER INCREASING SOUTH 4 LOCALLY 5. ISOLATED
SHOWERS. MAINLY GOOD. MODERATE DECAYING SLIGHT.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Jun 2004 15:28:18 +0800

Meng,

Two responses, for the price of one:

MWW> OK, speaking of CSV in its current incarnation, can anyone
MWW> give me a concrete example of how the
MWW> authentication/authorization procedure operates?

MWW> In SPF, authentication is simple: you do the SPF TXT lookup,
MWW> you get back the SPF TXT record,

Forgive me, but:

MWW> the computer thinks a bit,
MWW> and you get a well-defined PASS or FAIL or NEUTRAL, etc
MWW> response.

That sounds quite a bit about the old joke about the blank space in a
board that is otherwise filled with equations. The scientist responds
to a query by pointing to it and says "that's where a miracle
happens".

So, yes, your description does indeed sound simple, but that to be
because you left out all of the interesting stuff.

MWW> In CSV,
MWW> http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11
MWW> suggests that you do authentication by doing a A lookup of
MWW> the HELO name;

It's not a "suggestion". It is a "specification". The differences is
important. CSV is very simple and constrained. It is entirely based on
the SMTP HELO.

If you are using some other identity, then you are not using CSV. That
is why the specification has a title that says "client smtp". The HELO
is the only place that that client is able to declare its identity.

MWW> I would request that the next draft of the CSV proposal
MWW> contain some examples and walkthroughs.

My co-authors have thoughtfully added a rather nice description of the
usage sequence in Section 1 of <draft-ietf-marid-csv-intro-00>.

More detailed examples are almost always often helpful, so perhaps you
could describe what sorts of cases you would like to see described?

 - - - - -

MWW>   client ip         factored query         block query
MWW>   ---------   --------------------------   ---------------
MWW>   192.0.2.1   lookup(aol.com, 192.0.2.1)   lookup(aol.com)

As your discussion highlights, there is some complexity to the desired
lookup- and storage- compression efficiencies that folks might seek.
The usual implication of such an observation is that folks should be
careful about standardizing particular choices, until there is
experience with the physics of the service.

In any event, as Roy noted, CSV does a forward query based on a domain
name. The incoming IP Address may be used by a higher-level CSV
process, to do some comparing.

So the "factored query" that you describe does not show up in CSV. For
that matter, it is not a DNS query, since you do not get to specify
two lookup keys in a DNS query. You specify one, a domain name.

According to the example you give, the CSV style of query therefore
looks like the column marked "block query".

In the typical case, returned information will include a set of IP
Addresses in the Additional Information field. How the DNS client
chooses to organize and use this information is its own business. That
choice is not forced upon them by the protocol.

At best what you scenario suggests is that a CSV-category module
should do its own caching and do it more cleverly than a
run-of-the-mill system DNS cache.

I suspect the confusion in your comments is between protocol versus
implementation.  Clearly, one would want the implementation to have a
feature along the lines you described, since that gives nice caching
behavior.

As I understand it, the working group is doing PROTOCOL specification
-- specifically a DNS record, though we seem to range rather farther,
in order to understand what we need the record FOR.  We are not doing
implementation standardization.  As long as the protocol does not
behave in a way that prevents good implementation, then the it is not
the working group
optimization that you are suggesting.

So I am not understanding what difference in protocol behaviors you
are distinguishing between SPF and CSV, with respect to the functions
raised for this thread.  (As I noted in a separate note, the scope of
SPF is something I've been finding confusing, so I'm forced to use the
CSV scope for this note.)

d/

MWW> On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote:
MWW> | 
|     Meng>> antispam engines.  Factored records which require a new
|     Meng>> lookup for every cache negative are, in their world, not
|     Meng>> lightweight by comparison.
MWW> | 
MWW> | But, AIUI, CSV in it's current incarnation involves doing an SRV
MWW> | lookup on the domain name; how is this more heavyweight than doing a
MWW> | TXT lookup.  CSV looks just as cacheable to me as SPF, but uses more
MWW> | compact records...
MWW> | 

MWW> I was mainly comparing cache negatives.

MWW> Scenario: 5 spams that all say MAIL FROM:<[email-masked]>

MWW> Let each spam come from a different IP.

MWW>   client ip         factored query         block query
MWW>   ---------   --------------------------   ---------------
MWW>   192.0.2.1   lookup(aol.com, 192.0.2.1)   lookup(aol.com)
MWW>   192.0.2.2   lookup(aol.com, 192.0.2.2)      cached
MWW>   192.0.2.3   lookup(aol.com, 192.0.2.3)      cached
MWW>   192.0.2.4   lookup(aol.com, 192.0.2.4)      cached
MWW>   192.0.2.5   lookup(aol.com, 192.0.2.5)      cached

MWW> In this scenario, factored queries do not benefit from
MWW> local DNS caching.

MWW> So, the theory is: a spam run against a single receiver
MWW> domain may originate from X distinct IPs.

MWW> That spam run may forge Y distinct domain names.

If X >>> Y, a block format is better than factored.

If Y >>> X, block and factored formats are equivalent within
MWW> one order of magnitude.

MWW> Scenarios in which factored formats beat block formats hands
MWW> down tend to be contrived.

MWW> The current threat model is lots of zombies, hence lots of
MWW> IPs.  True, there's nothing to stop them from forging lots
MWW> of domains, too.  That's where the MTAMark design proves
MWW> useful --- it scales well, because only one network owner
MWW> has to add records.

d/

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Jun 2004 15:10:11 +0800

Meng,

d/

d/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 25 Jun 2004 14:04:24 +0200

> because you left out all of the interesting stuff.

Well, it's _possible_ to leave out the interesting stuff if that's 
defined as a local matter.

If the "SPF publisher" is responsible for interpreting his own policy, 
which is queried via RPC by mail recipients, then there's no reason to 
specify the interesting stuff as an internet standard.

The "SPF publisher" need not run any software server - something like 
the pobox SPF wizard can easily provide that service. I'd be happy to 
provide such a wizard.

Arnt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Jun 2004 21:16:54 +0800

Arnt,

>> because you left out all of the interesting stuff.

AG> Well, it's _possible_ to leave out the interesting stuff if that's
AG> defined as a local matter.

If it were strictly a local matter, it would not need to be published
in the DNS.

The problem is that the receiving SMTP server is required to interpret
the SPF policy that is published by a sender some indeterminate number
of MTA hops upstream.

That is very much NOT local.

d/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 25 Jun 2004 15:38:36 +0200

Dave Crocker writes:
> the SPF policy that is published by a sender some indeterminate 
> number of MTA hops upstream.
>

Right. I'd like the publication to contain only an address/port. The 
receiving SMTP sender looks the address up, makes an RPC to the 
published address (e.g. using UDP, although BXXP is a possibility too), 
receives a well-defined FAIL/PASS/NEUTRAL answer, and that's it.

The address/port may be located at the site that makes the policy, or it 
may be at a third party which offers a wizard like that Pobox offers 
for SPF.

Arnt

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 25 Jun 2004 09:41:17 -0400

On Fri, Jun 25, 2004 at 03:38:36PM +0200, Arnt Gulbrandsen wrote:
| 
| Right. I'd like the publication to contain only an address/port. The 
| receiving SMTP sender looks the address up, makes an RPC to the 
| published address (e.g. using UDP, although BXXP is a possibility too), 
| receives a well-defined FAIL/PASS/NEUTRAL answer, and that's it.
| 
| The address/port may be located at the site that makes the policy, or it 
| may be at a third party which offers a wizard like that Pobox offers 
| for SPF.

For the record, the design you describe above has been
fleshed out --- as DVP.  It was not submitted to this WG but
I wanted to mention it for completeness.  If anyone's
keeping track of MARID/LMAP-family proposals, this should be
on the list.

http://www.exploits.org/dvp/

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 25 Jun 2004 10:06:22 -0400

On Fri, Jun 25, 2004 at 03:28:18PM +0800, Dave Crocker wrote:
| MWW> In CSV,
| MWW> http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11
| MWW> suggests that you do authentication by doing a A lookup of
| MWW> the HELO name;
| 
| It's not a "suggestion". It is a "specification". The differences is
| important. CSV is very simple and constrained. It is entirely based on
| the SMTP HELO.
| 

The text I was referring to said:

    There is no universal method to authenticate that a host is
    correctly identifying itself. For most email purposes, it
    will be sufficient to show that the EHLO domain name
    forward-resolves to the IP address.

"For most email purposes" looks like a loophole to me, which
is why I was requesting clarification.

If it said "do an A/AAAA lookup on the HELO domain name; the
client IP must appear on the list of returned addresses", I
would feel I had a better understanding.

As things stand now, one could read the draft as saying "for
most email purposes, a forward lookup is sufficient; for
other purposes, you may need to do an SPF evaluation against
the HELO domain name" in which case SPF would be compatible
with, and even a part of, the CSV concept.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 25 Jun 2004 09:40:15 -0500

> fleshed out --- as DVP.

> http://www.exploits.org/dvp/

That's similar to but barely a fraction of the functionality that Arnt is
describing. DVP as described therein only says whether or not an address
is valid, while Arnt is saying that the 'sender authorization' problem in
its entirety can be handled by such a query-response system.

There's a lot to be said for such an approach. The DNS overhead would be
reduced to SRV entries. The computational load would be linked to the
sender's volume instead of the recipient's volume. Etc.

Arnt needs to make some time to write up his proposal still. :)

---

From: John Leslie <[email-masked]>
Date: Fri, 25 Jun 2004 10:45:52 -0400

>     forward-resolves to the IP address.

   For context, let me quote the rest of section 5.2:
] 
] CSV usually returns the list of IP addresses in the reply to the
] SRV query. The Host Name Authentication appendix gives advice on
] how to proceed if no list is returned.
] 
] If the list is returned and the actual IP address is in it, the
] receiving SMTP server SHOULD consider the EHLO domain name to be
] authenticated. Conversely, if the list is returned and the
] actual IP address is not in it, the assertion of the EHLO domain
] name SHOULD be considered incorrect, and an error returned.

> is why I was requesting clarification.

   The point we intended was that this level of authentication
(finding a matching IP address in the response to a forward DNS
query) is not sufficiently strong for "all" purposes.

   If you follow the text, it becomes clear (IMHO) that CSV
recommends, at the SHOULD level, accepting this as authentication.

> would feel I had a better understanding.

   But there's no reason to say that: it's implied in the SRV
query.

   We could, of course, quibble about whether the SHOULDs should
be MUSTs: I'm sure we're open to discussion about that. We tend
to be rather conservative in using "MUST".

> with, and even a part of, the CSV concept.

   Try though I might, I cannot read it that way.

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 25 Jun 2004 16:29:59 -0400

On Fri, Jun 25, 2004 at 10:45:52AM -0400, John Leslie wrote:
| ] CSV usually returns the list of IP addresses in the reply to the
| ] SRV query. The Host Name Authentication appendix gives advice on
| ] how to proceed if no list is returned.
| ] 
| ] If the list is returned and the actual IP address is in it, the
| ] receiving SMTP server SHOULD consider the EHLO domain name to be
| ] authenticated. Conversely, if the list is returned and the
| ] actual IP address is not in it, the assertion of the EHLO domain
| ] name SHOULD be considered incorrect, and an error returned.

OK, what happens if the list is not returned?

---

From: John Leslie <[email-masked]>
Date: Fri, 25 Jun 2004 17:08:13 -0400

Meng Weng Wong <[email-masked]> wrote:
>|] CSV usually returns the list of IP addresses in the reply to the
>|] SRV query. The Host Name Authentication appendix gives advice on
>|] how to proceed if no list is returned.
>|] 
>|] If the list is returned and the actual IP address is in it, the
>|] receiving SMTP server SHOULD consider the EHLO domain name to be
>|] authenticated. Conversely, if the list is returned and the
>|] actual IP address is not in it, the assertion of the EHLO domain
>|] name SHOULD be considered incorrect, and an error returned.
> 

   There are a number of possibilities:

1) There is no list; name is not authorized:
   Immediate reject, with error.

2) There is no list; name is authorized:
   An A)ddress query would be pointless. Some other authentication
   method needs to be used (a local option) or the "Authentication
   Failed" error needs to be returned.

   As noted in draft-ietf-marid-csv-csa, "Regardless of what is specified,
   this  receiving SMTP server may decide to refuse the client if their
   chosen accreditation service returns 'Unknown'." Our expectation is
   that without a reasonably good accreditation report, an error will
   be returned.

   Even with a good accreditation report, there would need to be some
   indication of _what_ alternative authentication mechanism to use:
   otherwise an error will need to be returned. Perhaps accreditation
   services will choose to recommend a method for domains which fall
   in this category: the information _that_ they do will be publicly
   available, after all.

   Please note that this case is equivalent to "we're not going to tell
   you what IP addresses might be used" -- thus trusting the EHLO name
   without authentication is really _not_ justified.

3) There is a list, but the DNS server didn't return it.
   This probably means the list is too long. Our expectation is that
   only a domain with good accreditation reports will be considered to
   deserve the time penalty for what will no doubt turn out to be a
   TCP DNS query; and any others will be refused with an "Authentication
   Failed" error.

   If the receiving SMTP server chooses to pursue this further, we
   would expect it to do a TCP DNS query and check for a match to the
   remote IP address of the existing SMTP connection. If found, the
   authentication (as well as the authorization) would be positive.

   Note, of course, that most of what I've said is a matter of local
policy, and IMHO is inappropriate to specify even at a SHOULD level.
However, if WG participants feel differently, I'm happy to write
some of this into the CSV documents.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Jun 2004 07:14:11 +0800

John,

>> with, and even a part of, the CSV concept.

JL>    Try though I might, I cannot read it that way.

Creative interpretation of one's writing is always helpful for
learning how to strengthen it against misunderstanding.

d/

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 25 Jun 2004 22:52:38 -0400

Dave,

I am currently looking at the CVS (and DNS and CSA) drafts.

Please correct any misunderstanding I may have.  I'm sure I did not cover
everything so I only have a few comments at this point.

The main one that jumps out is this Accreditation Concept.

The positive design I see is that you generalized it with a suggested
format.  This is good.  As with the reputation (RBL) designs currently in
place, it has a standard response concept allowing for a standard
implementation and more importantly allowing customers/operators to chose
their favorite RBL systems.

The negative is that acceditation server bureaus will be limited, at first,
and most likely exclusive to specific group of organizations or type of
systems.   In the overview, it says "chosen"

   3.  Query a chosen Accreditation Service for the EHLO domain name
       (see Domain Name Accreditation (DNA) [ID-Marid-CSVDNA])

Based on what I am seeing in the market place, infopreneurs are making these
fee based systems. As I read some of the policies at some of these sites,
lookups are free, but membership is fee based.  Not a problem, but unless
someone champions and puts up free DNA site, it seems the CSV idea will be
somewhat crippled which means it only be implemented as part of a total
suite of other transaction management technologies.  In short, there will
probably need to be more than a list of acceditation sites to lookup to make
it more effective for operators.

I guess, if we implemented CVS with some initial supportive DNA sites, we
would be able to help promote this sites and even encourage membership.
But I do see a need to offer more than one site, if only because one site is
"less" expensive than the other.

Currently we allow a unlimited list of RBL sites to lookup.  By default, out
of the box, the top 3 (most popular) are provided.

Which brings me to another related note:

RBL is one area of optimization I would like to improve upon as it
represents a high percentage of the total validation transaction time.   If
you agree a list of acceditation sites is needed, then this needs to be
optimized as well.

Thanks

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: John Leslie <[email-masked]>
Date: Sat, 26 Jun 2004 10:15:05 -0400

> I am currently looking at the CVS (and DNS and CSA) drafts.

   Thank you. More eyeballs always help.

> systems.

   I envision several different types of business _adding_ this service
at "no additional fee". The first type is the domain-name registrars.
They're already taking a per-domain-per year fee and already maintaining
DNS servers. This service will differentiate them; and the sufficiently
clueful ones will quickly see the business case to add it.

> Based on what I am seeing in the market place, infopreneurs are making
> these fee based systems.

   Indeed: Right-Hand-Side Whitelists are fee-based right now. Their
business model limits their ability to market to the masses, so their
fees are high. I don't hope to see fees disappear entirely, but I do
expect "free with boxtop" levels of pricing for low-volume, well-behaved
domains.

   (OTOH, the current business model, effectively charging postage for
any mass-email which bounces or generates complaints, will no doubt
continue for mass-emailers.)

> ... unless someone champions and puts up free DNA site, it seems the
> CSV idea will be somewhat crippled which means it only be implemented
> as part of a total suite of other transaction management technologies. 

   (I've already discussed the "free with boxtop" services which will
directly rate domains.)

   The other side of the accreditation service is what we described as
"proxy" accreditation lookup (which mysteriously seems to have disappeared
from Section 5 of [DNA], though a hint still remains in Section 3). The
idea is that the procedure in Section 5 might be performed directly by
sites receiving a small amount of email; but for sites with a significant
volume of incoming email, these would be delegated to a proxy and performed
in the same manner but with results cached and reported separately --
possibly by a single UDP DNS query to the proxy.

   Operating such a proxy would be as cheap as operating a web proxy;
and there would likely be the same informal (no money changing hands)
arrangements for sharing the workload.

   (In either case, distribution of lists recommending weights to be
given to different direct-accreditation services would be out-of-band
and not worth charging for.)

> In short, there will probably need to be more than a list of
> acceditation sites to lookup to make it more effective for operators.

   Agreed. The proxy accreditation-lookup process is needed.

> But I do see a need to offer more than one site, if only because one site
> is "less" expensive than the other.

   I am confident that at least half a dozen registrars would offer the
direct-rating service.

> represents a high percentage of the total validation transaction time.
> If you agree a list of acceditation sites is needed, then this needs to
> be optimized as well.

   Does the proxy-lookup service I described satisfy this concern?

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 26 Jun 2004 17:30:56 -0400

----- Original Message ----- 
From: "John Leslie" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-MXCOMP" <[email-masked]>; "Dave Crocker"
<[email-masked]>
Sent: Saturday, June 26, 2004 10:15 AM
Subject: Re: CVS specifics: Accreditation

>    I am confident that at least half a dozen registrars would offer the

Ok. One of the things I would have to work out when it comes to a "feature"
that has 3rd party or marketing tie-ins, is to see how it will be accepted
by the customer base.   We got bit many years ago when tieing in one the
early Online Payment systems via a 3rd party VisaNet clearing house.  A
combination of customer support disputes with the 3rd party vendor and their
eventual demise killed this "Online Subscriber/Billing/Reporting" add-on
product line. At this time, the number of payment services like this was
limited.  Anywa, I try to limit and also make sure any tie-ins offerings is
first done with popular and reputable companies, especially it is going to
be a "natural" new feature added.

>    Does the proxy-lookup service I described satisfy this concern?

Yes, I believe it will.

Thanks

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 26 Jun 2004 23:43:59 +0200

> Arnt needs to make some time to write up his proposal still. :)

Be happy to, unless it's a waste of time. The silence does not sound 
good to my ears. I have a feeling that people really want SPF 
(optionally with a cosmetic changes, e.g. C-ID) and won't consider 
anything else.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 27 Jun 2004 11:22:35 +0200

> (optionally with a cosmetic changes, e.g. C-ID) and won't consider 

But I'll see if I can get a draft in tomorrow.

Arnt