RE: [Asrg] Too much of too little (Was: Taking a step back)

I believe there has been far too much discussion generally, without 
reflection and thought... and far too much has been said about 
specific applications.
The emphasis here should be on creating guiding principles... simple, 
clear, brief guiding principles... not code nor zealous defenses of 
unmeasured techniques.
Unwanted e-mail is an old problem. I see no reason that there should 
be an agreed upon solution in a week's time. I've been involved in 
the "spam problem" since Canter&Siegel and have tried to be work in 
other groups like this on, every one of which degenerated into 
application wars and semantic battles about "what is spam" and so on.
What is missing is the guiding principles, the catalog of approaches, 
carefully considered and then summarized discussion of each, and 
empirical evidence pro and con... Everyone may not agree on what 
those principles should be, but they are probably collectively 
tree-shaped and as they fork, individuals of varied opinions could at 
least determine where they stand in their beliefs and with whom, but 
would then be expected to defend those beliefs with some hard 
evidence - applications and the results of real testing and analysis.
The problem is not "spam" - someone in this mess of noise wrote a 
very good definition of what the problem is. For me, I fall back to a 
phrase from the US Supreme Court and picked up by privacy advocates: 
"The right to be left alone."
An opinion of whether some message is or is not "spam" may very from 
person to person, and individual tolerance levels may vary, thus an 
individualized solution is needed.
Yet some things, particularly high-volume, error-packed mail blasts, 
may be "spam" in the eyes of an ISP due to their impact on networks, 
thus a server-based solution is needed.
And clients and servers may only have incomplete information, so 
client-server collaborative approaches may be needed.
And some "spam" is only detectable via a worldview that no single 
server can have on its own, thus interop between servers/ISPs may be 
needed.
Will one "agreement" solve all of this? No. But neither will more 
headstrong efforts to just dive in and start writing code. The 
problem tangles social, political, economic, historical and 
technological matters. We will not fix it by jumping in and writing 
applications, nor by trying to yell the loudest.

- Jim






At 16:21 -0500 3/13/03, Jason Hihn wrote:
> Bah, I give up.
>
> Looks like I'll be relying on the Bayesian spam filtering in the
> just-released-today Mozilla (v1.3). So much for reclaiming band width, I'll
> just route spam to /dev/null because the client makers are much more willing
> to take a stab at the problem than the server admins (who ironically are
> suffering more).
>
> You (We) all are never going to make any progress at this rate. No one wants
> to adopt anything. No one wants to do anything more than bitch about it. It
> must not be a big enough problem then.
>
> You're going to have to make a commitment to SOMETHING SOMETIME. Jesus,
> anything is better than what we have now. If you don't want to commit to
> something then stop bitching and lay in the bed you made.
>
> I think sender verification should be started. It is easily implemented and
> we can stand to have significant gains rather easily. Even if we want to use
> the RCPT-TO hack in the short term.
>
>
>
>
> >  -----Original Message-----
> >  From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu 
> > [mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
> >  Sent: Thursday, March 13, 2003 4:13 PM
> >  To: Jason Hihn
> >  Cc: 'ASRG'
> >  Subject: Re: [Asrg] Taking a step back (Was: Proxy your address)
> >
> >
> >  On Thu, 13 Mar 2003 15:03:58 EST, Jason Hihn said:
> >
> >  > Note: This should be considered different from a simple RCPT-TO
> >  check. While
> >  > easily implemented as such, it can be used to validate an
> >  address (violating
> >  > #0) IMHO RCPT-TO should not ever return an error until after
> >  the socket is
> >  > closed. Then when it goes to return an unknown mailbox error, it ends up
>  > > doing a verify of the From address. This does several things. 1) It will
> >  > prevent unnecessary error messages being sent back to a no-good
> >  address. 2)
> >  > It will slow/prevent address receiver verification.
> >
> >  So.. instead of giving them a '550 Piss Off' right then and there, you
> >  go to all the effort of queueing it to disk and verifying the From:
> >  afterwards, and then finding out that you can't double-bounce.  Really
> >  bad if you're being spammed by 100K things in a dictionary attack...
> >
> >  And this is a messy situation - you have to be able to distinguish between
> >  double-bounces that should go to the postmaster because there's a real
> >  problem, and spammer double bounces.  Silently dropping all double
> >  bounces is a bad idea...
> >
> >  > verifies your email address before it sends out the image. Can
> >  we come up
> >  > with a standard that requires all images (any binary content
> >  really) to be
> >  > embedded? My preferred email client has a check box to "not load remote
> >  > images in mail", which works for me, but I fret over people
> >  whose clients
> >  > aren't so careful.
> >
> >  Let's note a few things:
> >
> >  1) This is (as you noted) really an MUA issue.
> >
> >  2) There's often legitimate uses for it.  If you're at the end of a slow
> >  link, you may very well want to download your mail w/o images, and then
> >  select 'load images' for certain pieces of mail and not others.
> >
> >  3) The same spammers that don't follow RFC822 won't follow your proposed
> >  standard either.
> >
> >  4) Identify the major software vendors who have issues in this
> >  area, and ask
> >  whether they're likely to implement such a standard.
> >
> >  5) Making it a standard won't make people upgrade.  Only user education or
> >  forcing an upgrade on them will do that.
> _______________________________________________
> 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