ietf-mxcomp
[Top] [All Lists]

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

2005-02-01 18:04:31

On Tue, 2005-02-01 at 16:42 -0500, Hector Santos wrote:
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.

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.

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.

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.

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