[Top] [All Lists]

Re: Has the IETF dropped the ball?

2005-03-10 06:09:25

----- Original Message -----
From: "David MacQuigg" <dmq(_at_)gain(_dot_)com>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, March 09, 2005 6:39 PM
Subject: Re: Has the IETF dropped the ball?

That is my view of the future, anyway.  For the topic of this thread,
however, it doesn't matter if I am wrong on this.  If all we get is the
elimination of phishing scams, that is reason enough to move ahead, and
work out a standard that everyone can live with.

-- Dave

My view is that you, among many here, are missing the boat of the real

I think this says it best:

"We build up whole cultural intellectual patterns based on past 'facts'
which are extremely selective. When a new fact comes in that does not fit
the pattern we don't throw out the pattern. We throw out the fact. A
contradictory fact has to keep hammering and hammering and
hammering,sometimes for centuries, before maybe one or two people see it.
And then these one or two have to start hammering on others for a long time
before they see it too . . . Seeing is not believing. Believing is seeing."
                      "Zen And The Art Of Motorcycle Maintenance"

What is the fact?

     "60-80% of the transactions are non-SMTP compliant transactions"

We choose to ignore this fact because we still wish to allow non-SMTP
compliant senders to exist: The backward SMTP compatibility dilemma.

Every idea will work to a "degree" but it is completely useless if you still
have to deal with the non-compliant sender.   Note I said, sender, not
spammer.  That is the key.  SMTP must view all the same - even if you are
not spammer, if you are non-SMTP compliant, you need to be rejected.  That
is the only way will get adaptation.  Only with chaos comes change, and
hence a new stability.

A few years back, that would be an unrealistic situation.

Today, it is more realistic.  Legitimate senders with poor setups know today
what is at stake.  For many, it will be a simple matter of a configuration
change.  For others, they might need to update their software.   Those who
resist, well, they will feel the pain.  The point is, there is no reason to
resist.  They know what is at stake.

What makes it even more plausible is this a very small percentage.  Today,
most people do run good setups.  The only segment, the largest one, who will
not complain to you, is the 60-80% of the senders with malicious intentions
in mind.

We all know what is at stake here. If reasonable solution existed, it would
of been done.

But it is the legacy and non-SMTP issue that is really keeping all this from
becoming a reality.

It is a mindset issue among the cogs that we need to change. I've been in
the mail business since atleast 81 and we always knew there was this SMTP
loophole.  But it wasn't deemed a big issue then and wasn't a big issue
until atleast 1992-94 and even then the mindset was still ignorant of the
nature of the problem.  Prior to 1992-94, most people was associated with an
dial up ISP at relatively low speeds.  The damage was extremely limited.
That has changed.

Mind you. I'm was part of the stubborn mindset too. My philosophy was that
it was an administrative policy to control problematic mail.  We just
delivered it to you.  I didn't do anything until I was personally affected
by the SORBIG eVirus in 2003, not on my system, but on other systems,
falsifying my identity.  That is when I said, enough is enough.  Something
had to be done at SMTP.

You really didn't see the big efforts begin until SORBIG exploited every
aspect of the SMTP process and also exploited the fact there is a vast
network of legacy SMTP sites that are still thinking in UUCP/SLIP mode with
continuing their POST SMTP/Gateway processing.

Most modern systems have move much of the gateway validation process into
the SMTP level and those system that use SMTP validation have a greater
protection from the SORBIG like attacks.

So if you want to champion a cause to get something going,  you will need to
address the legacy/non-compliant SMTP fact that is being thrown out by the
IETF cogs because it conflicts with the old patterns, a pattern that really
doesn't exist any more or isn't fixable or isn't going to be fixed today

This is very lost cost, first level approach that will have a significant
impact in helping secure the SMTP transaction.  Once it is the norm, the new
email authentication/authorization proposals will be easier to implement
with greater reliability.


Hector Santos, CTO
Santronics Software, Inc.
305-431-2846 Cell
305-248-3204 Office