Re: paralysis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Robert G. Brown <rgb@xxxxxxxxxxxx> 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 <john@xxxxxxx>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]