Complaint of the week: Ebay abuse mail (slightly OT)
Valdis.Kletnieks at vt.edu
Valdis.Kletnieks at vt.edu
Mon Aug 4 20:13:05 UTC 2003
On Mon, 04 Aug 2003 19:41:35 BST, Richard D G Cox <Richard at mandarin.com> said:
> The immediate benefit (as sender) is that you reduce the (now ever-increasing)
> risk of your mail being rejected by filtration processes and will be trusted
> on arrival; the benefit for the recipient is of course less junk!
Erm. No. You only get benefit as *other* sites deploy. If they haven't bought
in, they won't contact your new service. Or to use a totally different example
- if you've deployed IPv6, you won't actually get connections from other sites until
THEY put up IPv6 too.
Your users receive less junk only once a significant number of other sites deploy.
> However you CAN stop accepting "plain old SMTP" right away, because you can
> delegate that to a filtration service that hosts your old-style MX, applies
> ever-increasingly stringent filtration rules, and then forwards to you using
> the new protocol. Several such filtrations services may well appear when the
> time is right.
And this is an improvement over just applying the filtration rules *how*? ;)
"Since SpamAssassin isn't good enough to solve the problem, I'll run it over THERE
instead, and then forward 99.9% of my mail to here over new protocol XYZ".
> > 2) Who bears the implementation cost when a site deploys, and who gets
> > the benefit? (If it costs *me* to deploy, but *you* get the benefit,
> > why do I want to do this?)
>
> Both parties get benefits which seriously outweigh the costs!
Enumerate. Remember *not* to count benefits that aren't a result of your
protocol change...
> > 3) What percentage of sites have to deploy before it makes a real
> > difference, and what incremental benefit is there to deploying before tha=
> t?
>
> To some extent the concept is already here, and deployed, whether using
> in-house filters or remote-MX, to subject the unauthenticated mail - which
> of course is currently ALL the mail - to appropriate filtering.
Right.. so you can't count "filtering" as a benefit (see above). So what benefit
do you get for doing it *before* it reaches critical mass?
> That goes for any precautions taken - not just content filters. That is WHY
> the contractual relationships are absolutely essential for any new scheme.
> And there, too, lies the bulk of the work needed - the technical issues do
> not place any great demands on the networking community.
Gaak. There was a *reason* the X.400 concept of ADMD and PRMD died
an ugly death - it doesn't scale well at all. "Contractual relationships" is just
a buzzword meaning "whitelisting after the lawyers got hold of it". :)
ObNANOG: If this goes through, it will be considered a revenue source by
many providers. See "peering versus buying transit" for details. ;)
> > If you have a *serious* proposal that actually passes all 4 questions
> > (in other words, it provides immediate benefit to early adopters, and
> > still works when everybody does it), bring it on over to 'asrg at ietf.org'.
>
> Heh. The noise-to-signal level *there* is far worse than in NANOG - by at
> least 12dB last time I looked ;-)
Would improve vastly if asrg wasn't spending so much time thrashing yet
another non-bootstrappable proposal to death :)
And to the other responder who's name I've lost- yes, there's no good technical
solution to spam. That's why I advocate collecting $500 from each ISP to hire
some muscle from a suitable ethnic organized crime organization (I'm told
competition is driving the costs down ;) to "explain our position and make some
examples". This would quickly change the percieved economics of spamming -
that $4K/week suddenly looks a *lot* less inviting when you know the last guy
who tried it got a visit from 3 guys with baseball bats... ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20030804/01a4106f/attachment.sig>
More information about the NANOG
mailing list