On Mon, 04 Aug 2003 19:41:35 BST, Richard D G Cox <Richard@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@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... ;)