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

From: David Woodhouse <[email-masked]>
Date: Tue, 01 Feb 2005 07:57:46 +0000

On Mon, 2005-01-31 at 18:23 -0800, Douglas Otis wrote:
> 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.

The syntax of each can be treated as if it's entirely opaque, and SES
without any form of validation at the _receiving_ side is then
indistinguishable from BATV in all but cosmetics, surely?

What are the security concerns of which you speak?

-- 
dwmw2

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Feb 2005 00:20:27 -0800

> What are the security concerns of which you speak?

This was raised on the CLEAR mailing list by William Leibzon and
responded to by Tony Finch.  Follow the thread.

http://mipassoc.org/pipermail/ietf-clear/2004-November/000133.html

To discuss this issue, it would be best done on the CLEAR reflector:

http://mipassoc.org/mailman/listinfo/ietf-clear

-Doug

---

From: David Woodhouse <[email-masked]>
Date: Tue, 01 Feb 2005 08:48:26 +0000

> http://mipassoc.org/pipermail/ietf-clear/2004-November/000133.html

Ah yes; I had seen that but discarded it as irrelevant in the context of
BATV -- BATV alone doesn't really offer the _recipient_ much benefit
along those lines anyway. Referring to the examples in message
000146.html, it's obvious that with BATV the attacker could just send a
mail from 'batv=INVALIDBATVTAG/victim@domain' anyway, and the recipient
would have no means to validate that.

In the context of SES it's slightly more relevant, but really not by
far. It involves a naïve user actually looking in the message headers
for the reverse-path and _incorrectly_ identifying it as an SES
localpart, thus having faith in it. (If the MUA were to be modified to
show SES/BATV reverse-paths more prominently, of course it wouldn't have
the false positives that wetware can have).

In general, users don't do that. Either they're capable of telling the
difference, or they're not going to be looking in the headers for it
anyway. The middle ground is relatively rare.

It also involves the domain owner/admin actually permitting that kind of
reverse-path to be used in outgoing mail, and authorising it as valid if
it's sent from elsewhere.

-- 
dwmw2

---

From: wayne <[email-masked]>
Date: Tue, 01 Feb 2005 03:49:03 -0600

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

> This was raised on the CLEAR mailing list [...]
>

Wait, you don't want CSV issues discussed on the MARID list even
though CSV was adopted by MARID?  But you keep bring up SPF
discussions here instead of on SPF-discuss even though MARID never
adopted SPF?

*sigh*

-wayne

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Feb 2005 08:23:17 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 31, 2005 9:23 PM
Subject: Re: So here it is one year later...

> On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote:
> > 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.
>
> If the sending SMTP client publishes a CSV-CSA record, then this client
> is both authenticated and authorized by the HELO domain.

The "chain of trust" issues with SPF applies to CSV as well.

What about the downlink?   Once the message is received, it is your
responsibility to deliver it.   My sender went directly to you, the MDA. If
you decide to route it instead, then you have to maintain the chain of
trust.   You can not guarantee this transaction when you become the sender.

> > In addition,  you have a MUCH higher overhead than most as you based on
> > state point #1 - HELO/EHLO.
>
> Authenticating the HELO is done within a single lookup with CSV.  How
> can this be a higher overhead?

I don't think you really understand the implementation issues of your own
proposal.  Maybe you do and are just turning a blind eye.

> > Now why would I want to do a HELO CSV check without determining:
> >
> >     - Check to see if the sender is valid,
> >     - Final vs Route
>
> MASS is addressing the need to safely authenticate the administrator of
> originating sender domain.  ....

You didn't answer the middle-ware, chain of trust issue, and you didn't
address the above.

Delay verification is a REQUIREMENT, not a BCP for all DNS based
authorization ideas..  I have statistic proof with over 1 year of product
operations in thousands of installed sites:
http://www.winserver.com/spamstats.

The functional model of CSV is:

            EPV = CSV(helo, ip)

which fails to take into the account the validity of the other process
environment parameters, MailFrom, RcptTo.   That my friend, is a overhead
issue.

> > 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?
>
> This seems to be putting the cart before the horse.

No. It is called business and practical product experience.  You are
proposing an idea infested (wrongly placed) with capitalistic commercial
concepts, which I don't mind saying,  you will be among the first to benefit
from as the first DNA commercial service.  PR problem #1. Therefore, if we
were support and implement CSV,  we would have to include a disclaimer for
any Anti-Spam CSV support statement; "Batteries Not Included. DNA Service
Subscription Required."   We are not going to add what is suppose to be a
"technical" solution with subscription concepts behind it.  Period.  PR
problem #2.    My Advice?  Dave should take Doug out of the CSV promotion
picture.  You don't do CSV any justice.

Dont' get me wrong. I'm for making a buck as much as the next guy. But the
"Email Problem" needs an open standard technical solution free of 3rd party
dependencies.   It is a duel tier process.  Transport security must be done
using SMTP first.  Main Content Security is an separate issue, however,
there can be a tie in of the two, but not dependent on it.

The point is, if you send me mail,  I must be able to trust the transaction
before I accept your payload.  Authenticating the payload is an
ADMINISTRATIVE concept.

Using a CSV authorization domain is not sufficient WITHOUT looking at the
2821.Mail From as well as 2821.RCPTTO.  Therefore, as it has been
emperically proven, using HELO by itself would be wasteful overhead without
taken all process environment parameters into consideration.

I have PROOF of this issue. Doug. All you are doing is making assertions of
the opposite and you have no proof to show I am wrong.

Sincerely,

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Feb 2005 12:46:26 -0800

On Tue, 2005-02-01 at 08:23 -0500, Hector Santos wrote:
> On Mon, 2005-1-31 at 9:23 -0500, Douglas Otis wrote:
> > > 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.
> >

CSV does not make assurances for MAILFROM or FROM mailbox-domains.  The
HELO identifies the administrator of the specific MTA.  It is the
administrator trusted and not millions of users that may be using the
server.  When there is a problem, ONLY the administrator is able to
rectify the situation.  In essence, mail is not secure and the source of
a message is not assured beyond the immediate server.  It is wrong to
assume a "chain of trust" is maintained, as this could be injurious to
those assumed to be the source of the message.

MASS avoids the fallacy of a "chain of trust" by using a digital
signature.  SPF assumes identities are checked at each stage against a
lengthy resolution of path registrations.  There is also no consensus
which mailbox-domain is checked, if any, even assuming these checks were
practical and safe.  Schlitt's SPF draft says to use some identity as an
alternative without indicating whether this is the PRA identity or
something else. : ( 

> trust.   You can not guarantee this transaction when you become the sender.

Most MTAs only accept mail from anonymous sources being sent to their
immediate domains.  Most MTAs also decide whether to accept from an
anonymous source based upon reputations of the IP address.  Without such
checks, few could afford the bandwidth needed to permit legitimate mail.
You are describing a practice that could put the reputation of the MTA
IP address at risk.  A reputation service should never consider an
unauthenticated identity within the message as being culpable. 

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

Information provided by SPF only indicates who may have sent the
message, and not who actually sent it.  Resolving issues of abuse by way
of SPF is potentially injurious to mailbox-domain owners.  CSV ensures
accountability remains with those administering servers and not a
possibly hapless customer.   Essentially SPF is a weapon that does not
always shoot straight and therefore should not be used as an abatement
tool.  SPF does not eliminate the need for administrators to control
access to their servers nor remove the need to watch for abusive
accounts.  In addition, SPF is a paper tiger easily destroyed.  MASS
however is attempting to safely provide a real means to control use of
the sender mailbox-domain.

MASS provides this domain control to protect users, whereas CSV and BATV
protect networks.  SPF is unable to offer any real protection for either
users and definitely not networks.

> You didn't answer the middle-ware, chain of trust issue, and you didn't

The use of a digital signature avoids false assumptions of there being a
"chain of trust" as the mail channel is not secure.

> environment parameters, MailFrom, RcptTo.   That my friend, is a overhead

Inordinate overhead must not be placed upon the receiving MTA.  CSV
delegates source control overhead onto the administrator accountable for
the server.  There are many tools to assist in their effort.  Monitoring
the SMTP error logs, unusual traffic patterns, as well as abuse
reporting.  CSV helps ensure this reporting is directed to the
accountable administrator.  SPF alone will not abate abuse, while it may
produce victims as it is applied in conjunction with reputations.
Spammers will simply adapt and take advantage of these false assumptions
being made by SPF.

> > > 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?
> >
> from as the first DNA commercial service.

CSV is offering an authenticated name for the sending MTA that helps in
many ways with respect to dealing with the email abuse problem.  The
transition to the use of names will likely be an immediate benefit to
those already providing vouching services.

> PR problem #1. Therefore, if we were support and implement CSV,  we
> would have to include a disclaimer for any Anti-Spam CSV support
> statement; "Batteries Not Included. DNA Service Subscription
> Required."   We are not going to add what is suppose to be a
> "technical" solution with subscription concepts behind it.  Period.

An immediate benefit of CSV comes from being able to associate an
authenticated name with the immediate sending MTA.  MASS offers the
feature that allows control over the sender mailbox-domain regardless of
the immediate sending MTA.  The blunt instrument provided by CSV
protects the network from grossly negligent administrators.  MASS should
be able to protect users from those wishing to spoof sender
mailbox-domains.  MASS/CSV can work together in a unified name basis for
guarding mail.  SPF will not remove the need for some form of
reputation/vouching service, nor remove the need for some form of
network protection.     

> Dont' get me wrong. I'm for making a buck as much as the next guy. But
> the "Email Problem" needs an open standard technical solution free of
> 3rd party dependencies.   It is a duel tier process.  Transport
> security must be done using SMTP first.  Main Content Security is an
> separate issue, however, there can be a tie in of the two, but not
> dependent on it.

There were several companies touting reputations services at the FTC
Email Authentication Summit.  I was not promoting such a service.  I was
insisting upon adoption of a safe and accurate means to assess abuse.  I
remain convinced MASS and CLEAR are considering viable solutions.

> before I accept your payload.  Authenticating the payload is an

Authenticating the payload is the subject of an ongoing effort in MASS.
I want to see MASS succeed in providing an effective solution that can
protect the sender mailbox-domain.

> taken all process environment parameters into consideration.

Holding the sending domain accountable offers substantial relief without
a need to sort through millions of users employing various
mailbox-domains within thousands of various providers.  There is a fair
amount of experience that supports this view.  

> the opposite and you have no proof to show I am wrong.

This is not the proper venue for product related data.  Most of the
benefits claimed by SPF are related to changes in behavior, and not
cessation of abuse.  As an immediate source for relief, BATV would be
more effective in preventing the unwanted bounce traffic as this can be
done unilaterally.      

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Feb 2005 12:59:54 -0800

> discussions here instead of on SPF-discuss even though MARID never

Do you really want me to interact with those on the SPF-discuss mailing
list?

I suggested that the best forum to discuss this BATV/SES syntax was on
the CLEAR list server.  I see David made a minor error in his statement,
as example, but I am not the person most conversant on this subject.  I
encouraged William to propose his concepts, but Tony raised some
legitimate concerns.  It would be beneficial to find consensus on this
syntax.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Feb 2005 16:42:28 -0500

Is this a CANNED reply message?   It sure reads like it.

Look,  CSV does not pass the test for consideration.  That might explain why
no commercial vendor has implemented it.

And we were not talking about MASS.  We are talking about the fallacy of CSV
being immune to heterogeneous/mix policy topologies and lacks overhead
issues.   You are wrong in both cases.

I think you are saying MASS solves these problems for CSV.

Well,  that's a PAYLOAD solution so it doesn't address the heterogeneous/mix
policies and overhead issues at the SMTP level.   So I believe you are
incorrect here as well.

Anyway, I don't wish to get another canned reply, so I think I'll stop
here.:-)

Thanks for the chat

Sincerely,

Hector Santos, CTO

---

From: [email-masked]
Date: Tue, 01 Feb 2005 16:11:48 -0800

What an amusing thread.  Following along, it suggest this mailing list 
is secretly a humor list. At the least, it should be obvious why the WG 
accomplished nothing. "He's dead, Jim."

Bryce Ryan

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Feb 2005 17:04:12 -0800

> Is this a CANNED reply message?   It sure reads like it.

It sure feels like the same issues.

> Look,  CSV does not pass the test for consideration.  That might
> explain why no commercial vendor has implemented it.

The goal for CSV is to reach consensus on a well considered design, run
tests, and then attempt to pass muster with a standards effort before
widely promoting it.  Considering impacts upon existing infrastructure
has been no small part of this process.

It would seem proponents of SPF have concluded problems resulting from
changes to the rules without record versioning is acceptable.  Does it
really matter the same view is held by the Sender-ID faction, as well as
the SPF-Classic faction?  The spf.org site makes it clear Sender-ID
causes mail delivery problems.  Schlitt's draft also makes it clear
forwarded mail may be lost and "Tests against some other identity may
also be used to override the test against the "MAIL FROM" identity."
What other identity?  Being this vague ensures there will never be a
"chain of trust".  This type of approach makes it impossible to judge,
from the perspective of implementation, who is doing what.

Forgive those that take a longer view.  It seems SPF has already lost
control over how these records are used.  Breaking mail as a way to
inflict change is not justified for a system that makes consumers rather
than providers accountable.  Lack of authenticating the message source,
in the long run, may prove costly as these problem become apparent.

> issues.   You are wrong in both cases.

You seem to be obsessing on having SPF replace the role of a responsible
administrator.  Alas, SPF can not be trusted to properly indicate the
source of abuse.  Please don't say this is not your concern, and that it
is the victim's.

> I think you are saying MASS solves these problems for CSV.

The need to protect the sender's mailbox-domain can be safely provided
by MASS.  CSV never attempts to fulfill that role.  CSV is the first
protective phalanx for the network, based upon a name rather than an IP
address.  This could work in conjunction with a common name based
reputation system.  MASS will never offer protection for the network,
whereas CSV can.  SPF, with its high overhead, does not afford network
protection advantages.

> policies and overhead issues at the SMTP level.   So I believe you are

A minimal overhead at the SMTP level is definitely an advantage that CSV
offers over SPF.  The disagreement seems to be whether SPF provides
greater benefit by excluding messages that do not comply to an expensive
path registration.  Forwarding is now defined as "illegitimate" and
messages lost as a result of transparent interception at hotels and
network kiosks is "acceptable" even though these are effective anti-spam
deterrents.  Will customers accept such problems and blame under the
guise of defeating spam?

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 02 Feb 2005 14:07:48 +0100

Douglas Otis wrote:
 
> SPF may say, "Here is a comprehensive address list", when in
> reality it can never be comprehensive.

Of course it is.  There are at most 512 IPs sending mail from
whoever@xyzzy to somebody@elsewhere.  The other 254*256*256*256
IPs don't do this, unless they are forwarding mail from me, and
then it's something arranged by somebody@elsewhere.  He's free
to do whatever he likes, but of course he shouldn't check one
of his relay IPs against "my" 512 IPs.

And there at most 512 IPs who could say HELO xyzzy.claranet.de.
In reality no MTA should do this, but for this minor detail SPF
isn't good enough, maybe CSV could catch the remaining 512 IPs.
BTW, can it ?

> This is a problem created by the sender

"v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"
isn't "a problem created by the sender", it's simply the truth.

> SPF does not prevent spoofing of the domain, as many share
> common providers

If somebody authorized to use one of these 512 IPs spoofs "my"
vanity domain, then I'm sure that the abuse desk of my ISP can
solve this problem very quickly, otherwise they'd risk to lose
a happy customer.

And SPF offers solutions for this situation where necessary,
e.g. some existing policies use ? instead of + for shared IPs.

> there is no consensus which identities are checked against
> such records (when these records are even examined)

2821-From and -HELO are checked.  Anything else won't work as
expected.  Of course I can't force you to do "the right thing",
you could check something else somewhere else, but why bother
with DNS and SPF if you want some random rejects ?  Try BLARS,
its cheaper than SPF for this purpose.

> CSV is intended to protect the network using the same name
> basis.

So far I haven't seen any spoofed HELO xyzzy.claranet.de in
bogus "bounces to" me, so probably CSV would have done nothing
at all for my problem.

> This domain assertion is not constrained to zone cuts.  After
> lengthy consideration, it was determined this too would be
> inappropriate.

Can it identify HELO xyzzy.claranet.de as rubbish ?  I've read
the discussions about SPF's "zone cut" in CLEAR, and the Jan 4
plus Jan 6 entries in <http://www.livejournal.com/users/fanf/>
- but that doesn't explain the details.  And I haven't found a
case where `nslookup -q=ns sub.dom.ain.example` fails to find
the "zone cut".

> A well understood problem is not FUD

Claiming that SPF causes mails to be lost is definitely FUD,
Like the collection of monstrous lies in the PDF:
<https://antiphishing.kavi.com/events/Conference_Notes/sender_auth_myths_and_domainkeys.pdf>

BTW, I found that link on the page:
<http://podcast.resource.org/rf-rfc/index.html#item0003>

> A script based language is inherently complex

Yes, the macro language has its drawbacks, and the TINW in "we"
had some problems to get it right for some obscure cases like a
slash in a FQDN used as HELO.   Actually that was in one of two
relevant articles in MARID (with thanks to Julia and Margaret)

OTOH Wayne now defined exactly 10 macro letters, 8 are used in
sender policies, anything else is an error.  That's not too
complex.  Don't try to convince me that the SPF "explanations"
are ridiculous, I wouldn't disagree (one of the minor issues I
hoped to get rid of in the former MARID WG, but here we are).

  [overall timeout]
>> From the Schlitt's draft:

ACK, error on my side, this "implementation detail" is still a
part of the draft, and maybe I'll discuss it with Wayne on the
SPF list, it's unnecessary.  Of course there must be a way to
report and log "local error conditions".

In the lentczner-drafts the optional overall timeout was a very
important part of "processing limits" and indirectly "security
considerations", now it's on the same level as say a "sigterm".

> The draft requires these 101 to 201 lookup limits depending
> upon the mechanisms.

If you have some local reasons to ignore a sender policy, then
just do it.  And if you want a documented reason to state that
a sender policy is erroneous follow the spec.  The latter is a
reason to reject the mail with a PermError, the sender policy
has to be fixed.

> 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.

For me it's critical that a forged "mail from me" is rejected,
and CSV won't do this trick.  If you think that the two lookups
to check any "mail from me" are too much just don't do it.

SPF worked for me as soon as some "important players" (defined
from the POV of "my" spammer) implemented it, it's not critical
if you don't use it.
                     Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 2 Feb 2005 09:26:06 -0500

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 02, 2005 8:07 AM
Subject: Re: So here it is one year later...

> <http://podcast.resource.org/rf-rfc/index.html#item0003>

Ha!   How about this new "Think" protocol?

 When you think connection-oriented transport services, think TCP! 
 When you think legacy protocols, think BOOTP! 
 When bandwidth is cheaper than memory, think MIME! 
 When you think impedence mismatch, think LDAP! 

Hilarious!

Anyway,  to the PlayPod radio host.  GREAT IDEA!!!  

How about getting some developer viewpoints in your shows?

Sincerely, 

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Wed, 02 Feb 2005 17:33:52 -0800

> of his relay IPs against "my" 512 IPs.

Today, mail is not checked for a path registration against some
mailbox-domain, and forwarding works as expected.  Now SPF allows any
mailbox-domain to be checked against path registration, according to
Schlitt's SPF draft.  As a result, there is no assurance that a specific
mailbox-domain was checked.  Recipients would be guessing which
mailbox-domain was used to authorize the message, assuming such
authorization was required.  The benefits of this process remains highly
dubious.

On the promise of a benefit, this scheme requires administrators to
institute a program of white-listing servers that forward mail on behalf
of their customers.  Such white-listing practices permit undetected
abuse, when these servers are excluded from the SPF rule-set (see
draft).  This system goes from some mailbox-domain may have been
checked, to perhaps none, even when there is an SPF policy in place for
the sending mailbox-domains.  Of course, there is the vast number that
still do not use SPF.

Forwarding of mail involves three parties, the sender-domain, the
recipient-domain, and the forwarding-domain. 

A) You want the sender-domain to register all servers used, which is
   not in keeping with the normal scale for a DNS response.

B) The recipient domain then must white-list all forwarding-domains
   based upon information derived from their users.

Once the recipient-domain also employs the SPF rule-set for accepting
messages, these forwarded messages may become lost or rejected.  Don't
forget about the change made with respect to HELO, where now even the
bounce may be refused.  The needed feedback to know there is a problem
may have been lost due to the zone-cut change.

Do you still insist you can list all servers?  You seem to be admitting
that you are leaving some of this listing work to the recipient-domain,
in that they must white-list forwarded accounts, some mailing-lists,
perhaps some hotel and network kiosks, etc. etc.  Why not admit that it
is _impossible_ to include the entire list?

> isn't good enough, maybe CSV could catch the remaining 512 IPs.

CSV does not attempt to include all the IP addresses for an entire
mailbox-domain, but instead limits a response to that of a single
server.  There is no difficulty created when more servers are used for a
very large domain, even spanning millions of addresses.  Each individual
response is limited to that for a specific server.  Even the DNS entry
does not deal with addresses, as this process is automated within the
SRV RR type. 

As a mail provider, the HELO could reflect which domain is generating
the traffic (with the cooperation of the sending domain).  If the desire
is to isolate accountability, then the HELO technique could satisfy this
need, while not breaking mail to the same extent as attempting to
constrain mail to some mailbox-domain/IP address binding.

Although this is a function provided by the sending domain policy, a bit
within the CSV record could indicate the HELO will "always" be within
the domain of the MAILFROM.  The reason not to make this assertion is
the same as why SPF should not make their assertions.  It would always
be a lie.  The difference is that CSV scales and could achieve the same
silly goal without abusing DNS.  : )    

> isn't "a problem created by the sender", it's simply the truth.

I would say it is only half of the truth.  The other half is the need
for random white-listing to keep from disrupting current widespread and
legitimate practices.

> solve this problem very quickly, otherwise they'd risk to lose

You may have authorized several providers to send mail on behalf of your
domain, and discovered a problem by way of a poor reputation assessment
or, even worse, your mail being filtered.  You will likely find it
difficult to learn where the problem originated and receive little
cooperation from reputation or filtering services, as they protect
sources.  The several providers may not care whether you remain a happy
customer when you ask them to do additional work.  Perhaps they only
consider Sender-ID a valid choice and you insist that logs be sorted for
SPF specifics.  After all, SPF/Sender-ID ensures the problem is yours
and not theirs.  Very likely, your recourse will be expensive and
perhaps futile.

> e.g. some existing policies use ? instead of + for shared IPs.

Providing a PTR list of CSV authenticated domains compared against a
mailbox-domain would achieve these filtering goals without hundreds of
DNS lookups, as potentially required by SPF.  There is much less effort
maintaining names than huge address lists, and this response would fit
within the constraints of DNS.

> its cheaper than SPF for this purpose.

Schlitt's SPF draft:
   There are several possible ways that [an] authorization failure can
   be ameliorated. ... Tests against some other identity may also be 
   used to override the test against the "MAIL FROM" identity.

If MAILFROM doesn't work, then try an assortment of mailbox-domains.
You can not say with any certainty, even for those following Schlitt's
draft, that a specific mailbox-domain was checked.  Some chain of trust!

> bogus "bounces to" me, so probably CSV would have done nothing

With a field not often checked, there is little reason to lie.  Checking
the HELO is not disruptive, as it does not affect the content of the
envelope or the message.  Using HELO to establish accountability
protects the owners of the mailbox-domains from being falsely accused
for having sent unauthenticated messages.  Unlike other entities within
the message, without a signature, only the HELO can be authenticated.
SPF assertions assume a fallacious "chain of trust."  Schlitt's draft
makes a mockery of that concept.  

> case where `nslookup -q=ns sub.dom.ain.example` fails to find

There were several reasons for not using the zone-cut.  There is some
blood on the floor regarding this topic.  Complying with the way domains
and zones are used, how software is structured, and what is reasonable
to expect of the server in some odd cases, were the major reasons in my
view.  For the most part, this draft is in its final stages.  The design
team wishes to present their finished version rather than a series of
interim drafts.  CSV is very much a team effort.

> Claiming that SPF causes mails to be lost is definitely FUD,

Odd, I would think that the mention of lost mail in Schlitt's SPF draft
would have removed the uncertainty and doubt.  I still think fear is
well advised. : )

> <https://antiphishing.kavi.com/events/Conference_Notes/sender_auth_myths_and_domainkeys.pdf>

I would be interested to know what you find in error, besides too many
slides. : )

> <http://podcast.resource.org/rf-rfc/index.html#item0003>

Marshall and Andy fail to consider anything other than path registration
in this bit of nostalgia.  They are consistent.

> report and log "local error conditions".

Let me remind you.  A lookup may entail several queries to resolve the
resource.  The timeout for each query typically involves a timeout of 5
seconds with perhaps 2 or 3 retries which double the timeout after each.
Waiting for a timeout to expire is how UDP is prevented from flooding a
network during congestion.  With the 101 lookup limit (higher for
reverse DNS resolution), should an implementation attempt to resolve SPF
in parallel, there may be many outstanding DNS queries not completed
when everything starts anew for the next message.  A slow DNS server
could entail an average of 3 queries per lookup which totals 303 queries
or about 25 minutes per message, without invoking a single timeout or
lookup limit!  This time could be more than doubled by using reverse DNS
resolution. : ( 

> considerations", now it's on the same level as say a "sigterm".

This view overlooks the need for UDP exponential fallback!  Think of the
network and not just the program.

> reason to reject the mail with a PermError, the sender policy

Why write a spec and then imply that it should not be followed?  Don't
you see a problem?

> to check any "mail from me" are too much just don't do it.

SPF does NOT prevent mail from being mistaken as being from you.  SPF
normally checks the MAILFROM.  MAILFROM is rarely seen by the user.  CSV
can authenticate the HELO domain, SPF can only determine that the
message has been authorized by a domain.

When one considers the need to stop spam, reputation is an important
aspect of that effort.  No reputation service should hold a domain
culpable just because a message had been authorized.  With the HELO
authenticated, any abuse will be attributed to the correct entity.  With
SPF, you are using a weapon that does not always shoot straight.  Unlike
SPF, CSV is as accurate as the underlying infrastructure.

> from the POV of "my" spammer) implemented it, it's not critical

Take the longer view and considering what is needed to improve security
and to better protect networks.  There will be less mess than what may
be created by the many potential exploits enabled by SPF.  Although SPF
may temporarily achieve some reductions in bounce traffic, BATV is a
better immediate solution.  MASS and CLEAR still represent viable and
well considered solutions.  SPF still should be discouraged.

-Doug