At 01:34 AM 6/23/2003 -0500, gep2(_at_)terabites(_dot_)com wrote:
[..]
>it has to do with "how spammers amplify their distribution channels while
>keeping costs nearly at zero" in Barry Shain's words.
Again, those trojans are propagated and installed primarily either by
scripting
and/or attachments. Restricting those e-mail features by default on a
"need-to-use" basis will eliminate at least the great majority of such stuff.
>I think that we had plenty of arguments both ways, and both camps are
>staying were they are. I would suggest that either you or someone else,
>write up a BCP or RFC, plus create some working code and get back to the
>group.
I'd be glad to collaborate with someone wishing to proceed with something
more
formal, particularly if there is funding for the effort.
BTW, both the IRTF/IETF are volunteer organizations. Funding is not
expected here.
Also, I would like to point something out here. This discussion has dragged
on for quiet a while, partly because people have confused your proposal
with regular HTML blocking. Your proposal does not advocate straight out
HTML blocking, rather developing a system where the receiver can give
senders permission for sending HTML email after the initial ASCII email
went through. In another words, you are seeking to develop a system where
receiver of email can give block incoming email based on certain rules (in
your case HTML, attachements, etc.) and give permission to those senders
that he knows to allow the stuff to come through. How is this different
from the following statements:
"Therefore, we generalize the problem into "consent-based communication".
This means that an individual or organization should be able to express
consent or lack of consent for certain communication and have the
architecture support those desires. "
What you are seeking to create is a consent-based system - a system that
blocks email based on certain rules and allows the receiver to express
consent for certain senders. This is the goal of the entire group as stated
in the charter. In your specific proposal these rules would be HTML,
attachments, etc. - in C/R systems this would be all senders that are not
whitelisted. The underlying concept is still the same - there is a need for
a consent-based system.
There are other aspects of your proposal that are outside this
"consent-based" system such as plain HTML blocking, need to educate
software creators on the dangers of default HTML settings in email clients,
etc. These goals can be accomplished by creating a site similar to the "Web
Standards Project" (http://www.webstandards.org) like I had mentioned in an
earlier message to Vernon.
Now keeping that in mind and the fact that the group is chartered to
created such system, we should start discussing this on the list. Among the
collaborative effort of the people in the group we can come up with
something useful.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg