On Wed, 05 Mar 2003 17:00:33 -0500 "Alan DeKok"
<aland(_at_)freeradius(_dot_)org>
wrote:
Alan, your msg helped me understand better that "path verifiability" may
be a big part to this problem... just as postal services add origin
stamps, phone companies provided CallerID, the 'net has similar
verifiabilty already spec'ed... the recipients could take a large amount
of control back very simply: enforce path verifiability. Once the path is
verifiable, much spam will crawl back into its hole, IMO.
"Gary Feldman" <gaf(_at_)rtr(_dot_)com> wrote:
1. On the use of "Consent-Based Communication"
The charter begins by arguing that spam is not well-defined,
and therefore moves to generalize the problem with consent-
based communications. Let me first observe that based
on the discussion here, the definition of consent and consent-
based communication isn't clear enough.
Everyone talks about "consent" in relation to the end user who
receives email. The other parties in the process are ignored.
When someone installs a broken piece of software which can be abused
to send spam, did they consent to such abuse?
Explicitly, no. Implicitly, arguable. Knowingly continuing after
discovery/notification, yes.
When someone receives email with forged 'from' lines, did the other
domain consent to that forgery?
Hmmm... ignoring the legal realities, would "Wire Fraud" be applicable?
However, this is a content/payload issue; just like someone using forged
letterhead -- it's not part of the "path".
When someone receives email from another site, do they consent to
accepting any kind of lies or deception embodied in that email?
I block at connection/envelope stage, so if my path filters fail, implicit
yes IMO. Successful delivery just means someone sent me "data" (aka
content)... truth vs lies vs misinformation at this stage is a rocky
road...
The answer to all of these questions, I believe, is "No."
Partially disagree for above reasons.
Achieving
consent-based email for these parties will *not* involve content
filtering, and will get rid of probably 90% of the spam.
[Not sure I fully grok this as written...]
While there are those that argue for anonymous communication, my attitude
in denying anonymous person-to-person (or *-to-person) mail is that an
anonymous sender simply wants to shove something down my throat without
allowing or informing me how to respond... the only places I accept
anonymous senders are on mailing lists and news sites... there, it's my
choice to participate... if a sender doesn't allow me the option of a
2-way communication**, I don't see why I should extend any open-arms
courtesy to him/her/it.
** since everything can be forged, my rules are that everything I *can*
confirm (IP, DNS, rDNS, not open-relay, dest_userid_exists, etc) *will* be
a requirement. Access to my mailbox is freely available (my courtesy);
though, as in a contract, in return for this priviledge, I only ask for
the ability to confirm that the communications path is somewhat
trustworthy -- if a sender insists on hiding or lying about the path, then
the message must by association be highly suspect. Such sender will have
to convince me via a more trustworthy path to allow the untrustworthy
path... good luck.
The left over spam will come from people who publicly admit that
they consent to sending spam. Everyone else can individually agree
that they do *not* consent to receiving email from such people. (But
that's a political decision, not a technical one.)
Do it how you like, I chose the technical one for now since it works for
me.
A goal of this group should be updating the technology to allow
people to have informed consent, and to make informed decisions as to
which email satisifes their political or ecomonical objectives. The
current lies and deception which are permitted in SMTP do not allow
these sort of informed decisions to be made.
If you've already received the spa^H^H^H^message, then as Dr. Race stated:
No proposal will gather public acceptance which is based on
the "make the victims pay" model.
The burden is rightly on the owners of the open relays, not on
their victims.
I don't limit the burden to open-relays... everyone, to the best of my
ability, owns the burden of using properly identifiable communications
paths. IMO, it eliminates the "90% of spam" I would have gotten, the
rest are using proper paths; but if they lie in the content, they are
added to my personal blacklist... could it be easier to do this, sure...
but again, this is not part of the "path verifiability" which everyone has
access to... I wish everyone just enforced that part of the problem
space...
Instead, we have ad-hoc filters, which try to insinuate someone
else's intent, or consent, by doing content-based filtering. That
doesn't scale.
Agreed; and the reason I don't use/like content-filtering (other than the
most obvious headers).
We still need a way to identify policies - and
that means coming up with some sort of meaningful definitions
for spam. The trick is doing so, without forcing a single
definition of spam down everyone's throat.
Sure. Multiple definitions would help. A start could be:
"Spam is AT LEAST any email which is not intended to be sent from a
network."
e.g. Unknowing open relays in schools in Korea, abused by people in
the U.S. If it was legitimate email from Korea, then the 'from' line
would be from the school. If it was legitimate email from someone in
the U.S., then they could send the mail directly themselves.
So let me propose a framework: Spam, as indicated in the
charter, is loosely defined as unwanted email.
Unwanted by who? Odds are often that the administrator of the IP
sending the spam doesn't want it, either.
At this point in time, arguing about the appropriateness of
any particular category (whether intuitive or formal) is
inappropriate. Rather, the point is to establish the structure
in which those categories can be documented and analyzed.
I agree. Proposed solutions to a vague and ill-defined problem
aren't helpful.
I get the impression it's ill-defined to those who are still getting tons
of spam... those of us who are enforcing the simple rule: "you must use a
verifiable path before I accept your mail"** are still open to spam; but I
assure you, it's already >90% less than we would be getting otherwise...
** I live in the US, so for me, the USPS is the only verifiable path to my
P.O.Box... the spam that arrives there has a valid return path (at least
to the originating P.O.; even uncancelled mail *could* be traced) for the
simple reason it's "sender pay".
If you want to send to me directly and the path is not verifiable, *we*
can address this with our providers.... keep trying to get your mail
through to me, and I will send the bounces to the provider as best I
can.... over time, my experience shows the legit ones *do* relent and make
the path verifiable... However, if you are a spammer, your provider will
feel my pain, no more... this too has worked for me...
In particular, it is a legitimate question to ask whether the
technology can and should play a role in aided the encorceability of
legal sanctions, e.g. can and should the technology make it easier
to find someone who violates an anti-spam law.
I would say that the technology should make it possible to make
informed legal decisions. Tracking down a spammer is just one part of
that process.
Simply enforcing verifiablity of the communications path goes a long way
IMO.
The charter say very little about the premises or constraints
of what falls within its scope. The current set of discussions
indicates that many people are working under the premise that
existing (low-level) functionality must not be changed, or other
assumptions about approaches that would be out of bounds.
I know I would appreciate it if people made their assumptions
explicit.
My assumption is that the path verifiability is already spec'ed and
implemented, just not fully, reliably and enforcibly deployed...
enforcing this verifiability will not prevent From: abuse; but that's a
*payload* issue; just as the USPS doesn't get involved in the content of
the mail they transport.
Furthermore, individual subsolutions should be evaluated in the
context of a complete solution strategy.
... within a well-defined problem space. I'm not even sure we have
that.
IMO, we are trying to encompass solutions to parts of the problem space
that already have a solution: path verifiability is the big one, the way I
see it.
But I think you've made a good start on narrowing the discussion.
I'm new to this list, so I'm reserving judgement... :^)
Pierre
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg