Re: [spf-help] Re: SPF and SenderID

----- Original Message -----
From: "Kjetil Torgrim Homme" <[email protected]>

> correct.  tying it to the MTA is what makes CSV deployable for just
> about any e-mail provider, whereas SPF in most cases require large
> changes both in infrastructure and in customer behaviour.

hmmm, I hate to get into dumb debates.  But I can't help myself.

CSV does not address the TARGET problem of malicious transactions.  It has
no practical value other than ENFORCE a new level of secured transactions
and this is only DOABLE within compliant systems.

In other words,  the problem is the bad people.  Not the Good people.  This
was proven over and over again by implementators and data research
organizations.  If you take any protocol and you analyze the results, you
will find that at both ends of spectrum, it will have low false positives
and low false negatives.  See  David Silver, VP of MarkMonitor presentation
at:


http://metahost.savvislive.com/microsoft/20050712/GS6_auth_scorecard.asx

In short:

    Bad systems do not comply.
    Good systems comply.

This is the fundamental issue that the "spammers, spoofers", etc, rely on.
What makes phishers a touch problem is that they LOOK like compliant systems
at the SMTP level.   This is part of the "middle" segment, the ones you
can't catch, that David was referring to and it matches with all our
emperical statistics we have done as well.

> >     If CSV uses "MAIL FROM" for reputation, then it has pretty much
> >   the same issue as any other proposal using that field.
>
> yes, I think it has been established by now that "MAIL FROM" can't be
> used without breaking e-mail or being vulnerable to replay attacks.

Not quite.

Our success with our AVS system is fundamental based on "SMTP compliance."

Over 60-80% of all transactions are BAD - that's a fact. there is no dispute
here and if anyone says otherwise at this point of time, they simply don't
know what they are talking about.

If SMTP requires that the MAIL FROM: be fundamentally required and correct,
then it should go without saying that it is INDEED a verifiable entity -
regardless of how you go about it and there are quite a few ways to do it.

This is different from the client domain (HELO/EHLO) where it is WRITTEN in
stone that it could be BAD and thus it not required to be correct for
accepting a transaction.   But even then, there are new levels of
consideration that one can implement for client domain validation - i.e,
domain literal compliance, local machine domain spoofing.

We will implement any GOOD idea and their many reasons we haven't
implemented CSV.  It just isn't a practical solution today.  However, that
does not say that a closed net or group of related mail networks (vendor to
vendor, etc) can not use it, but we already have ways to address trusted
relationships.  So it would be a WASTE of time to use CVS today.

Now if we totally revamped the industry and you enforced a new LEVEL of
client domain requirements, including A/R, then we can begin to use it.

But then we are still back at square one:

  - How to address the TARGET problem of legacy, non-compliant
    systems that the BAD people are basing their distribution on.

and that is the PROBLEM.  If it was not, we would not be here today.

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