Subject: CSV stake in the ground

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Jul 2004 10:37:51 -0700

Rough consensus and working code...

I would like to put additional resources into CSV.  Should I be
confident these documents will not dramatically change?  It will become
a much prolonged time line (and wasted effort) if this devolves into a
debate how an SRV DNS record could be defined using a TXT record.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 2 Jul 2004 14:22:43 -0400

For what its worth,  as CSV stands today, it is difficult to endorse it or
warrant any further for product consideration or implementation for the
following five (5) simple reasons:

- Potentially high (unnecessary) SMTP redesign issues,
- Has higher than required SMTP compatibility conflicts,
- Potential customer acceptance (PR) issue regarding fee-based service
bureaus,
- Overall, the change vs. benefits offer no advantage over what SPF can not
offer. and
- You, nor Dave have never answered my comments/questions.

I don't care about SRV vs. TXT, that's a DNS admin thing.  But either way, I
will be looking to optimize or minimize the total number of lookups.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Jul 2004 12:47:58 -0700

> - Potentially high (unnecessary) SMTP redesign issues,

CSV is proximal to the current use of RBL.  I do not envision serious
design issues.  The concerns raised are being addressed by Dave Crocker
and John Leslie.  You are right in that StartTLS, as used today, is not
relevant, but to simply cover the topic of public or open authentication
and authorization techniques, these methods were mentioned.  You are
right, more information is needed, and it will be forth coming.   

> - Has higher than required SMTP compatibility conflicts,

CSV virtually leaves SMTP unchanged.  CSV requires only careful
placement in the SMTP session process of where the CSV checks are
applied.  CSV makes the least change to SMTP compared to other
proposals.  It does require the host name be valid, but I would not
describe that as a major change.  The intent of CSV is to remove reasons
permitting this lapse in host name validation.  SMTP requires the check,
it just currently forgives an unsuccessful result.    

> - Potential customer acceptance (PR) issue regarding fee-based service

Accreditation bureaus exist today and are responsible for preventing
many more times that not seen than the amount that is seen.  The cost of
these services is highly dependent upon efforts needed to vet these
accreditations.  In addition, use of names is a positive alternative
that will help those currently hampered using dynamically assigned
addresses.  That which remains is difficult to deal with on a per
mailbox basis, but having an authorized and authenticated domain that
provided access for such user may become a powerful tool for enforcement
of criminal activity.  Controlling access is the only means the mail
system will improve. SPF does not impact that aspect of the problem at
all.  In fact, SPF can not assess the source of abuse, or accredit any
provider for failing to ensure security.  Only through accurate
accreditation is this possible.

If you do not use any accreditation service, you still benefit.  Through
third party assessment, providers learn of abuse and where security has
been violated.  Again, SPF offers little or no help in this area.  Do
not expect spammers to take very long to adapt to any SPF deterrent and
likely find the means to totally defeat any SPF limitation that you wish
to see imposed.

> - Overall, the change vs. benefits offer no advantage over what SPF can not

SPF will always allow spammers to leverage any domain that publishes an
"open" list, including their own domain.  Those that publish such a list
may find their addresses spoofed heavily and their DNS servers
overwhelmed. Their reaction to this problem would be to either "close"
the list or remove the SPF record entirely.  Those that "close" their
list may find their mail lost in transit, if it takes a path not
published, perhaps through no fault of theirs.  As SPF never holds a
service provider accountable for their exercise of policy regarding
security, SPF can not ensure even those that publish a "closed" list
will stop seeing their mailbox spoofed.  As SPF is very susceptible to
DDoS, it may well be disabled, leaving victims a false impression based
upon these defeated SPF assurances.  Unlike CSV, SPF _DOES_ require
extensive SMTP design changes.

> - You, nor Dave have never answered my comments/questions.

Remember, Dave is on vacation and much of your concerns addressed his
document which he promised to update.  Perhaps you could factor that in
to your concerns.  You have been prolific addressing your concerns and
my understanding is that Dave has difficulty finding reasonable
bandwidth to permit direct access to these lists.  Give him a chance to
respond via the update at least.

> will be looking to optimize or minimize the total number of lookups.

The TXT record examples often assumed additional lookups would be
required by simply placing a free standing a in the TXT record.  On the
face of it, this may appear to be similar to the function of the SRV
record, it is not however.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 2 Jul 2004 21:55:29 -0400

Doug, Dave,

Your message is greatly appreciated.  I would like to apologize to all,
especially to Dave, for any impatience behavior exhibited by me.

Just one clarification and one report of a very important news event that
has occurred today directly related to CSV, and a follow up question related
to the report.   It may change or reinforce some decisions.

Clarification:

I am not against DNA. I'm a capitalistic vendor too. :-)  I did understand
your intent to allow this part of  the process to be flexible and a "plug
and play" concept including with RBL.. I was simply noting the major
consideration as to how it is introduced into a commercial product line.
One of many example issues related to customers will be marketing: "Great
new ANTI-SPAM feature" with an asterisk footnote that says "Required
batteries (DNA service) not included" etc.

Report:

I have a private address home DSL account with bellsouth.net, a large ISP, I
would say.  They used the current connection machine IP address to authorize
"anonymous sender" (I can use any MAIL FROM: address) relay/route access.
SMTP AUTH was not supported hurting legitimate roaming users.  Their reason:
It allowed users to share ID/passwords with friends or to spam from any
machine.  However, this didn't jive with the idea that the same account info
is required for POP3 which can be used from any machine.  (I know of no POP3
server that uses only an IP for access, do you?)

As of July 13,  Bellsouth.net will require all users to use SMTP AUTH to
connect to their servers.  .  Part of their announcement is below.   My
question to you is this:

I need to check this out more, i.e, are they still locking the IP and
requiring SMTP AUTH as well, but assuming CSV was available today and it was
a technology that Bellsouth.net was expose to and could implement, how would
they use CVS in lieu of SMTP AUTH?

Announcement from Bellsouth.Net:

....

This spam fighting upgrade to the BellSouth e-mail service requires you to
make a small change to your e-mail client by July 13, 2004.  This change
must be made to each account that uses your e-mail client program.  These
accounts include any account you have that ends in @bellsouth.net as well as
accounts from other ISPs, such as yahoo.com, msn.com, etc.  The change is:

  a.. Add additional validation to your existing e-mail account.

Your e-mail service will also now require additional validation to promptly
send your messages from the BellSouth network.  We ask you to check the box
in your e-mail properties that specifies ‘My server requires authentication’
and enter your e-mail account password in the appropriate field.

...

This change applies to all customers who send their e-mail with an e-mail
client through the BellSouth e-mail servers at mail.bellsouth.net.

...

If you do not ensure this change by July 13, 2004, after that date, you will
be asked to enter the account password each time you send an e-mail.  These
changes will be required in order to send e-mail with our enhanced
protection.

Thanks

---

From: Dave Crocker <[email-masked]>
Date: Sat, 3 Jul 2004 11:46:35 +0800

Hector,

HS> For what its worth,  as CSV stands today, it is difficult to endorse it or
HS> warrant any further for product consideration or implementation for the
HS> following five (5) simple reasons:

HS> - Potentially high (unnecessary) SMTP redesign issues,

CSV does not require any redesign of SMTP.  None.

HS> - Has higher than required SMTP compatibility conflicts,

CSV has no compatibility issues with SMTP.  None.

HS> - Potential customer acceptance (PR) issue regarding fee-based service
HS> bureaus,

I cannot seriously guess what you are talking about.

It seems to have something to do with business models, but there is
nothing about CSV that prefers or limits choice of business models.

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

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 4 Jul 2004 05:56:53 -0400

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "MARID" <[email-masked]>
Sent: Friday, July 02, 2004 11:46 PM
Subject: Re: CSV stake in the ground

> CSV has no compatibility issues with SMTP.  None.

Dave,  I believe it all depends on what your team (and yourself) finally
conclude on how CSV is going to behave.  As it is stated now, you have many
issues that make it problematic to implement.  Do I need to outline them?

> nothing about CSV that prefers or limits choice of business models.

Dave, I clarified I have no problem with this.  But I am surprise to read
you don't see the implications this has for commercial mail server product
vendors, and quite probably, even more with non-commercial developers.  This
might all depend on the availability and type DNA services available.  If
its only going to be MAPS,  we might want to get an arrangement with them to
help promote it.  But I would like to see more DNA services available before
committing time, money and resources to CSV development.   That would be
just the few of the many other issues that will crop up.    In short, CSV is
not just a basic plug and play technical solution.

Thanks for writing.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Jul 2004 19:53:24 +0700

Hector,

HS>   As it is stated now, you have many
HS> issues that make it problematic to implement.  Do I need to outline them?

yes.

but not for several weeks, since the chairs have asked that CSV
not be discussed right now.

HS> n  But I am surprise to read
HS> you don't see the implications this has for commercial mail server product
HS> vendors,

I see the implications quite well.  What I said was that CSV does not
constrain the busines model choices.

HS>  But I would like to see more DNA services available before
HS> committing time, money and resources to CSV development.

One of the business decisions available is to wait for others to lead
the market.

d/