ietf-asrg
[Top] [All Lists]

Re: [Asrg] 2a. Analysis - Developer Perspective

2003-09-12 14:10:25
Dear Hector,

I understand your frustration and I am sure that it is shared by many others here and on the rest of the Internet. However, the developer's perspective is not what is needed here, you also need the designer's perspective.

The designer looks at the overall Internet infrastructure and the spam problem as related to that infrastructure. While the developer jumps to writing code and implementing solutions, the designer takes his time looking at the overall structure and how everything else might affected by the code to be written. We cannot mandate sweeping changes, we cannot change the SMTP protocol overnight, we cannot force millions of people and companies switch over to a "perfect" system at the tune of billions of dollars, euros, rupees, etc. We cannot do anything unless we analyze how it will affect every aspect of the Internet and its users. We are responsible to all of the Internet users on this planet, we maintain the Internet and keep it operating. This requires very careful analysis of any changes to the underlying protocols and standards on it.

There is a reason why no specific proposals are being concentrated on - we do not have any way to evaluate them. The technical considerations document (http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt) outlines many of the issues that will face us in this analysis. However, most developers want to jump straight to code instead of analysing the impact of it on others. That is why so many efforts must be concentrated on analysing the problem because that is necessary for the analysis of proposals.

Therefore, I would like to suggest that our concentration should be on getting some documents out the door on the problem of spam, and how to analyse and evaluate solutions. The technical considerations document, the requirements document, the inventory of problems, the analysis of spam, the consent framework, the proposal guidelines, the evaluation model, etc. all of these need volunteers. If you want to kill the problem, that this analysis must be performed. If you want an overnight solution - stop looking - it cannot be found.

If you would like to continue this conversation, please email me off-list.

Sincerely,
Yakov Shafranovich
Co-Chair, ASRG


Hector Santos wrote:
<snip>
Hello everyone,

I'm going out on the limb here.  So everyone with a heart,  please don't
jump on me, I'm just providing my technical opinion here.   This is a little
long winded, but its done with a purpose, hopefully with goal of reaching
people (especially developers of mail software) who feel the same way I feel
to finally address the spammer problem once and for all.   So brew of pot of
your favorite coffee, a smoke or whatever you do that relaxes you.

I recently learned of this group via a cyber space article who were talking
about what efforts are being done to combat the growing spam problem.  The
article was talking mostly about the basic approach of various method filter
methods, but it concluded with a statement that the solution may also
include a fundamental change to the SMTP system being orchestrated by the
new AETG.

"Finally!  YEEPEE!"  I said!  Finally, we are getting to the heart of the
problem instead of all the kludgy filtering solutions that a) didn't work,
and b) to a large extent played into the hands of spammers.  I wanted to be
part of this process that will fundamentally finally change the outdated
SMTP system!

So I wrote Yakov and others with eagered baited breath telling them I want
to HELP!  We have a pretty big commercial system but I didn't really tout my
own horn.  I wanted to really be part of the process to help define the next
generation software.  So I joined this group with one and only one goal in
mind, to help change the outdated SMTP specification in such a way that
would immediately stop the spamming problem.

Unfortunately,  what I found here was a little disappointing.  I was little
lost with whats going on with this working group.   Instead what I saw here
is a slew of proposals which to me, basically beats a dead horse and will
not solve the problem.

It makes no sense to me to study or analysis the "patterns of spammers" or
what techniques they use, etc, or what "tricks" they have up their sleeves,
or hearing what spammers had to say in this group. All I saw here weree
efforts that attempt to "play games" spammers using filters or other items
that is basically playing into their hands.   Sure, we can learn about them,
but does it solve the problem?   I don't think so.

In the end, working solutions will be based on what the software developers
and vendors  see as clear, sound technical design solutions and more
importantly,  they will only allocate resources that addresses and solve the
main problem head on.   They are not going to implement dozens of these
proposals.  They will see the best and work with that.

To me, we know what the problem is - the SMTP specification!  We change it
and the problem is essentially solved!

Sure, absolutely!  I understand the "spirit" of the internet of keeping a
open standard and the resistance to deviate from the current standards.

However, it is this "spirit" that we need to let go and admit where the
problem of spams really lies and ultimately, the solution will need to be
finally be based on the fundamentals of the solid mail distribution system.

I say this because of past experiences with standard mail systems that
resisted change.   If things don't change, further chaos will evolved and
ultimately, may threathen the very existence of the SMTP protocol, including
any say this IETF working group may have.


<snip>


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg