Robert G. Brown <[EMAIL PROTECTED]> wrote: > ... > here is a short list of what I have heard proposed recently as ways > of abating spam (and in some cases, other forms of network abuse > such as viruses as well): > > a) Add a "cost" per message... > > The fundamental premise here seems to be that we are more able and > willing to pay a higher cost for mail than spammers...
Nonetheless, this might be useful for some parts of the 'net. If Bill Gates wants to run MSN.com in such a way that he collects a penny per email accepted there, I'm happy to let him try. ;^) > b) Require all mail to be electronically signed... > People can already sign their mail digitally if they wish... I'd > expect this to have absolutely no impact on spam at all besides > making my internal whitelist whiter... Digitally-signed whitelisting would be a very good thing -- rendering forgery of From addresses nearly harmless. But few of us believe it will be implemented widely. > c) ... require all mail to come from people you know, or people > you "consent" to receive mail from... > I consider the abilty to receive mail from strangers an essential > feature of email... Most of us on this list would agree. Others won't -- for example many parents would want this model for their children. > d) ... Only accept mail from "clean" networks. > I personally believe that tightening up the regulation of networks > might well "help" abate the spam nuisance... Obviously, not all networks _will_ tighten regulation of spam. For those that don't, a dose of cost-per-message seems appropriate. > There is a time lag problem here as well -- blacklists are often > trying to "catch up" with the rapidly changing spammer identities. There is definitely room for improvement there. > some superlarge domains (e.g. yahoo, hotmail) are effectively > impossible to blacklist... because there are too many friendly > strangers mixed in with the evil spammers that abuse their services. A small cost-per-message might change attitudes here... > AUPs tend to be actual contracts and have to be dickered out by > lawyers. Enforcment is not cheap, which is why many providers throw > up their hands and refuse to deal with the problem or blame somebody > else. A small cost-per-message might change attitudes here, too. > Some SPs may have a vested interest in NOT controlling the problem, > as they profit (indirectly) from spammers working through their > domains. Very important point here! So long as we insist on subsidizing such SPs, we're going to keep increasing the spam load. > Still, this DOES seem to me at least to be a place where the IETF > might make some small contribution, perhaps by working out a clean > partitioning of the responsibility that everybody seems to want to > avoid and getting it written into future AUPs from the top down, > possibly by integrating this process with e). I'm not quite sure what you're proposing: if you mean that IETF should define the responsibilities of each SP, I'd advise against it. If you mean defining a machine-readable language for encoding AUP policy, that might be useful. If you mean defining a protocol for third parties to express opinions about the effectiveness of AUP enforcement by various domains, I think that _would_ be useful. > e) How about if we write some laws and regulations REQUIRING > them to deal with the problem with fines and other penalties > for noncompliance... > This approach seems to be gradually moving forward of its own accord, > driven by considerable public dissatisfaction with spam. But is this anything other than "damage" to be routed around? > f) Filters. > This is a very robust and dynamic solution, and is unlikely to go > away unless/until things like legal measures and improved AUPs > ameliorate the problem (if they ever do). It can be implemented by > individuals at the user level. It can be implemented by sysadmins > at the domain level. Not an IETF concern... > Filters and other intelligent agents COULD be implemented by SPs > at the transport level to identify clients that are spamming, Tell you what -- why don't _you_ start the SP that does this? > and if it ever WERE implemented at this level and the SPs came > down on AUP violators like a ton of bricks with contractual > monetary penalties, the spam problem might really significantly > abate. ... when the SPs are put out of business by the lawsuits... I'm afraid it's _much_ safer for a SP to publish a policy that certain IP addresses are assigned to poorly-monitored customers than to actually interrupt their traffic. And there _is_ a role for IETF in defining a protocol for publishing such policy. It's safer still for third-parties to publish such policy, just less accurate. Third-parties are _now_ publishing IP ranges that shouldn't be trusted, with the result that SPs that use those third-party blacklists get a lot of grief for blocking too much. It would be a substantial improvement if blacklists would accurately reflect SP policy on monitoring. > Most of the detailed solutions thus far proposed fit into one or > more of the categories above. The problem is difficult enough, IMHO, to require a combination of approaches. > Some require universal registration of one sort or another... Unlikely, and rather contrary to some basic 'net design principles. > Some require certification authorities. Many, alas, require certification authority -- singular. A bad thing, IMHO. > Some require integrated costing agents or challenge/response systems > to be inserted into (I suppose) MTAs. Unlikely. > Little discussion of costs on the part of the proposers, often > wildly optimistic benefit claims. Understandable... > In summary... > a) [ePostage] A silly solution. There isn't any reason to believe > that adding scaled costs to spammers will deter spam... Any cost will "deter" some spam -- but very likely not enough. > b) [digital-signiture]... by all means sign messages if you > like... Just don't suggest that it will have any impact on spam > and don't "force" me to use them, make them so attractive that I > WANT to use them... A worthy goal, but rather long-term. > c) [consent to each sender] I don't consent to spam NOW, and > insist on being able to receive mail from real strangers... > I'll NEVER be able to give consent on a person by person basis > without opening the envelope. If I have to open the envelope, > this adds NOTHING to the anti-spam filtering measures already > represented in f). Opening the email need not signify "consent". Also, it need not be done daily, and it could wait for third-party advice. > Remember, I think that there may not BE a solution to spam, in the > sense that people seem to be looking for. There aren't any > perpetual motion machines either. We shouldn't be talking of "a solution"; we should talk spam- abatement -- measures which improve the signal-to-noise. People who want to stop all porn spam -- and there are many -- will have to limit themselves to email from people they already know; and they'll have to limit their circle of friends to those clueful enough to avoid all viruses. Most of us, I hope, will settle for spam-abatement to the point where we can ignore the problem for a few days at a time without subjecting ourselves to sorting through hundreds of spam to find the one false-positive. > On to the good news. > > d) [accept from clean networks] seems worth pursuing. At least > in the sense that AUPs are one of the effective impediments to spam > NOW -- one of the things that largely keeps it from originating > within academic networks, for example -- and thus there is a real > possibility that a better schema for spam regulation at the network > level could result in a significant, enduring, abatement of spam. Yes -- it is important to note which kinds of networks are relatively free from spam-sending. > Here I think that the IETF could be a very positive force and > provide real guidance (in the form of specifications for > software that might be used by SPs to detect patterns of abuse > originating within their boundaries, for example... I seriously doubt the IETF could hope to stay ahead of spammers here. I believe the actual tools for detection of spam-sending will have to be individually developed and constantly tuned. > and possibly with legal work on contract templates that would > permit them to impose financial penalties). I doubt this -- there are too many jurisdictions involved, most of which have their local lawyers writing the laws. > e) [laws forcing SPs to react] Time will tell, but again worth > pursuing. Largely outside of the IETF's purview, though... Agreed. > f) [filters] ... has the advantage of being evolutionary... > and of requiring no higher-level consent or approval (from e.g. > the IETF) to implement on any level... In other words, not an IETF concern. Agreed. > Obviously this is bad news, possibly even unacceptably bad news, > to folks disenchanted with filtering as anti-spam measures. Bad > news or not, it is reality at the moment and quite possibly really > is the best we can do short of legislation or better enforcement > at the AUP/SP level. But we should not rule those out. Especially we should look to encourage better AUP enforcement by means other than new laws. > In conclusion, I have seen almost nothing in the entire spam > abatement discussion that can be taken seriously BECAUSE the > proposals do not include the steps described by Vernon. While I quite agree that such analysis is necessary before any proposal nears Proposed Standard, at the same time I'd prefer to see a brief, succinct, statement of each "new" idea -- so that I can decide whether to expend my own time considering it in that much detail. Granted, this will result in a large number of ideas for which "no serious objections were raised", we have been living with that for years. Perhaps a bot-like posting of the rejection form would help... -- John Leslie <[EMAIL PROTECTED]>