I'm farily new to this list (but not the issues and problems), so if I say
something that's allready been hashed over, please be gentle with me...
:-)
I've seen several messages over the past few days that exhibit in various
degress part of the following sections I'll quote -so my focus is not solely
no this particular message or text.
On Fri, Mar 28, 2003 at 02:49:10AM -0500, John R Levine wrote:
People can ask for any e-mail they want. That's a real and useful
choice.
Indeed, but not one in this protocol proposed.
But in the end, I see this banner as effectively equivalent to writing
into SMTP, "Senders MUST NOT send UBE"
Which might indeed be what most people want, but it's not for the IETF
to do, and as you point out, it's not that meaningful without a law behind
it, which is also not for the IETF to do. The IETF defines protocols that
lets users specify their choices.
To be extremely blunt on this - while the intent of laws are all well and
good (which I do support), relying on them for real world impact is not
practical. It never has been and never will. Enact as many laws as you
want it whatever juristdiction you happen to be in, and the bad guys will
simply move elsewhere. I happen to be at the moment in Hong Kong. Why
should I be concerend with laws in the US or Europe? And if it gets to the
point where I would be, I can simply move my bad guy operation to a
neighboring country, pay off the law enforcement people, and I'm in business
indefinitely. Without naming any names, trust me on the later - it is the
reality in many places. :-(
The vigalante nature of most of the blacklist organizations brings their own
set of problems that are well known to most here.
It seems to me that our best hope for a solution is in a group such as
this - however we are not dealing with problems as black and white (at least
in technical terms) as most other IETF groups work with. Coming up with
things like the MIME and DSN recommendations was pretty black and white as
an example - most issues were purely technical. Not the case with SPAM.
My preference would be to rephrase your last comment as "The IETF should be
defining protocols and solutions to let users solve real problems." The
difference is that the scope is a bit wider here - and can encompass areas
not specifically covered by protocol design.
Well, you know I have many thoughts on these issues, but I will refrain
from
going onto them on this list, where I prefer to discuss the merits of
engineering solutions.
I'm not sure what you are trying to imply here. Most engineering designs
have to take into consideration the technologies available, their costs, and
at the end of the day build something that works for people. It's the
later part of the equation that is most often the most difficult, and most
certainly the case here.
The engineering question here is, "Do users need a way to refect their
UBE preferences during the SMTP dialog, and if so, how should they be able
to do it in a way that meets their desires." I'm not sure a basic banner
would meet that test, but the concept can be explored more. However, it's
only really meaningful in the concept of law.
It has already been shown that the bad guys have no respect for protocol or
laws. Hey, we've even had one spammer recently that we uncovered that was
simply ingoring all the SMTP failure codes (after we detected they were a
spammer), and simply continued blindly along sending the message. I think
we do a disconnect now rather than continue the SMTP dialog, but it just
goes to show that SMTP extensions will not be effective for those you are
trying to pull the reigns in on. These are not your normal law abiding
citizens, and never will be, so don't expect for them to conform to
standards or recommendations designed to keep them out.
Any sort of opt out or tagging rule or any other limit on spam is
meaningless without a legal stick to whack violators, so I don't see
much
point in defining constructs that have no chance of having the necessary
stick attached.
Well, that's certainly true, though in fact this does not require the
congress. For example, ISP TOS can and do have the ability to cut off
users for sending traffic that is in violation of protocols. In many ways
it can be clearer than just the no spam rule.
To be effective, solutions need to be devised that do NOT rely upon legal
enforcement for the reasons cited above. If you don't believe me, check
the archives of many of the anit-spam lists that have discussed this over
the past several years. This is not a new concept - in fact many have
believed it to be the silver bullet to enforce policies, however time and
time again it has been shown to be a false assumption.
On the nearly-technical side, I am also concerned about how much success
there
will be in defining the terms. Some what Solicited to be implied on a
pre-existing
relationship (possibly with a "respect unsubscribe requests" rule) and
others
want solicited to mean explicit subscription. I would hope they can be
reconciled. And there are arguments on bulk in either case and where the
cutoff should be, though in truth all low cutoffs are probably enough to
solve
the spam problem -- if they were obeyed. Alas, I have poor faith on any
of this being obeyed. As you know, a significant fraction of the spam
sent today is already illegal under non-spam laws --- fraud, illegal
medical
sales and all the rest -- so I see little hope in those spammers obeying
the No-UBE sign we might hope to put up on our mailbox.
Exactly! To expand on this, it is my opinion, despite how hard it is to
come to consensus, that a common definition of what we believe SPAM to be is
established. Everyone has their own definitions, from the DMA, to those
that think that anything they were not expecting in their inbox (regardless
of content, sender, or any other criteria) would be considered SPAM. A well
understood definition needs to be established before a system to deal with
it can be properly designed. Otherwise, how will you ever know if you've
reached your goal, if the target keeps moving?
Anyway, hope I've not strayed too far off topic here - if so, please be kind
in your rebuttles... :-)
Best Regards,
-- Tim
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg