[Hector Santos]:
From: "Kjetil Torgrim Homme" <kjetilho(_at_)ifi(_dot_)uio(_dot_)no>
> 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.
oh well, one man's dumb debate is enlightening for others (such as me :)
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.
I don't think anyone believes that CSV will be much help in the
struggle against spam, but it will help establish clearer
responsibilities and accountability. we already reject half a million
delivery attempts daily based on bogus HELO values. CSV will increase
that hit rate (probably not by much, though), and remove some of the
ad hoc rules in our system.
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.
that's not what I heard in the above talk. smart bad systems comply,
too. one example from the talk is that both "pfizer.com" and
"pfizre.com" publish SPF records.
the talk also emphasises a number of problems with managing SPF for
corporate users, e.g., coordinating the use of multiple domains across
departments. this is interesting since CSV and DKIM has no problems
with this and allows easy delegation of responsibility.
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.
yes, until we get full deployment, the middle section will be a
problem. this is why it is critical to agree on a standard which is
deployable by everyone.
> 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.
no disagreement here!
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.
sure. I was talking about going _beyond_ SMTP. we require the domain
name used in MAIL FROM to be e-mail routable (ie. have valid A or MX
record). you might say this goes beyond RFC 2821, but in any case
there is no need to formalise this behaviour. I think most will think
it is the natural thing to do.
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.
exactly, which is why we need an explicit method to cover for the
lee-way RFC 821 provided.
We will implement any GOOD idea and their many reasons we haven't
implemented CSV. It just isn't a practical solution today.
do you have any technical problems doing it?
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.
CSV is still in draft, so I understand fully that you're holding off.
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.
CSV will help somewhat (see number of bad HELO above), but DKIM is
much closer to be a solution for that problem.
--
Kjetil T.