ietf-mxcomp
[Top] [All Lists]

Re: CSV stake in the ground

2004-07-02 18:55:09

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

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







----- Original Message ----- 
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>; "MARID" 
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, July 02, 2004 3:47 PM
Subject: Re: CSV stake in the ground


On Fri, 2004-07-02 at 11:22, Hector Santos wrote:
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,

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
  bureaus,

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

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.

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.

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








<Prev in Thread] Current Thread [Next in Thread>