ietf
[Top] [All Lists]

Re: paralysis

2004-03-08 15:54:48
Robert G. Brown <rgb(_at_)phy(_dot_)duke(_dot_)edu> 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(_at_)jlc(_dot_)net>