Subject: So here it is one year later...

From: "Gordon Fecyk" <[email-masked]>
Date: Thu, 27 Jan 2005 09:33:08 -0600

...since the first rumblings of talking about a working group, and there's
been no press on MARID since the breakup of said working group.  No press
from Microsoft, no press from the SPF crowd, no press from anyone.

And no instructions included on how to compile, install, or use what little
software is available out there.  Except for the few commercial (and
expensive) offerings by GFi.

What gives?  Has the whole world lost complete interest in stopping spam?  Is
spyware really the next big threat to the Internet that the US Congress is
looking at legislation for it but not bothering with spam anymore?

-- 
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: Douglas Otis <[email-masked]>
Date: Thu, 27 Jan 2005 09:38:11 -0800

> looking at legislation for it but not bothering with spam anymore?

There is a signature based effort ongoing with Yahoo and Cisco.

http://www.mipassoc.org/mass/

One hopes details of merging strategies is being discussed, as it does
not appear to be happening much on the mailing list.  The technology
looks very promising from the perspective of protecting people.
(Assuming there is a means to revoke authorization granted by way of the
signature.)   

http://www.mipassoc.org/clear/

Work is still happening and a new draft is about to be released.  This
approach is compatible with mass efforts, but offers a means to protect
networks with similar name based instrument.

The pressure is still very much present.  The entire effort is about
improving security by way of authentication.  The lack of security
remains the principle enabler.  Security places focus upon the
client/server administrator, which is the entity authenticated by way of
efforts in MASS and CLEAR.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 27 Jan 2005 20:37:08 +0100

Gordon Fecyk wrote:

> no press from the SPF crowd

The "SPF crowd" has a position on Sender-ID (Dec 2004):
<http://www.OpenSPF.org/>

A council was elected (December 2004): <http://spf.mehnle.net/>

An updated draft was published (January 2005):
<http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt>

SpamCop recommends SPF and / or domain keys (yesterday):
<http://www.spamcop.net/fom-serve/cache/329.html>

Other relatively new activities include:
<http://www.ietf.org/internet-drafts/draft-crocker-email-arch-02.txt>
<http://www.ietf.org/internet-drafts/draft-housley-mass-sec-review-00.txt>
<http://www.ietf.org/internet-drafts/draft-irtf-asrg-dnsbl-01.txt>
<http://www.ietf.org/internet-drafts/draft-stumpf-dns-mtamark-03.txt>

        Bye, Frank (some remarks about RfC 3865 censored)

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jan 2005 16:28:01 -0800

> > no press from the SPF crowd

pobox.com still has the slogan:
  Sender Policy Framework, an essential part of Sender ID.

And although the link has been modified, it continues to indicate the
current SPF draft is:

http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt

> The "SPF crowd" has a position on Sender-ID (Dec 2004):

Quote from this faction:

"Many SPF developers and users consider that Microsoft's SenderID
proposal is technically unsound and undermines the progress already
begun by SPF. SPF development and deployment predate Microsoft's entry
into the field and have achieved significant success to date. SenderID,
in its most recent form, appears likely to interfere with the correct
function and deployment of SPF."
...

"Where SenderID breaks the function of existing v=spf1 records, domain
owners will only learn of it when legitimate mail is not delivered.  SPF
record publishers made their records public with the expectation that
they would be used with the SPF algorithm.  SenderID puts those records
to a different, possibly incompatible use, without any consent from the
publishers."

Agreed; applying a record against different algorithms than that
intended when published is inherently deleterious, even though SPF still
prevents delivery of mail from forwarding and some list servers. : (

> <http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt>

Once again the algorithm changes and still this draft uses the same
labels and record identifiers?  Classic.

Endorsements from those that block all bounce traffic are not likely
concerned about mail lost as a result of forwarding or being from
various list servers, so it would seem.  Based upon these comments,
SPF/Sender-ID reduces mail integrity in the bargain.  

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Thu, 27 Jan 2005 20:47:53 -0500 (EST)

> from Microsoft, no press from the SPF crowd, no press from anyone.

The working group broke up because of unresolvable technical problems.

> expensive) offerings by GFi.

If you aren't a developer of SPF, probably you shouldn't be using SPF.

> looking at legislation for it but not bothering with spam anymore?

No, the world has just realized that SPF doesn't work, and won't stop
spam, nor stop forgery. In its present form, SPF does nothing except
create more opportunities for email abuse, and promotes spam and email
abuse.  Most people are interested in things that work. Fewer are
interested in making things worse.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: <[email-masked]>
Date: Thu, 27 Jan 2005 21:07:43 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dean Anderson
> Sent: Thursday, January 27, 2005 8:48 PM
> To: Gordon Fecyk
> Cc: IETF MXCOMP (E-mail)
> Subject: Re: So here it is one year later...
>
>
>

Get specific Dean, the unresolvable technical issues was the the PRA is broken, NOT SPF.  So it is SenderID's PRA
component not its SPF component that caused the technical failure.

And the senderid venture was doomed to failure anyway because of the M$ IPR crap.

> If you aren't a developer of SPF, probably you shouldn't be using SPF.

Wrong again.  And the proof is that there are many domains that implement SPF, successfully.

> spam, nor stop forgery.

SPF never pretended to stop spam.  It does prevent forgery, it does not prevent phishing, but then no technical solution
will ever solve phishing as long as MUA's like Outlook show "pretty names" for everything, suppressing the try
underlying identities of everything from email addresses to attachment types.

> In its present form, SPF does nothing except

I cannot see how you come to that conclusion, (especially not on your lack of facts you presented).  It does however
well illustrate that there was/is an effort to scuttle SPF.  Mostly by those with alternative products.  Which is
interesting, because if SPF was not a threat to the alternative products, they wouldn't try to scuttle SPF.

Terry Fielder

---

From: Dean Anderson <[email-masked]>
Date: Thu, 27 Jan 2005 22:19:36 -0500 (EST)

On Thu, 27 Jan 2005 [email-masked] wrote:

> Get specific Dean, the unresolvable technical issues was the the PRA is
> broken, NOT SPF.  So it is SenderID's PRA component not its SPF
> component that caused the technical failure.

That was _a_ problem. It wasn't the only problem.

> And the senderid venture was doomed to failure anyway because of the M$ IPR crap.

I agree the IPR crap was a bad thing. (I am the president of the LPF,
after all).  However, I don't think it doomed standardization to failure.
The IETF has standardized RFCs with patented algorithms before.  People
made an informed choice, and decided that anti-spam technology is
something that needs to be pervasive, free, and unencumbered.  This has to
be a major concern for the privateers interested "making a fortune in
anti-spam"

> Wrong again.  And the proof is that there are many domains that implement SPF, successfully.

Most them are spammers.

> SPF never pretended to stop spam. 

That isn't what Meng Weng said it Linux World. He said it would end spam.  
There are many other similar articles.  Indeed, Microsoft also announced
it would "end spam".

>  It does prevent forgery,

Demonstrably, it does not. Excluding DNS spoofing, which is also trivial,
one only needs an account at the same ISP as the forgery target.  Many
ISPs will not use SPF because of the DOS vulnerabilities, and unless
everyone use SPF, it will not stop forgery, even given an assumption that
every domain has a unique IP (which isn't a realistic assumption)

>  it does not prevent phishing, but then no technical solution will ever
> solve phishing as long as MUA's like Outlook show "pretty names" for
> everything, suppressing the try underlying identities of everything from
> email addresses to attachment types.

I didn't hear anyone say it would prevent phishing.  Phishing is only 
tangentially related to forgery, anyway. Even if you could stop forgery, 
it would not alter phishing.

> > In its present form, SPF does nothing except create more opportunities
> > for email abuse, and promotes spam and email abuse.  Most people are
> > interested in things that work. Fewer are interested in making things
> > worse.
> 
> I cannot see how you come to that conclusion, (especially not on your
> lack of facts you presented).  

Facts were already presented. The working group dissolved.  Look at the
IETF-MXCOMP archives. About 15 different critical, insurmountable problems
were listed by me and others.

> It does however well illustrate that there was/is an effort to scuttle
> SPF.  Mostly by those with alternative products.  Which is interesting,
> because if SPF was not a threat to the alternative products, they
> wouldn't try to scuttle SPF.

None of the people speaking about SPF problems have alternative products.  
Some of the people in favor of SPF however have significant investments in
products, or have interests in its other properties, such as preventing
email outsourcing by binding together email and access.  AOL, MSN, etc for
example, have interests in the latter.

The SPF steamroller attempts to move on anyway.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 28 Jan 2005 04:20:50 +0100

>   Sender Policy Framework, an essential part of Sender ID.

Yes, the pobox site is not exactly up to date, that's AFAIK on
the "todo" list of the new council.  The new SPF draft is more
important.

> it continues to indicate the current SPF draft is:

Meng is one of the 5 SPF council members, they all agree that
the new draft is _the_ draft.  He's also one of the 2 authors.

Mark had no time for this project after draft-lentczner-spf-00,
otherwise there'd be probably three authors of the new draft,
if that's allowed by the IETF and supported by xml2rfc.

 [Sender-ID position]
> Quote from this faction:

The majority fraction, if you insist on these political terms.
<http://OpenSPF.org/cgi-bin/openspf_pledge.cgi> counts 129
signatures.  The SPF council was elected by 161 voters.  Not
exactly the same constituency, but roughly the same group of
people.  Finding a better text supported by almost all SPF
"fans" is (or was) also on the "todo" list of the new council.

> applying a record against different algorithms than that
> intended when published is inherently deleterious

Indeed.

> Once again the algorithm changes and still this draft uses
> the same labels and record identifiers?  Classic.

This "new" draft is technically nearer to the last pre-MARID
"old" draft than draft-lentczner-spf-00 was.  The latter was a
rather quick hack salvaging all syntax improvements found here
(= mxcomp) after MARID was killed and the old draft expired.

The "new" draft kept these syntactical improvements, removed
some oddities with the handling of errors, and added all things
from the old draft forgotten in draft-lentczer-spf-00.  There
are almost no semantical differences between "old" and "new".

Some of the minor differences between lentczner and new / old
were simply errors, e.g. lentczer would FAIL for a MAIL FROM
domain literal.  While that might be seen as a feature it was a
case of "receiver policy" and not "sender policy", and the new
draft fixed it (back to the state of the old draft).

Only side effects of the MARID disaster, no SPF problem, no new
algorithm, no differences for existing policies.  Only a better
error handling and more restrictive limits for DNS queries, no
substantial changes.
                     Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jan 2005 23:11:05 -0800

> (= mxcomp) after MARID was killed and the old draft expired.

This draft is attempting to make significant algorithmic changes to the
initial draft, as well as how these records are used.

Some examples:

   SPF clients MAY check the "HELO" identity by calling the check_host()
   function (Section 4) with the "HELO" identity as the <sender>.  If
   the HELO test returns a "fail", the overall result for the SMTP
   session is "fail", and there is no need to test the "MAIL FROM"
   identity.

A test against HELO that goes from unknown, to not tested, to fail?
This a change in algorithm, as is the hunt for alternative records,
where a pass may not be based upon address compliance.  One wonders how
macros are applied when the same check_host routine is recycled. 

   An SPF record published at the zone cut for the domain will be used
   as a default for all subdomains within the zone (See Section 4.5.)
   Domain owners SHOULD publish SPF records for hosts used for the HELO
   and MAIL FROM identities instead of using the zone cut default
   because the fallback requires additional DNS lookups.  The zone cut
   default does reduce the need to publish SPF records for non-email
   related hosts, such as www.example.com.

Again, another change in algorithm.  This also means TXT RR placed at
the zone apex may now be problematic as how it becomes applied and to
which identity.  

   If no matching records are returned for the <domain;>, the SPF client
   MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat
   the above steps.  The <domain>'s zone origin is then searched for SPF
   records.  If an SPF record is found at the zone origin, the <domain>
   is set to the zone origin as if a "redirect" modifier was executed.

   If no matching records are returned for either search, an SPF client
   MUST assume that the domain makes no SPF declarations.  SPF
   processing MUST abort and return "None".

Yet again another change in algorithm isn't it?

   This mechanism matches if <ip> is one of the MX hosts for a domain
   name.

   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]

   check_host() first performs an MX lookup on the <target-name>.  Then
   it performs an address lookup on each MX name returned.  The <ip> is
   compared to each returned IP address.  To prevent DoS attacks, a
   limit of 10 MX names MUST be enforced (see Section 10).  If any
   address matches, the mechanism matches.

A limit change is an algorithmic change that could not be possibly
foreseen by earlier publishers.  Who is responsible when their mail goes
missing?

   Note regarding implicit MXes: If the <target-name> has no MX records,
   check_host() MUST NOT pretend the target is its single MX, and MUST
   NOT default to an A lookup on the <target-name> directly.  This
   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821]
   Section 5.  If such behavior is desired, the publisher should specify
   an "a" directive.

Would this be yet another algorithm change?

  In pseudocode:

   sending-domain_names := ptr_lookup(sending-host_IP);
   if more than 10 sending-domain_names are found, use at most 10.
   for each name in (sending-domain_names) {
     IP_addresses := a_lookup(name);
     if the sending-domain_IP is one of the IP_addresses {
       validated-sending-domain_names += name;
     }
   }

Yet another change to the algorithm that introduces a new limit.

   Pseudocode:

   for each name in (validated-sending-domain_names) {
     if name ends in <domain-spec>, return match.
     if name is <domain-spec>, return match.
   }
   return no-match.

   This mechanism matches if the <target-name> is either an ancestor of
   a validated domain name, or if the <target-name> and a validated
   domain name are the same.  For example: "mail.example.com" is within
   the domain "example.com", but "mail.bad-example.com" is not.

   Note: Use of this mechanism is discouraged because it is slow, is not
   as reliable as other mechanisms in cases of DNS errors and it places
   a large burden on the arpa name servers.  If used, proper PTR records
   must be in place for the domain's hosts and the "ptr" mechanism
   should be one of the last mechanisms checked.

One wonders how this mechanism is to be discouraged?
 
   SPF implementations MUST limit the number of mechanism that do DNS
   lookups to at most 10, if this number is exceeded, a PermError MUST
   be returned.  The mechanisms that count against this limit are
   "include", "a", "mx", "ptr", "exists" and the "redirect" modifier.
   The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and
   therefore do not count against this limit.  The "exp" modifier
   requires a DNS lookup, but it is not counted as it is used only in
   the case of errors.

   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
   checked.

I would also describe this as an algorithmic change that could not have
been anticipated by the publishers.  And the following regarding
forwarding:

   There are several possible ways that this authorization failure can
   be ameliorated.  If the owner of the external mailbox wishes to trust
   the forwarding service, they can direct the external mailbox's MTA to
   skip such tests when the client host belongs to the forwarding
   service.  Tests against some other identity may also be used to
   override the test against the "MAIL FROM" identity.

   For larger domains, it may not be possible to have a complete or
   accurate list of forwarding services used by the owners of the
   domain's mailboxes.  In such cases, white lists of generally
   recognized forwarding services could be employed.

Some other Identity?  Generally recognized forwarding services?  Would
this open the door for abusing the typical alma mater?  This is a mess.

This draft at long last recognizes wildcard labels are a problem.  Why
not also recognize a need to _change_ revisions when algorithms change
and the need for a standardized prefix rather than a record tag?  These
are rather significant changes being made, why suggest otherwise?

-Doug

---

From: [email-masked]
Date: Fri, 28 Jan 2005 12:44:03 +0100

> > Wrong again.  And the proof is that there are many domains that implement SPF, successfully.

May we see some proof of that please? And with proof i don't mean that
report that is by now almost a year old and which was found to be
incorrect a while ago. 

I don't have proof of the opposite, but i do seem to experience that
many non-spammers are implementing spf (i'm saying this based on the
requests the spf 'tech support team' gets in and activity on spf mailing
lists).

Koen

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

---

From: [email-masked]
Date: Fri, 28 Jan 2005 12:44:03 +0100

Koen

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Jan 2005 11:34:39 -0500 (EST)

I don't do the usage tracking.  It was reported on the mxcomp and other
lists. I've never heard anyone dispute it before. I'd have to dig through
my mail archives to find the reports, but my recollection is that they
came from people doing the usage tracking.

While I'm not disputing that there are non-spammers using SPF, the
spammers rushed to it for fairly obvious reasons. Anything that even
suggests that mail might be accepted or subjected to less checks is
definitely a big win for spammers.

		--Dean

---

From: [email-masked] (Justin Mason)
Date: Fri, 28 Jan 2005 10:01:19 -0800

> report that is by now almost a year old and which was found to be

FWIW, here's the results of a check of 54725 spams and 6680 nonspam mails,
from SpamAssassin's weekly mass-check of network rules (at
http://www.pathname.com/~corpus/NET.age ).

All these messages were received less than 1 month ago, and are taken from
5 people's hand-classified corpora.

  SPF records passing HELO strings: 4.98% of spam, 13.29% of ham
  SPF records passing the MAIL FROM: 3.72% spam, 18.90% of ham

So it certainly looks like that statement is untrue.

- --j.

---

From: wayne <[email-masked]>
Date: Fri, 28 Jan 2005 13:20:51 -0600

The MARID list has become a cesspool of misinformation and trolls.
For that reason, I have not been posting to it and I would encourage
others to ignore the "information" posted here.  The following post by
Doug Otis is an prime example of just how bad most posts here are.

> initial draft, as well as how these records are used.

Discussions about the SPF specification are best discussed on the
SPF-discuss mailing list.

> macros are applied when the same check_host routine is recycled. 

This is not an example of changing semantics and/or algorithms.  As
pointed out by Frank, this is consistent with the pre-MARID
specification of SPF.  The problem is not that draft-schlitt-spf-00
changed things back, but that the IETF, via the MARID WG, allowed it
to change in the first place.

> the zone apex may now be problematic as how it becomes applied and to

This is not an example of changing semantics and/or algorithms.  As
pointed out by Frank, this is consistent with the pre-MARID
specification of SPF.  The problem is not that draft-schlitt-spf-00
changed things back, but that the IETF, via the MARID WG, allowed it
to change in the first place.

> Yet again another change in algorithm isn't it?

This is not an example of changing semantics and/or algorithms.  As
pointed out by Frank, this is consistent with the pre-MARID
specification of SPF.  The problem is not that draft-schlitt-spf-00
changed things back, but that the IETF, via the MARID WG, allowed it
to change in the first place.

> foreseen by earlier publishers.  Who is responsible when their mail goes

While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice.  As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit.  This change only effects abusers and
misconfigured systems.

> Would this be yet another algorithm change?

No.  This has *always* been the case.

> Yet another change to the algorithm that introduces a new limit.

While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice.  As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit.  This change only effects abusers and
misconfigured systems.

> One wonders how this mechanism is to be discouraged?

By saying, in the spec "this mechanism is discouraged" and by having
the various SPF wizards not generate it.

> been anticipated by the publishers.

While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice.  As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit.  This change only effects abusers and
misconfigured systems.

>                                      And the following regarding
> forwarding:
>

As noted in Section 9, this is is non-normative.  If you don't agree
with what is said, you are free to do anything you want.  This is just
for your information.

> are rather significant changes being made, why suggest otherwise?

The section on wildcards was added as part of the MARID process and
remained in the draft-schlitt-spf-00 version because it is useful.
The changes to the algorithms that were added as part of the MARID
process have been removed.  Changes to the algorigtms from the
pre-MARID SPF specs have all been implemented by at least one system
and have been checked, via wide surveys, that they do not conflict
the install base of legitimate SPF records.

I find it very amusing that you are now complaining about the process
limits being a change, since you have long complained about the lack
of process limits in previous versions of the SPF spec.  

-wayne

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Jan 2005 14:56:46 -0500 (EST)

> So it certainly looks like that statement is untrue.

Err, no:

OVERALL%   SPAM%     HAM%     S/O    RANK   SCORE  NAME:0-1
OVERALL%   SPAM%     HAM%     S/O    RANK   SCORE  NAME:1-3
OVERALL%   SPAM%     HAM%     S/O    RANK   SCORE  NAME:3-6

  5.377   3.7259  18.9072    0.165   0.23   -0.00  SPF_PASS:0-1
  1.361   0.9087   3.3508    0.213   0.25   -0.00  SPF_PASS:1-3
  1.749   0.5116  18.4304    0.027   0.34   -0.00  SPF_PASS:3-6

As you see, spam + ham does not add up to overall.  Its not clear what
these statistics mean, nor how they were calculated.  But your
interpretation is clearly either wrong or at least not supported by the
page.

FYI, this is the original post:

---------- Forwarded message ----------
Date: Thu, 9 Sep 2004 15:18:42 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: SPF abused by spammers

Justin Murdock posted this link on the qmail list:
    http://news.bbc.co.uk/1/hi/technology/3631350.stm
    "CipherTrust [...] found that 34% more spam is passing SPF checks than
    legitimate e-mail."

        \Maex

--
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 
32356-299
"The security, stability and reliability of a computer system is 
reciprocally
 proportional to the amount of vacuity between the ears of the admin"

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Jan 2005 15:10:57 -0500 (EST)

> interpretation is clearly either wrong or at least not supported by the

Sorry to reply to my own post, but there is another point I forgot: when
dealing with a very sample from a very small domain, that deals with a
limited part of the internet, E.G. a domain with relatively few people who
develop SPF, and who therefore exchange disproportionately more mail with
other SPF users, then their email statistics on SPF usage will also be
skewed.  In other words, this is not a random sample.

One needs to get better sample from someplace that doesn't particularly 
cater to SPF email users, and interacts more broadly with the internet.

		--Dean

---

From: [email-masked] (Justin Mason)
Date: Fri, 28 Jan 2005 12:17:07 -0800

> interpretation is clearly either wrong or at least not supported by the

Actually, you're wrong there. This is SpamAssassin's "hit-frequencies"
tool output.  Those are percentages, not message counts, so simply summing
SPAM%+HAM% will not add up to OVERALL%.

Here's a quick walk through the pertinent parts. (I'm discarding the 1-3
and 3-6 month ranges -- those are old mails so that data isn't very useful
for network tests -- and just concentrate on the 0-1 month range.)

OVERALL%   SPAM%     HAM%     S/O    RANK   SCORE  NAME:0-1
  61405    54725     6680    0.891   0.00    0.00  (all messages):0-1

This means that there were 61405 messages mass-checked in total,
with 54725 spams, and 6680 "hams" (non-spam messages).

looking at the SPAM% and HAM% columns, that means that 3.7259% of the spams
checked had SPF_PASS, and 18.9072% of the hams. that means

  ((3.7259 / 100) * 54725) = 2038.998775

I'd suspect that rounding error means that 2039 spam messages passed the
SPF check, so round to 2039.

  ((18.9072 / 100) * 6680) = 1263.00096

and 1263 hams passed SPF.  Total those, and you get 3302 messages
from the overall corpus passing SPF; to express that as a percentage
of the total overall corpus, in other words "OVERALL%", you compute
(3302 / 61405) * 100 = 5.377.

If you have any more questions on the hit-frequencies format, I'll
be happy to fill you in -- I wrote the tool in question ;)

>     "CipherTrust [...] found that 34% more spam is passing SPF checks than

Sure.  But this was guaranteed to change over time, and vary depending on
corpus composition.  It's pretty radically different now, from where I and
the other SpamAssassin corpus contributors are viewing it.

- --j.

---

From: [email-masked] (Justin Mason)
Date: Fri, 28 Jan 2005 12:21:53 -0800

> cater to SPF email users, and interacts more broadly with the internet.

FWIW, those figures come from contributors at 5 different sites.  It's not
just one domain.  Some are not even spam filter developers. ;)

Ciphertrust's figures are also biased -- their customers in turn will be a
certain cross-section of email users, rather than "truly representative"
of the internet at large.

I don't think anyone has yet come up with a way to get a hand-classified
sample that can reflect everyone's use of email...

- --j.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Jan 2005 16:07:25 -0500 (EST)

> checked had SPF_PASS, and 18.9072% of the hams. that means

Ah. That certainly explains the computation. Thanks.  But the particular
stats are from only 4 people, who, being spamassassin contributors,
probably have more SPF-using friends than most people.

> the other SpamAssassin corpus contributors are viewing it.

Everything changes over time.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Jan 2005 13:28:47 -0800

> to change in the first place.

Here is a quote for the pre-MARID draft regarding the specified
processing algorithm limits.

6.2 Processing Limits
   
   During processing, an SPF client may perform additional SPF
   subqueries due to the Include mechanism and the Redirect modifier.

   SPF clients must be prepared to handle records that are set up
   incorrectly or maliciously.  SPF clients MUST perform loop detection,
   limit SPF recursion, or both.  If an SPF client chooses to limit
   recursion depth, then at least a total of 20 redirects and includes
   SHOULD be supported.  (This number should be enough for even the most
   complicated configurations.)

   If a loop is detected, or if more than 20 subqueries are triggered,
   an SPF client MAY abort the lookup and return the result "unknown".

   Regular non-recursive lookups due to mechanisms like "a" and "mx" or
   due to modifiers like "exp" do not count toward this total

This new draft is NOT a compatible change.  It should also be noted this
pre-MARID process could entail orders of magnitude more lookups.  

> to change in the first place.

You should review which records would be used to evaluate the EHLO/HELO.
And yet another quote from Pre-MARID.

     The <responsible-sender> comes from the domain name of the "MAIL
     FROM" envelope sender.  When the envelope sender has no domain, a
     client MUST use the HELO domain instead.  If the HELO argument does
     not provide an FQDN, SPF processing terminates with "unknown".

Now the record applied against the EHLO/HELO identity could be found at
the zone apex AND at the EHLO/HELO.  The results of this check have also
changed and is not consistent.   

> to change in the first place.

This changes the pre-MARID, mid-MARID, and post-MARID algorithms!  The
publisher can NOT be sure which record will be applied against their
HELO.  It goes from virtually a don't care to a failure.  The fall-back,
as it is called, will also likely conflict with records at the zone
apex.  Complain about mail lost as a result of the algorithms applied by
Sender-ID, but show some compunction regarding the effect of these
changes.  All this could be avoided by changing the record identifier.

> have come close to this limit.  This change only effects abusers and

I guess those that are affected are therefore illegitimate?  To publish,
discover the limits in the code being used?  Code that did not comply to
some or any draft?  When are the next changes to the algorithm going to
be made?  How can a disruption be avoided when there is NO MEANS to
introduce a new version without removal of the prior?

> > And the following regarding forwarding:
> >

In essence, don't expect forwarding to function.  May I comment that
this is disruptive and a mess without this comment being called
misinformation or myself as being a troll for taking time to read the
drafts presented on this reflector.

Regarding the debate about who uses SPF, spammers register more domains
than legitimate users, but at any instant, individual spammer domains
will not likely be used once consistently blocked by filters.  Looking
at the numbers from the perspective of nominal traffic, versus published
domains with a "bad" record, these ratios _should_ be different.

> of process limits in previous versions of the SPF spec.

I have not complained about a reduction in the limits, but rather a
change that imperils the publishers.  I was complaining this draft still
does not allow a reasonable method to change processing algorithms
without potentially creating sizeable disruption.  This is due, in no
small part, from a false expectation that a wildcard label provided some
utility and is the reason for usurping the use of the TXT RR.  This was
wrong and remains wrong.  Using a prefix on the record remains a viable
method to ensure SPF offers less disruption to users as well as other
protocols.  If I was right once...

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Jan 2005 17:25:47 -0500 (EST)

BTW, I'd say that 38% of the SPF use was ham, and 62% was spam.
    1263 ham / 3302  = ~38%
    2039 spam / 3302 = ~62%

So, 24% versus the 34% in September.  Either slightly better than
September, or perhaps the sample is too small and skewed to be useful. Or 
both.  Its still better to block whenever you see SPF.

Still, I'd think the 3.7% of total spam using SPF is still fairly
significant, and probably reflects the relative proportion of genuine
commercial spam to non-commercial spam.  It would be interesting to know,
of those spams that pass SPF, how many are CAN-SPAM compliant?  How many
of the non-SPF spams were CAN-SPAM compliant?  I'd conjecture a strong
correlation.

		--Dean

---

From: [email-masked] (Justin Mason)
Date: Fri, 28 Jan 2005 15:14:27 -0800

> both.  Its still better to block whenever you see SPF.

hmm!  not sure if that's a good assumption -- it's very much dependent on
the comparative ham:spam ratio a domain would see. This set of corpora is
heavily skewed towards receiving more spam than ham; 87.8% of our messages
being spam.

Let's say those corpora were only receiving a third as much spam as they
currently do, possibly because they were younger email addresses or
whatever.  In that case, we'd see 1263 ham, 680 spam (2039/3 ~= 680), in
which case the proportion of SPF-using-spam vs SPF-using-ham would be on
its head: 34% being spam, 65% being ham.

What I'm trying to illustrate here is that it's important to compare
figures using figures that compensate for the comparative ham:spam ratio,
because that varies wildly.   Hence, comparing (SPF-bearing-ham / all-ham)
to (SPF-bearing-spam / all-spam) is safer than comparing the message
counts of SPF-bearing-ham and SPF-bearing-spam directly.

> of the non-SPF spams were CAN-SPAM compliant?  I'd conjecture a strong

now that's something I don't have time to get into, CAN-SPAM compliance
not being something that's easy to automate checking for (more's the
pity).

- --j.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 28 Jan 2005 19:04:11 -0500

On Jan 28, 2005, at 2:20 PM, wayne wrote:

> The problem is not that draft-schlitt-spf-00

This statement strikes me as particularly offensive.  If the intent was 
to have the IETF simply rubber-stamp SPF, making that clear up front 
would have saved us all a lot of time.

-andy

---

From: wayne <[email-masked]>
Date: Fri, 28 Jan 2005 23:32:54 -0600

In <[email-masked]> Andrew Newton <[email-masked]> writes:

> This statement strikes me as particularly offensive.  If the intent
> was to have the IETF simply rubber-stamp SPF, making that clear up
> front would have saved us all a lot of time.

MARID never adopted/considered SPF.  When, at the interim meeting,
MARID assigned authors to create proposals, it was to create SenderID
with the use of the PRA.  At that point, all compatibility with
SPF-classic was basically thrown out the window.  Eventually, enough
people decided there were enough incompatibilities that it was decided
at the ietf-60(?) session that SenderID should use new records.  For
some strange reason, the IETF is now considering the SenderID drafts
that still use the same records.  Go figure.

I know of no one who asked or assumed that the IETF would rubber-stamp
SPF.  I did say, several times, that adopting an existing system would
be a much better idea than trying to create something from scratch.
Both DMP and RMX, for example, would have been a better choices than
SenderID because both had more testing done on them.  If MARID had
chosen to adopt either DMP or RMX, that would have been fine with me.

Now, back to message I was replying to, Doug talked about the
SPF-classic spec of draft-lentczner-spf-00.  Like all SPF specs, it
was never adopted by MARID.  The problem here is that Mark took the
drafts developed during MARID and tried to back-port them to be
SPF-classic drafts.  The advantage of doing this is that a great deal
of wordsmithing, in particular work done by Mark, had gone into the
MARID drafts and they were much better language wise.  Unfortunately,
they had the many semantic/algorithmic changes that the MARID group
made during the development of SenderID.

draft-schlitt-spf-classic-00 is an attempt to use the much better
language of the MARID drafts, but to restore functionality to match
what the install base of SPF systems is.  This draft also has removed
several features that are unused in the wild, and has more strict
error handling/checking added.

So, not rubber-stamping SPF wasn't a problem.  Creating a new spec
that changed the semantics of SPF records was.

-wayne

---

From: wayne <[email-masked]>
Date: Sat, 29 Jan 2005 00:05:31 -0600

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> [big snip]

>    [stuff from, I'm pretty sure, spf-draft-200406 snipped]
>

I disagree.  In practice, at least, this is a very compatible change
because almost no one runs into the limits.

> changed and is not consistent.   

Yes, the zone cut stuff, while in spf-draft-200406, is certainly the
thing that I'm most willing to remove from
draft-schlitt-spf-classic-00.  It has some nice properties, but it has
some problems also.

> [another big snip]
>
> This changes the pre-MARID, mid-MARID, and post-MARID algorithms!

I'm not sure what you mean by this.  The zonecut stuff is in
spf-draft-200406. 

>> > [mx processing limit stuff snipped]
>> 

"A difference that makes no difference is no difference" -- spock

Yes, in theory, there are incompatible changes, in practice there
aren't.  

> [yet another big snip]
>
> In essence, don't expect forwarding to function.

Yes, SPF and traditional alias/.forward type forwarding don't work
well together.  The MAPS DUL list and all end users being able to have
their own MTA don't work well together.  DomainKeys and mailing lists
don't work well together.  NAT and many games/vpn/etc. don't work well
together.  There are *lots* of changes that have happened that cause
other problems.

That section of the SPF-classic spec explains the situation.  As an
email receiver, if you don't like it, you don't have to check SPF
records, check the MAPS DUL, check domain keys, or use NAT.  Your box,
your rules.

> protocols.  If I was right once...

Lots of stuff here that I guess we will just have to agree to disagree
on.  I don't agree with all the choices that were made with SPF, some
due to hind sight, some due to differening opinions.  It still remains
far and away the most deployed designated sender system out there.  It
doesn't appear that we make any fatal mistakes.  IMHO, some of the
stuff you stuggest would be "better" would, actually, have been a
fatal mistake.

-wayne

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 29 Jan 2005 12:15:15 +0100

Andrew Newton wrote:

> If the intent was to have the IETF simply rubber-stamp SPF,
> making that clear up front would have saved us all a lot of
> time.

My intention was always to get a RfC for LMAP (with SPF as the
most promising candidate at this time, but also including CSV),
i.e. to find and fix all bugs and oddities in these concepts.

You never allowed this to happen here.  You always pressed for
2822 and the IMHO broken Sender-ID concept, and when that failed
you let the A-D close this WG without prior consultation.
-- 
<http://purl.net/xyzzy/home/test/MARID.appeal.txt>

---

From: Andrew Newton <[email-masked]>
Date: Sat, 29 Jan 2005 11:12:07 -0500

On Jan 29, 2005, at 12:32 AM, wayne wrote:
> For

If by same records, you mean anything TXT then I'm afraid you will have 
to live with that... and any other new uses for TXT that come along.

> that changed the semantics of SPF records was.

But I suppose you mean the v=spf1 records and agree that you have a 
point.... which is not what I thought you were saying.  Sorry for 
jumping to conclusions.

-andy

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Jan 2005 12:12:45 -0500

> you let the A-D close this WG without prior consultation.

  The chairs asked for consensus from the group.  The consensus was to
look at 2822 and Sender-Id.

  Once that happened, further consensus did not occur.

  Alan DeKok.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 29 Jan 2005 10:17:34 -0800 (PST)

> look at 2822 and Sender-Id.

That is not exactly true. Prior to May interim meeting there was general 
consensus that we're going to look and work with RFC2821 identities and
RFC2821 MAIL FROM in particular.

On that meeting it was announced that Meng & Microsoft agreed to merge
into what was essentially CallerID (xml dns record, rfc2822 identities,
pra), but its syntax would be closer to supporting spf with clients
also support spf1 records. It was presented to the group in the way
that left no serious alternative except CSV for checking HELO which 
was also worked by the WG.

There were people on that meeting who did not like the kind of merger
between spf and callerid that was announced but we were willing to at
least try to see what this would turn out into especially since IETF
was willing to put its hand into making it work. Within month however
it became clear that XML was not the way to go (not for DNS TXT record
at the very least) and within another month it was also seen that 
RFC2822 identities is really not the right thing to do per-hop 
authentication of incoming mail server by ip.

Besides that Microsoft intentions and its willingness to work every party
that had interest in MARID was seriously in question and it was seen
that Microsoft and its PRA was more of a burden then help.

So by IETF60 there was really no longer consensus, but parties most
interested in SID were still trying hard to push it through. The
result was not unexpected that when actual poll on consensus (last-call 
on sid documents) was done it fall miserably.

The correct thing to do would have been to re-asses the situation and check 
for consensus again to see if any alternative solution would be have 
consensus to go forward and would not have the same technical problems. 
But it was also from the start felt by many that IETF was under a lot of 
pressure from corporate interests to standardize CallerID/SenderID and 
that MARID was nothing but a show to slightly polish it before putting 
ietf stamp on it and that that abandoning in favor of another alternative 
would be seen as unacceptable to very very large corporate parties who 
would take it as a sign that they should not come and work with IETF again.

So unfortunately, instead of choosing to clearly disregard what was
technically unacceptable proposal that does not have consensus of the 
community,IETF decided to just disband the WG and make decisions about 
the same proposal privately at the level of IESG and select group of
individuals who we don't even know - DEA Directorate had been formed but 
its membership seems to be kept private even though Ted Hardie said here
in message http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html
that it will be made public. I'm hoping that Ted Hardie and IESG will 
follow through on its promise and that there is no official information
on IETF pages about DEA is just an oversight due to very overworked staff
who had not yet had time to create appropriate information page.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: wayne <[email-masked]>
Date: Sat, 29 Jan 2005 12:54:09 -0600

>   Once that happened, further consensus did not occur.

No.

The chairs/AD asked for consensus from the group.  The consensus was to
look at the 2821 identities first and then look at the 2822
identities.  The charter promised that once this decision was reached,
that all further discussions on other identities would be ruled out of
scope.

This did not happen.

The chairs/AD, at the interim meeting, decided to ignore this and
switched to 2822 with SenderID and the PRA as the only option.  This
complete change of direction was never confirmed on the mailing list,
despite the IETF rules on the subject.

(Ok, CSV was left on the table, to be considered after SenderID.
That, however, completely ignored SPF's 2821.HELO checking, and all
forms of 2821.MAILFROM checking.)

MARID showed just how much more important political considerations are
in making decisions than technical considerations.  The end run that
the IETF is making, right now, around the technical problems with
SenderID is just another great example.  The SenderID I-Ds have now
been sent off to a secret directorate for review, with no place to
make public comments.  It is not even clear if the IESG will allow an
IETF wide last-call for the SenderID I-Ds before they are promoted to
being RFCs.

But, the people on this MARID mailing list don't even care about
that.  They would much rather discuss the SPF-classic I-Ds, something
that was never adopted by the MARID working group.

-wayne

---

From: wayne <[email-masked]>
Date: Sat, 29 Jan 2005 13:03:05 -0600

In <[email-masked]> Andrew Newton <[email-masked]> writes:

> If by same records, you mean anything TXT then I'm afraid you will
> have to live with that... and any other new uses for TXT that come
> along.

Nope, I see no problem with using TXT RRs.  (The same goes for CSV's
use of SRV records or MAPS's use of A records.)

> point.... which is not what I thought you were saying.  Sorry for

Actually, reviewing things, I shouldn't have jumped so hard on MARID
changing things.  When MARID decided to do a design-by-committee of a
new system, rarely a wise idea, it didn't change the SPF-classic
specifications.  New systems don't have backward compatibility
problems.

The real problem was that the draft-lentczner-spf-00 I-D did not
eliminate all the incompatibilities that the MARID SenderID I-Ds
created.  Hence the creation of draft-schlitt-spf-classic-00.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Jan 2005 15:30:13 -0800

> use of SRV records or MAPS's use of A records.)

Those publishing SPF records risk causing their mail being forwarded by
various recipients to be blocked or lost, with the same happening to
mail sent through some list servers.  For network security and to
establish accurate reputation, an accountable entity for the mail being
sent can be found by way of the HELO domain.  SPF however can not
indicate which identity checking is desired by the sender.  Is it the
Sender-ID PRA, the SPF MAILFROM, or now the SPF MAILFROM and HELO in
combination?

The design choice of SPF to not use a specific label to access a
potentially large initial TXT RR record, dedicates this TXT RR for use
by one revision of one application.  This is wrong.  This gets even
worse with use of this same TXT RR by more than one faction.  A wildcard
label can not establish policy, so the reasons for avoiding a prefix
proves to have been a major mistake. 

While commending efforts that attempt to establish reasonable limits for
the use of DNS, this effort is like starting with a square block and
chipping away at the corners.  Eventually, one arrives at the wheel.

The new SPF processing limits are stated differently:

A limit of 10 mechanism[s] that do DNS lookups?  Each mechanism is then
allowed 10 lookups?  Would that be a total of 101 lookups?  Will this
prevent attacks?  The average number of queries for each lookup could be
around 3.  The following text and process definitions seem to allow 10
lookups each to resolve the MX, the PTR, and the %{p} macro (reverse DNS
comparison to forward DNS).  Would 10 %{p} count as 20 DNS lookups?

This compares poorly to CSV which uses a single lookup to obtain the
CSV-CSA record.  This record also limits the scope of the identity being
checked to that of the HELO/EHLO.  This record also uses a prefix as to
not usurp a RR type or interfere with other protocols.

CSV makes it clear ONLY the HELO is to be checked, which avoids the
conflicts present with Sender-ID and SPF algorithms.  Sender-ID and SPF
essentially reduce the integrity of mail delivery.  The disruption
caused by these algorithms is without significant benefit, as path
registration authorization does not ensure mail is not being spoofed,
nor which identity is being checked at each stage, nor allow accurately
assessing reputation.

Endorsement of SPF by those that also block bounce messages seems to be
indicating a willingness to trade reliability for expediency.  In the
long run, this approach will be expensive.  There are efforts outside of
SPF that are focusing on the problem.  Mail integrity can be retained,
and accountability accurately determined without putting the email and
DNS system at risk.  May I encourage some of the energy placed upon SPF
to focus on the MASS and CLEAR work groups?

http://mipassoc.org/mass/
http://mipassoc.org/clear/

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Jan 2005 18:28:59 -0500

> that all further discussions on other identities would be ruled out of

  i.e.   http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html

  My recollection was that there was a later consensus call, but I
can't find the post.  The closest is:

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

  Where you note that the consensus of the WG (simple hum, unconfirmed
on the list) was changed to RFC 2822.

> in making decisions than technical considerations.

  Almost all spam/anti-spam discussion is political.  We know how to
stop all spam: turn off all email.  Past that, the "technical"
decision to turn off limited portions of email for some reason
(e.g. message/host validation) quickly becomes political.  Some people
will not implement the scheme themselves, and others oppose a scheme
in general.

  Alan DeKok.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 30 Jan 2005 09:33:38 +0100

Douglas Otis wrote:
 
> Those publishing SPF records risk causing their mail being
> forwarded by various recipients to be blocked or lost,

They don't "risk" this, they _want_ it, it's the idea of RMX
or SPF -all that "mail from A" must come from an IP allowed
by the sender policy of A.  If "mail from A" arrives at C
from another IP B, then C would reject it.

If B was a spammer or mail worm the spam or worm is in fact
"lost", again that's the very idea of RMX or SPF FAIL.  If B
was a legit MTA it would create a bounce message to A, and
the mail is not lost.

Either A screwed up, maybe he forgot to include B in his
sender policy, or B screwed up, maybe a secondary MX forwarded
mail to a primary MX, and the latter tested SPF without
white-listing the secondary MX.  SPF tests work as expected
at the border defined by A, but not later.

You can say that you don't like this one and only feature of
SPF, but you can't say that it's a bug, because it's the idea.

> SPF however can not indicate which identity checking is
> desired by the sender.  Is it the Sender-ID PRA, the SPF
> MAILFROM, or now the SPF MAILFROM and HELO in combination?

Not only "now", HELO was "always" mandatory for MAIL FROM:<>
and otherwise optional.  It's not a new idea.  And it's not
necessarily a good idea, actually it was one of the things I
hoped to solve in the former MARID WG, but unfortunately it
wasn't allowed to discuss 2821 and CSV.  [The SPF overhead
for simple HELO checks is IMHO too big]

Sender-ID PRA has nothing to do with classic SPF policies, it
only uses a somewhat similar syntax for Sender-ID policies.

> This gets even worse with use of this same TXT RR by more
> than one faction.

If somebody abuses a protocol for a completely different
purpose, and it breaks, then he owns the pieces.  As far as
SPF and I'm concerned the goal is a SPF RR replacing TXT in
the future.  One of the reasons why I wanted an RfC.

The other reason was to get an "official" document which can't
be modified only because the authors have a new idea.  That's
now solved by the formation of the SPF council.

> The new SPF processing limits are stated differently

They are just clear and better.  The handling of all errors is
now much more predictable.  Minus DNS timeout errors the same
policy should now have the same effect with all conforming SPF
implementations.

> This compares poorly to CSV which uses a single lookup to
> obtain the CSV-CSA record.

Depends, many policies need only ip4 and all, and that causes
no additonal lookup.  a, include, exists, and redirect need one
lookup.  Ignoring the discouraged ptr only mx is "difficult",
but OTOH looking up MX is something any MTA knows.  Yes, there
is a significant potential overhead, that's the price for its
great flexibility like per-user policies.

s/great/too great/ as you see fit.  An SMTP where nothing but
the IP is reliable doesn't work.  An SMTP where the IP and the
MAIL FROM and the HELO make sense again is a huge step forward.

                       Bye. Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 30 Jan 2005 10:53:40 +0100

Alan DeKok wrote:

> The consensus was to look at 2822 and Sender-Id.

That was a decree and no consensus.  CSV was declared off topic
until the 2822 discussions were ready, and as a result CSV was
never discussed.  Same problem for classic SPF, minus the one
week when the former WG chair asked for a spf2.0/mfrom draft,
and let the WG be closed three (?) days after it was published.

There's a serious problem with RfC 3710 (4.3) vs. RfC 2418 (4).
It's a bad sign that 3710 and 2418 are now among the relatively
few RfCs that I know, thanks but no thanks to MARID. :-(

                      Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 30 Jan 2005 14:44:27 -0800

> SPF, but you can't say that it's a bug, because it's the idea.

Those publishing SPF records want their mail to go missing?  There is no
means to know which recipient may be using a forwarded account.  There
is no means to prevent a "screw up" with SPF.  Forwarding is a common
practice within colleges, societies, and many providers.  Validating the
legitimacy of an MTA can take place within a single lookup of a small
CSV-CSA record.  A single lookup does not increase the risk to DoS
attacks, and also does not create inadvertent loss of mail, as does
SPF.  

> for simple HELO checks is IMHO too big]

The draft just submitted changes both when the HELO is checked and the
outcome of this checking.  Previously, someone ignoring the use of SPF
for HELO would likely find their bounce messages treated as from an
"unknown" source.  With the change being made, the HELO may now be
checked against a record found at the zone apex.  This unexpected change
could cause their bounces to be rejected AND also their mail to be
rejected, as the HELO check is to be done in combination with the
MAILFROM rather than as an alternative for handling bounces.  These are
changes publishers could not anticipate.

I agree, the overhead for HELO checking would be unacceptably high with
SPF, in addition to the other problems SPF records create.

> only uses a somewhat similar syntax for Sender-ID policies.

Pobox still claims Sender Policy Framework is the essential part of
Sender-ID.  It matters how the publishers are basing their decisions.  I
have yet to hear any admonishment by proponents that when publishing
SPF, expect some of your mail to be lost or rejected due to problems
with either SPF et al or Sender-ID algorithms.  This is shameful.

> now solved by the formation of the SPF council.

A mechanism built upon a strategy that can not support revision does not
require a council.  Nor would it likely find approval by a standards
organization that cares about compatibility and a need to support
orderly change.

> policy should now have the same effect with all conforming SPF

This conclusion is guess work.  You could be right, but those that have
published what is now considered too many records may find their mail
being rejected.  The SPF timeout imposed still ignores UDP fallback.
Normal exponential fallback ensures congestion avoidance.  This
oversight for such an intensive use of DNS is a serious concern. 

> great flexibility like per-user policies.

Will imposing the task of implementing the sender's per-user policies
upon the receiving SMTP server scale?  Is it reasonable to expect the
receiving SMTP server to perform a hundred lookups per message?  I see
this "great" flexibility stemming from an overly ambitious marketing
effort that continues to ignore serious problems.  I agree with you,
there is a need to move toward a name basis to establish meaningful
feedback to administrators of MTA systems.  A name basis would help
centralize the effort at getting rid of abuse.  This can be safely
achieved via the efforts in MASS and CLEAR, but not with SPF.

-Doug

---

From: [email-masked]
Date: Mon, 31 Jan 2005 08:40:43 +0100

> attacks, and also does not create inadvertent loss of mail, as does

The forwarding problem is known and information is on spf.pobox.com
(which still is the primary source for information about spf). It's not
like it is 'the big secret of spf' that there is a forwarding issue. I 
suppose people read this site before publishing, so they must know
about the forwarding problem. However, people still publish. I'm not
going to guess at the motivations of these people, i'm not a pyschologist.
Fact is that despite the forwarding issue, people do publish. 

I can only elaborate a bit on my own motivations: if a message is
forwarded and then bounces because of spf, the bounce will contain the
actual email address to which the message was forwarded. I can resend,
perhaps attaching a small note about the fact that the forwarding did
not work. I have never had serious problems with this issue.

Koen

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 31 Jan 2005 10:56:06 +0100

Douglas Otis wrote:

> There is no means to know which recipient may be using a
> forwarded account.

Yes, it's a "sender policy", not a "recipient's policy", and
not a "mediating source policy" (one of the mail-arch terms).

> Forwarding is a common practice within colleges, societies,
> and many providers.

Sure, there's nothing wrong with forwarding, each and every
mail I send is forwarded at least twice, from me to a smart
host, from the smart host to an MX of the recipient, or to
an MDA in the case of local users.

What happens beyond the MX of the recipient is none of my
business, as you say there's no way for me to know what the
recipient does.  My "sender policy" cannot cover forwarding
by the recipient.  If he wants this for some reason, he has
to use his own MAIL FROM and his own "sender policy".

> Validating the legitimacy of an MTA can take place within
> a single lookup of a small CSV-CSA record.

Fine, I've no problem if my mail providers do this for their
smart hosts, or if they test it for incoming mails at their
MXs.  CSV / SPF / SPF+CSV / ... are all okay, as ar as I'm
concerned.

> With the change being made, the HELO may now be checked
> against a record found at the zone apex.

The "zone cut" isn't a new feature, it was in the last SPF
draft published before MARID.  BTW, Tony's blog mentions that
CSV now also solved this problem, but I don't find how, it's
apparently not in the last (now expired) CSV draft.

Here's a summary of my SPF experiences in the last 10 months:

Mar 04: some spammer(s) start to abuse "my" vanity domain, I
        get about 1000 erroneous bounces / vacation mails /
        challenges / etc. per day.
Apr 04: My ISP publishes a sender policy.  Intuition or bug,
        neither my ISP nor me saw the "minor" problem, that
        this sender policy didn't cover "my" vanity domain.
May 04: Wildcard added, now it works even without "zone cut".
        "Zone cut" also added to the SPF draft replacing an
        older "match_subdomains" construct.
Sep 04: 180,000 bounces etc. so far in my mailbox (JFTR, I'm
        a modem user)
Oct 04: My spammer(s) got the SPF idea, again zero bounces
        etc. per day
Jan 05: So far not a single problem with SPF from my POV, and
        4*30*1000 = 120,000 avoided bounces etc. since Oct 04.

You can discuss "the better is the enemy of the good" in MASS
and CLEAR as long as you like, I have what I wanted, and SPF
was good enough for me.  Let them all disable SPF as soon as
something better exists and works, no problem.

> I agree, the overhead for HELO checking would be unacceptably
> high with SPF

Where that's the case (it depends on the sender policy) the
sender could arrange his HELO domains to avoid it.  And if CSV
has a better solution than SPF's "zone cut" for spoofed HELOs,
I'd be interested what it is - I'm always curious.

> when publishing SPF, expect some of your mail to be lost or
> rejected due to problems with either SPF et al or Sender-ID
> algorithms.  This is shameful.

No legit mail is "lost" with SPF, that's FUD.  While MARID was
a shameful disaster, one of the few results was, that Sender-ID
evaluations of SPF sender policies generally do _not_ work.

> those that have published what is now considered too many
> records may find their mail being rejected.

If an erroneous policy "worked" with old SPF implementations,
and new implementations report the error, then it's time to
fix the old error.

> The SPF timeout imposed still ignores UDP fallback.

The overall SPF timeout in old drafts was replaced by clear
processing limits, which don't depend on a vague accumulated
processing time.

| Records that are too long to fit in a single UDP packet MAY
| be silently ignored.

> Is it reasonable to expect the receiving SMTP server to
> perform a hundred lookups per message?

No, that's why it's impossible, you have constructed a worst
case of 1+10+10*10 = 111 DNS lookups for a sender policy with
10 mx directives, each with 10 MX hosts.

The average case is probably more like 1 to 4 lookups, I've no
data to support this guess.  And not necessarily per message,
if you'd use CSV or SPF or an RBL to block an IP or to reject
all mails after your HELO-test resulted in a FAIL, then you
won't test the individual messages in this SMTP session.

> This can be safely achieved via the efforts in MASS and
> CLEAR, but not with SPF.

Please inform "us" when that's ready and deployed.  Bye, Frank

---

From: "Ian Rogers" <[email-masked]>
Date: Mon, 31 Jan 2005 13:45:00 -0000 (GMT)

> K.F.J. Martens wrote:
> like it is 'the big secret of spf' that there is a forwarding issue.
> [snip]
>
> I can only elaborate a bit on my own motivations: ...

As admin of several dozen domains I publish SPF records to avoid litigation!

Considering that sending a virus as an offence against the Computer Misuse
Act (in the UK at least) every now and then I get irate messages accusing
my servers of sending out spam or viruses. A quick glance through the
header of the accused message confirms that it was spoofed and then I'm
able to write back saying "no, it wasn't my server that sent it and I've
published the SPF records to prove it. Please encourage your ISP to use
SPF" and give the pobox URL for good luck :-)

I'm happy to take the flack for messages not being delivered due to
"anonymous" forwarding. Note there is a difference between a person
forwarding a message from their MUA (which is effectively generating a new
message with the content of another - which SPF handles fine) and
"anonymous remailers" (where a forwarding 'bot effectively spoofs itself
as the original sender in order to forward the message on verbatim to the
ultimate recipient).

In the Good Old Days the anonymous remailer was a useful tool. But in
*this* day and age of forged-sender spam, Joe jobs and phishing that
functionality must (unfortunately) be considered broken.

You (Douglas and other anti-SPF posters) are quite correct in saying that
SPF won't stamp all spam (but then SPF never claimed it would) and that it
breaks anonymous forwarding (which SPF always acknowledged) but SPF+SRS is
the best, current, first-baby-steps solution available for stamping out
forged sender - which *is* IMHO the essential first step for eliminating
joe-jobs, phishing and a significant subset of spam.

Regards,

Ian.

---

From: David Woodhouse <[email-masked]>
Date: Mon, 31 Jan 2005 14:35:13 +0000

> Fact is that despite the forwarding issue, people do publish. 

The forwarding problem isn't exactly shouted from the rooftops on the
SPF site, and people rarely actually think things through for
themselves, unfortunately. If you point those _same_ people at something
like http://david.woodhou.se/why-not-spf.html they often seem to change
their mind again and stop publishing records, in my experience.

-- 
dwmw2

---

From: "K.F.J. Martens" <[email-masked]>
Date: Mon, 31 Jan 2005 15:42:55 +0100

> their mind again and stop publishing records, in my experience.

Although not correct in some places, it as a funny web page indeed! In
my experience, people have read that page and either don't care, don't
understand or don't believe what is being presented. And given the
incorectness of some of the statements on that page, who can blame them.
Anyway, this thread is going nowhere fast, so let's close it allright?

Kind regards,

Koen Martens

Networking, hosting, embedded systems, unix, artificial intelligence.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 31 Jan 2005 12:37:05 -0500

Douglas Otis <[email-masked]> wrote:
> Those publishing SPF records want their mail to go missing?

  Any mail they didn't send.

>  There is no means to know which recipient may be using a forwarded
> account.

  Yup.  Likewise, there's no way to know who on the net will be
sending spam forged to be "from" your domain.

> Forwarding is a common practice within colleges, societies, and many
> providers.

  As is spamming.  As is drunk driving.  Having something a "common
practice" doesn't mean it's right.

>  Validating the legitimacy of an MTA can take place within a single
> lookup of a small CSV-CSA record.

  Which is a great idea, and has been integrated into SPF.

> A single lookup does not increase the risk to DoS attacks, and also
> does not create inadvertent loss of mail, as does SPF.

  No, "intentional" loss of mail.  I intend every single spam which
uses my domain name to be discarded.  I would rather have others
discard them than have those people complain to me that I'm spamming
them.

  This is not to say SPF is perfect.  Other methods do much of what
SPF does, without it's problems.

  But as a concept, the domain owner should be able to control the use
of that name.  If we can't agree on that, then the only logical
alternative is that third parties can use someones name without their
consent, and therefore forged spam is OK.

  Alan DeKok.

---

From: wayne <[email-masked]>
Date: Mon, 31 Jan 2005 12:55:40 -0600

> sending spam forged to be "from" your domain.

If the sending domain uses SES, then it can detect the forwarder
situation and not cause an SPF failure.  (This can also be used for
roaming users.)  The cost is an extra DNS lookup.

The receiving MTA can know if email is being sent through a
forwarder.  For example, the user can tell the system via a whitelist
request.  Spamassassin's auto-whitelists will automatically help out a
great deal because it detects the overall spamminess of the forwarder and
that will be enough to override the SPF failures.

Better systems could be built to automatically detect forwarders by
looking to see source usually fails the 2821.MAILFROM SPF check, but
usually passes when the 2822.To: (or cc:) gets an SPF check done on
it.

> SPF does, without it's problems.

I certainly agree that SPF is not perfect.  I am, however, curious
which systems you think do much better than SPF and what data you have
to back up that opinion.  So far, I haven't found any data to back
that claim.

-wayne

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 31 Jan 2005 15:52:22 -0500

wayne <[email-masked]> wrote:
> which systems you think do much better than SPF

  I did not say "better".

  There are schemes which, individually, do less than what SPF does.
As a result, they do not have the issues that SPF has, because SPF has
a wider scope and therefore wider side-effects.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jan 2005 13:05:07 -0800

> to use his own MAIL FROM and his own "sender policy".

SPF may say, "Here is a comprehensive address list", when in reality it
can never be comprehensive.  Either the sender policy allows open-ended
inclusion of other locations, or such sender policies may cause mail to
go missing or be refused.  This is a problem created by the sender, and
not the many unknown others using forwarded accounts.

Use of close-ended SPF records presumes excluding mail on the basis of
MAILFROM not matching a sending MTA has value exceeding a disruption it
may cause.  SPF does not prevent spoofing of the domain, as many share
common providers and there is no consensus which identities are checked
against such records (when these records are even examined).  The high
number of potential DNS lookups ~101-201 (requirements based upon
Schlitt's draft) ensures SPF can not be used to protect the network.
SPF represents an increased risk with respect to network security and
protection.

Protecting the domain from being spoofed is a feature safely offered by
digital signature techniques.  I see a real value in this, but yet no
signature scheme offers network protection.  CSV is intended to protect
the network using the same name basis.  

> apparently not in the last (now expired) CSV draft.

There is not a major change being made to CSV.  The design team is
defining use of the Port field for Domain assertions.  Such assertions
could include use of signature algorithms, as example.  Use of a
wildcard label is unsuitable for publishing policy, so the prefix used
by the CSV-CSA record is not a deterrent toward establishing domain wide
assertions.  This domain assertion is not constrained to zone cuts.
After lengthy consideration, it was determined this too would be
inappropriate.  This updated draft should be ready very shortly.

>         4*30*1000 = 120,000 avoided bounces etc. since Oct 04.

There needs to be a means to discourage spoofing of domains and the
abuse of bounce traffic.  The MASS, CLEAR (BATV & CSV) efforts are aimed
at achieving those goals without onerous path registration discovery.
While a small domain may accommodate such related problems, security
considerations dismiss value in path registration and thereby the need
to also disrupt forwarding, various list servers, and user's access to
mail.  CSV looks to the administrators of the domain to control access
to their outbound servers, and uses both assertions and reputations to
protect the networks.  CSV does not require providers to make specific
DNS record changes to accommodate their customer's use of independent
mailbox domains.

> I'd be interested what it is - I'm always curious.

Good to hear.

> evaluations of SPF sender policies generally do _not_ work.

A well understood problem is not FUD!    

> and new implementations report the error, then it's time to

With SPF, there is no means to prevent disruption and provide an orderly
introduction of newer revisions.  A script based language is inherently
complex and rarely stable. : (

>From the Schlitt's draft:
   MTAs or other processors MAY also impose a limit on the maximum
   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
   allow at least 20 seconds.  If such a limit is exceeded, the result
   of authentication SHOULD be "TempError".

> 10 mx directives, each with 10 MX hosts.

The concern is not what most use, the concern is what limits must be
permitted.  The draft requires these 101 to 201 lookup limits depending
upon the mechanisms.

> won't test the individual messages in this SMTP session.

By checking per HELO, the rate CSV does a lookup is some multiple less
than SPF, and constrained to a single lookup and not hundreds of
lookups.  This aspect is critical. 

> Please inform "us" when that's ready and deployed.  Bye, Frank

Gladly.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jan 2005 16:50:26 -0500

Please Doug.

You can't guarantee that an immediate router will be CSV compliant.  So you
have the same heterogeneous/mixed policy issues as SPF and all the rest of
the proposals.

In addition,  you have a MUCH higher overhead than most as you based on
state point #1 - HELO/EHLO.

Now why would I want to do a HELO CSV check without determining:

    - Check to see if the sender is valid,
    - Final vs Route

You will say;

    "Our new MAPS CSV/DNA service will take of this.  We will vouch
     for the transaction."

 But what if the SMTP operator does not want to use your new MAPS CSV/DNA
service?  What if you go out of business?   What if you get enough support
headaches from thousands of smaller systems that you decide to raise the
price to filter out these bothersome clientele?

Please, again.

Give me something technically SOUND before even have to bother with the
baloney that will come about with DNA like concepts.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office

---

From: Dean Anderson <[email-masked]>
Date: Mon, 31 Jan 2005 20:10:41 -0500 (EST)

> its head: 34% being spam, 65% being ham.

Err, no. If there was less total spam, then instead of some 60k messages,
you might have 50k messages. However, very likely, there would still be
3302 messages that had correct SPF records. Your calculation, while a
useful number, adds in all sorts of other noise, not related to SPF. This
sort of misunderstanding is unfortunately, all too frequent.

If you decrease the number of spams by 10k messages (roughly 15%), and
3.7% of total spam has SPF, and all spammers do the same thing, then the
SPF spam number would only decrease by 3.7%. Assuming that, we'd expect
our SPF-using spams to drop by 75 messages. (neglecting variance)

So now we'd have:

1263 ham / 3227    = ~39%
1964 spam / 3227   = ~61%

Barely a difference, yet a roughly 15% change in spam volume.

However, the SPF spammers are not doing the same thing as all other
spammers. We have no reason to think so. So a change in the behavior of
the non-SPF using spammers would _not_ affect the behavior of the
SPF-using spammers, so you'd expect the same 3302 messages as before.  Of
course, virus joe-jobbers probably think that by generating more spam,
they alter the statistics of real spammers.  That's only true if there is
no way to distinguish joe-jobs from real spam. But of course, we can make
such distinctions with CAN-SPAM. No doubt, this is precisely why the DMA
was behind CAN-SPAM.

Fake spam violates CAN-SPAM: no real product or service, etc.  Genuine
spam MOSTLY doesn't: There is a strong incentive for genuine spammers to
comply, and compliance isn't hard for a real company. But it is
practically impossible for fake spammers to comply, because if they had
real products or services, they'd be real spammers, but of course, they 
aren't real commercial operations.

SPF added another interesting element to all this, in that genuine
spammers leapt onto the bandwagon early, and essentially added a label to
their spam, a lable that fake spammers can't easilly add at the moment.  
Eventually, viruses such will be able to start using ISP relays identified
by SPF, but for now, they can't do that easily, and so don't have SPF
"protection" or labeling.  The unexpected segregation created during this
transition period should yield a great deal of insight into genuine spam
and virus activity.

BTW, I noticed that John Levine published a diatribe on the "failure of
CAN-SPAM" on circleid a few days ago. He is wrong again, asserting
incorrectly that CAN-SPAM was meant to outlaw spam. It legalized spam, and
gave a way to distinguish the real (ie DMA member) spammers, from the fake
(and I suspect anti-spam radical) abusers. I suspect that if you go back
to Congress, the DMA will simply push for enforcement of the criminal
provisions of CAN-SPAM, which should reveal the identities of our virus
operators.  I wonder who that will reveal, and if it will be another ISP
abuse admin, or radical anti-spammer.  I forsee the end of a certain type
of spam, in the same way that open relay abuse ended: The abusers will
just give up. It will be nice if this accounts for 96.3% of all spam.  
But, I've digressed enough.

> counts of SPF-bearing-ham and SPF-bearing-spam directly.

Safer?  Its different. Safer has some other implication thats not clear. I
don't know what "safer" means.  It could mean that since 18% of total ham
has SPF records, that perhaps deleting based on the roughly 2 to 1 chance
that "SPF records mean spam", is an "unsafe" bet.  More rules to cover the
ham would be important.

However, when you ask the question "what is the ratio of SPF use that is
spam and SPF use that ham?", the Sum of the percents have to add to 100,
otherwise you didn't answer the question. You answered some other
question.  Possibly, that question is also useful, but it wasn't the
question asked. The assertion was the spammers jumped on SPF. The percent
SPF use that is spam is 62%.  The percent of SPF use that ham is 38%. The
total SPF use is composed of spam and ham. Spam SPF use + Ham SPF use must
equal 100%.

Your corpus supports the Ciphertrust assertion.  But you said it didn't.  
That was incorrect.  The mistake was that you answered a different 
question.

> not being something that's easy to automate checking for (more's the

You should have accepted the IEMCC proposal back in 1997. Wallace and co.
proposed everything that's in CAN-SPAM, with the benefit of a special
X-spam header (I think it was called something else, like X-advertisement
or some such).  That sort of labeling would have made the problem easy.  
But the radicals didn't want to be reasonable at the time--thought they
could end spam by techincal means.

		--Dean

> - --j.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Exmh CVS
> 
> iD8DBQFB+sdSMJF5cimLx9ARAhvgAKCdDpROw4/yqVxCwOwMipg46uh/LACbBD/6
> HsR9l0+iPdHRG4RDM/zOSmQ=
> =lLX4
> -----END PGP SIGNATURE-----
> 
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jan 2005 18:23:22 -0800

> have the same heterogeneous/mixed policy issues as SPF and all the rest of

If the sending SMTP client publishes a CSV-CSA record, then this client
is both authenticated and authorized by the HELO domain.  This permits
assessment of reputation which may supersede evaluation of the IP
address.  It also permits direct and meaningful feedback to the
accountable administrator, as a means to rapidly respond to abuse.

Authorizations offered by SPF path registration is insufficient for
reputation assessments, as there is no assurance which administrator is
directly accountable for abusive messages.  SPF does not authenticate
the sending domain, it only confirms authorization.  Where many domains
have authorized an MTA with SPF, resolving abuse may become an expensive
process.

CSV allows such assessments to be made safely on an opportunistic basis
while not requiring heterogeneous adoption.  CSV is also incorporating a
means to assert domain wide use of CSV as a means to discourage HELO
spoofing.  Unlike SPF, CSV does not disrupt the normal use of mail nor
depend upon any tests or changes in MTA behavior.

> state point #1 - HELO/EHLO.

Authenticating the HELO is done within a single lookup with CSV.  How
can this be a higher overhead?

SPF provides authorization for the MTA referenced by a sending mailbox
domain (without consensus as to which mailbox domain).  While SPF could
also be extended to examine the HELO domain, those that have previously
published SPF records may not have ensured HELO domains resolve to an
SPF record.  SPF evaluation of HELO was previously applied during the
sending of bounce messages, where the outcome would have been "unknown"
rather than "fail" without specific records in place.  It is also likely
that SPF HELO records may require resolving the same large address space
as that needed for mailbox domains and is a DoS concern. : (

Changing SPF to apply a record at the zone cut against the HELO, in
addition to further increasing overhead, may now put some domains in
jeopardy due to a lack of proper record revisioning.  Using the same
check_host routine and records, as used to examine mailbox domains, may
also permit unexpected exploits.  Although the number of SPF records
could be few on average, the need to register potentially complex paths
always requires an excessive limit for the number of lookups.    

>     - Check to see if the sender is valid,

MASS is addressing the need to safely authenticate the administrator of
originating sender domain.  CSV addresses the need to protect the
network from abuse, and therefore only considers authenticating the
administrator of the immediate sending domain.  CSV does not require
customers of various mail providers to have their various provider's
domains entered into their DNS records.

CSV will not inappropriately assess the customers of various providers
for a lapse in access control of some provider's server.  The
administrators of the servers are accountable for security, not
customers.    

>     "Our new MAPS CSV/DNA service will take of this.  We will vouch

Accurately authenticating the accountable domain's administrator (who is
permitting mail access), allows assessing reputation.  There is value
from this information alone, as it also means the sending MTA has been
specifically authorized to send mail.  This helps with detection of
zombies without the use of a vouching service.  Securing the networks
will always require a reputation service, whether IP address based or
extended to using names.  There are advantages using names with respect
to ensuring legitimate domains eliminate abusive accounts with the least
expenditure.

> price to filter out these bothersome clientele?

This seems to be putting the cart before the horse.

> baloney that will come about with DNA like concepts.

The CLEAR design team is working diligently at ensuring CSV is sound.
There are models where reputation is provided as a service to the SMTP
servers.  While CSV has made accommodations for a vouching model, it is
unknown which model will prevail.  While bulk mail providers may favor
the vouching approach, a more significant number may rely upon a direct
reputation service model.

I should also note that BATV does not require any outside service to
address abusive bounce messages.  Although SES is similar, it introduces
some security concerns by way of its syntax.

-Doug