Subject: Re: [Asrg] Spam, why is it still a problem?

From: Danny Angus <[email-masked]>
Date: Mon, 16 Jan 2006 13:35:16 +0000

Hi Craig
You say..

> Or more to the point why are we letting it still be a problem?
<snip/>
> why is it that there is so little
> visible progress on this list and generally regards implementing a
> solution that actually works and which can be easily accessed by the
> average Internet user?

>From a "pure" point of view, it is clear that unwanted email never even
entered the equation when the requirements for email were first drawn up by
those pioneering boffins. They tacitly assumed that everyone who used email
would be like them and not even consider doing anything other than to play
nice together.
In much the same way localisation, identity and security have until recent
times never been more than an afterthought to most ICT.
The Y2K issue highlights well how implicit assumptions can become invalid
and wreak havoc in your systems design.

Sadly, and all of us here know it, the real answer to spam requires us to
re-analyse the requirements for electronic messaging and consider processes
for authenticating identity and for handling unwanted mail and malicious
content. We could probably knock together a modern interoperability
specification which would accomodate these, and many other, factors but
what use would it be? We would then have to convince every user of mail to
upgrade their software, and if we manage that what cost would it have?

We're left being asked instead to look for the philosophers stone which
will take an alamingly open and trusting interoperability mechanism, one of
the most widely implemented specifications of them all, and retro fit some
paranoia to it in a way which will involve no interruption to service and
no cost to users or systems owners.

This is in large part confused by the fact that people with different roles
have both different definitions of "spam" and different requirements for
their perfect solution to implement.

You can't have everything, what we're left right now with are:
1/ a small number of extremely well thought out and intelligent proposals
which are being suffocated by attempts to assert some form of commercial
control over them and a lack of cooperation.
E.G. Senderid, SPF, DomainKeys, etc

2/ a large number of less well thought out proposals which tend to recycle
discredited concepts in new guises.

One thing that any sucessful solution must do is, by using it, to reduce
the cost of handling mail, not increase it.
If you want to invent a solution which will appeal to the people who pay
for the operation of mail transport it has to do the following (reproduced
from my blog):
"I/ In any messaging system any components involved with identifying and
removing unwanted messages should, when operating sucessully, create
conditions in which no other parts of the system (particulalrly parts
operated by other people) experience an increase in resource consumption as
a direct consequence, and should tend to reduce consumption in some
components as a consequence of removing unwanted messages."
"II/ Any components identifying and removing unwanted messages from the
system should reduce their resource consumption as the number of unwanted
messages they are challenged with reduces"
"III/ Resource requirements for components identifying and removing
unwanted messages from the system should be designed to be predictable and
based upon measureable attributes of the traffic."

3/ a few very effective filtering products, (e.g. spamassassin) and a load
of less effective ones (some appalingly so) .

Furthermore Spam is not just an ICT problem it is a social problem. The
legislators and law enforcement agencies are achieving only limited small
scale sucess.

If you want spam to stop dead you only need to replace SMTP as the mail
transport protocol of choice for everyone everywhere at once.

So you can see that your wish "actually works and which can be easily
accessed by the average Internet user" starts to look a bit naieve, because
not only is there not an "average internet user" but this problem is very
like those promises we used to hear about limitless free electricity they
are usually confounded by engineering details not the Big Theory, and human
nature which sees little incentive in spending your money to benefit me.

d.

***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 16 Jan 2006 17:36:42 +0100

Danny Angus wrote:

> 1/ a small number of extremely well thought out and
> intelligent proposals which are being suffocated by
> attemptsto assert some form of commercial control over
> them and a lack of cooperation.

You can use these three examples right now, at least SPF
and PRA (the part of SenderID not already covered by SPF)
are "ready" (= in the RFC editor queue), you're not forced
to wait for a proper RFC number.

But please read and understand the caveats as published in
<http://www.ietf.org/IESG/APPEALS/?C=M&O=D>

The DKIM WG was chartered a few days ago, for more info see
<http://tools.ietf.org/wg/dkim>

> Spam is not just an ICT problem it is a social problem.

Yes.  But there's definitely a design flaw in post-821 SMTP
as far as most SPF FAIL friends are concerned.  That's of
course highly controversial, many others claim that it's a
feature.  

That's where we enter the deep waters of financial interests.
Parts of the anti-spam industry might not like it if big
chunks of "the problem" are removed, because "the problem"
is their business concept.
                            Bye, Frank

---

From: Barry Shein <[email-masked]>
Date: Mon, 16 Jan 2006 12:59:29 -0500

> We could probably knock together a modern interoperability
          ...
 > transport protocol of choice for everyone everywhere at once.

I would like to introduce a new term to spam-fighting, analogous to
FUSSP ("final ultimate solution to the spam problem" or something
close to that):

                                IFUSSP

      The IMAGINARY Final Ultimate Solution to the Spam Problem.

>From the first nanosecond spam was recognized as something which
needed some sort of generalized solution people involved have repeated
to each other over and over:

      The problem is you can't just replace all the mail software
      overnight on either clients or servers which makes a practical
      solution very difficult.

           (I'll call that the First Axiom of IFUSSP)

Sounds good, but I claim there is no such solution, or it's never been
outlined that I've seen.

Someone please outline it and let others work on deploying its
acceptance. The latter, deployment, is a management function about
which a brilliant software designer may have little insight. Why
proclaim onself expert in both the design and its practical
deployment? Others have those skills.

It's been well over 10 years we've been proclaiming that any good
solution might take (gasp) as long as 10 years to deploy.

So let's just have this IFUSSP design, please. Or let's stop claiming
it exists.

-- 
        -Barry Shein

The World              | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Jan 2006 11:32:29 -0800

Folks,

...
> upgrade their software, and if we manage that what cost would it have?

Both of these statements suffer from being both true and misleading.

On the truth of the historical "deficiency" of initial requirements there was 
pretty much nothing all that organized about the effort, anymore than the 
current web represents a coherent requirements statement, formulated during 
initial development.

The nature of Internet applications is that they go through incremental change 
over extended periods of time, both adapting to changes in the environments and 
adding mechanisms to support added functionality.  Much like a social process...

Folks need to observe that the other global communications services lack the 
kinds of authentication mechanisms that are so readily claimed to be "essential" 
for today's proper Internet mail operation.  That those other services have 
other features, which tend to mitigate the abuses that dominate Internet mail, 
is a matter of accident, rather than planning.

On the matter of a redesign, we have two problems:

1.  It is not clear that it is needed.  Those claiming the need for a redesign 
take it on faith that one is needed.  This is akin to ready-shoot-aim. A 
re-design effort makes sense only after two pre-conditions are met:

    a) new requirements are formulated and gain community consensus, and

    b) attempts are made to retrofit the existing service to satisfy those 
requirements, but the efforts fail.

So far, we have been astonishingly successful at adding capabilities to Internet 
mail, so I strongly suspect that the real problem is in formulating the 
requirements.  This leads to the second, basic problem:

2. We do not know what changes will have long-term efficacy, without also 
causing long-term damage.  We need to ensure continued use of email for current 
and future purposes.  Email fits into a complex human communication fabric that 
is dominated by human and group dynamics, and therefore is frankly not well 
understood.  Change any interesting system -- especially one that is poorly 
understood -- and the changes will always have unintended consequences, most of 
which will be undesirable.  That argues strongly for taking small steps, and 
taking them very, very carefully.

The heuristic I use for considering system-wide responses to spam, and the like, 
is to ask whether the feature would be good to have, even if abuses were not a 
major problem.  Hence, current abuses serve merely as motivators.

d/

ps.  Some of the above is predictably redundant with 
<http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-4/anti-spam_efforts.html>.
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Barry Shein <[email-masked]>
Date: Mon, 16 Jan 2006 15:04:08 -0500

I am surprised that after all these years the problem of spam is still
so fundamentally misunderstood.

The problem at this point are viral-infected zombie bot armies.

These provide massive e-mail distribution power and most importantly
anonymity and mobility allowing evasion.

I think we look at the msgs in our boxes and focus on the content and
imagine ourselves sending such a msg to someone else which leads to a
vastly oversimplified view of the situation.

Everyone gets dozens to hundreds of these spams per day (perhaps some
blocked but they're still being sent.) Services which handle mail
delivery get gazillions of these msgs per day, mostly addressed to
non-existant mailboxes or similar.

These dirtbags can't do this with legally operated (by them)
facilities.

Their economics don't warrant it.

Not even close.

So they deploy literally hundreds of thousands, in total often over a
million, virus-infected zombie bots for which they're not paying a
nickel for (or at least nothing in proportion to their rational market
worth, sure, even bankrobbers have to buy gasoline.)

And that's it.

THAT'S IT.

Stop or significantly slow that and they're defunct, they can't hit us
with billions of msgs per day for the paltry sums they're earning.

And even if they could afford it they'd lose that evasive mobility and
they'd be shut down or at least blocked at a low-level so quickly
they'd go find another profession like stealing people's pets for lab
research or whatever.

How to fix what I describe is a further discussion.

But for the love all that is good and right let's try to agree on what
the problem is.

It ain't some miscreant spinning an SMTP server on his laptop much
like any of us sending email only more fervently.

It's massive, organized criminal infection and exploitation of vast
zombie bot armies numbering in the hundreds of thousands of infected
PCs.

Get rid of that and the amount of "spam" you receive wouldn't be worth
chatting about.

You're welcome.

-- 
        -Barry Shein

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 16 Jan 2006 22:15:48 +0100

Dave Crocker wrote in <asrg.ietf.org>:

 <http://permalink.gmane.org/gmane.ietf.asrg/11194>
> Some of the above is predictably redundant with

Hard to predict, because I didn't know this article, only one
of its diagrams now saying ADMD instead of AU was a déja-vu.

| A common simplification for this model is to use it only
| between boundary MTAs, but this considerable constraint is
| not specified in SPF.

http://tools.ietf.org/html/draft-schlitt-spf-classic#section-9.5
discusses this constraint, and in section 9.3 you find many
considerations for the one less obvious case.  

It's probably unnecessary to mention here that I consider the
1123 5.3.6(a) concept as broken by design, in stark contrast
to the same idea in 821 when source routes still existed.  Bye

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 16 Jan 2006 17:06:08 -0500 (EST)

Barry Shein <[email-masked]> wrote:

> I am surprised that after all these years the problem of spam is
> still so fundamentally misunderstood.
>

Yes, and when that gets solved, there will be a new problem.  Remember
when the problem was open relays?  That's solved, spam is still here.

> Stop or significantly slow that and they're defunct, they can't hit
> us with billions of msgs per day for the paltry sums they're
> earning.

Unless they find another method of emitting spam.  I can think of
several (which I'm going to hope don't get known, so they won't be
revealed).

> But for the love all that is good and right let's try to agree on
> what the problem is.

The problem isn't the sending technique they're using this month.

Seth

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jan 2006 17:08:55 -0800

On Jan 16, 2006, at 11:32 AM, Dave Crocker wrote:

> The nature of Internet applications is that they go through  
> incremental change over extended periods of time, both adapting to  
> changes in the environments and adding mechanisms to support added  
> functionality.  Much like a social process...
>
> Folks need to observe that the other global communications services  
> lack the kinds of authentication mechanisms that are so readily  
> claimed to be "essential" for today's proper Internet mail  
> operation.  That those other services have other features, which  
> tend to mitigate the abuses that dominate Internet mail, is a  
> matter of accident, rather than planning.
>
> 1.  It is not clear that it is needed.  Those claiming the need for  
> a redesign take it on faith that one is needed.  This is akin to  
> ready-shoot-aim. A re-design effort makes sense only after two pre- 
> conditions are met:
>

DKIM is a good start, provided SSP is scuttled.  Constraints on From  
address will be highly disruptive, impractical to obtain, and yet  
easily circumvented by bad actors.  Perhaps at some point email  
readers and list-servers will accommodate a strategy where the From  
address represents a component of the transport, rather than the  
author of the message, but to what end?

Rather than depending upon super human vision, or the acquisition of  
thousands of look-alike domains by the various institutions, a  
cryptographic signature allows the recipient's email application to  
register and uniquely recognize a prior correspondent.  This source  
recognition models the innate ability of humans to identify a unique  
voice or a face.  By highlighting recognized sources, attempts at  
pretending to be one of these correspondents would be easily noticed  
by the lack of highlighting.

The signature also allows the signing-domain to include a non-spoof- 
able opaque-identifier that could be used to track the account used  
to gain access without introducing yet another email-address.  A  
large portion of spam is from compromised systems.  Providing third- 
parties a low cost solution to tracking such systems would be a  
positive step at overcoming this significant problem.  For example,  
there are many services that offer a free system scrub, but the  
account in trouble must be notified.  This type of opaque-identifier  
would also allow the recipient's email application to detect intra- 
domain spoofing without any administration and verification of  
specific authorizations of who can use what email-address.  Email- 
address freedom and independence can be retained using this approach.

> The heuristic I use for considering system-wide responses to spam,  
> and the like, is to ask whether the feature would be good to have,  
> even if abuses were not a major problem.  Hence, current abuses  
> serve merely as motivators.

Being able to recognize a prior correspondent should represent a  
desirable feature independent of the role this could play at abating  
abuse.  Source recognition also allows blocking the account, without  
expecting a miscreant to cooperate and always use the same email- 
address.

-Doug

---

From: Barry Shein <[email-masked]>
Date: Tue, 17 Jan 2006 01:56:27 -0500

> when the problem was open relays?  That's solved, spam is still here.

So by your reasoning we shouldn't have bothered to close the open
relays?

I don't think there are all that many opportunities open to spammers
to cause the kind of global mayhem they cause, and raising their cost
of business (i.e., forcing them to retool drastically over and over)
should have its effects on them.

-- 
        -Barry Shein

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 17 Jan 2006 02:26:09 -0500 (EST)

> So by your reasoning we shouldn't have bothered to close the open

No, by my reasoning we should declare that as soon as we've won the
current battle we'll have won the war.

> to cause the kind of global mayhem they cause, and raising their
> cost of business (i.e., forcing them to retool drastically over and
> over) should have its effects on them.

What part of that argument couldn't have been made about open relays
before the advent of botnets?

Why don't you think it will sound just as silly after botnets have
been replace by the next thing?

Seth

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 17 Jan 2006 12:07:49 +0100

You identify bots as the principal current source of spam and you may be right -
you are not the first to posit this on this list.  I would, however, like to see
some evidence.  What I do see is a lack of evidence in the form of articles
written on technology in serious newspapers, particularly those advising on the
use of technology.  The concept of bots does not figure, so either these
professional journalists are ignorant or our view is skewed or ...

By comparison, suggestions that most spam came from a small number of people or
that there was an increase in spam from former communist states has been backed
up by statistics, by reference to web sites etc.

I don't say you are wrong - just that I wonder why others do not see it that
way - and I do see it as important to identify the nature of spam in order to
propose a realistic solution.

Tom Petch

---

From: John Levine <[email-masked]>
Date: 17 Jan 2006 16:53:16 -0000

>when the problem was open relays?  That's solved, spam is still here.

The move to open relays and zombies tells us that fixed source spam is
dead.  Other evidence of that is that there are few enough fixed
source spammers that the tiny volunteer Spamhaus group manages to keep
them under control.  The bad thing about the end of fixed source spam
is that seven or eight years ago mail system managers were reluctant
to block IP addresses for sending spam, but now they do it at the drop
of a hat which means that they make a lot of mistakes along the way.

It's certainly interesting to ask whether we will ever be able to lock
down the mail system sufficently to make it hard for bad guys to send
spam through unwilling third parties.  Considering how much of the net
runs on MS-ware and how unable Microsoft is to make any progress toward
writing secure software, on I'm not holding my breath.  And even if they
did, they're hardly the only source of design errors or implementation
bugs.

See http://www.slate.com/id/2133993/

R's,
John

---

From: John Levine <[email-masked]>
Date: 17 Jan 2006 16:55:39 -0000

> You identify bots as the principal current source of spam and you
> may be right - you are not the first to posit this on this list.  I
> would, however, like to see some evidence.

It's easy enough to find if you look for it.

> What I do see is a lack of evidence in the form of articles written
> on technology in serious newspapers, particularly those advising on
> the use of technology.

That's all secondary or tertiary sources.  I know the guy who used to
write a lot of spam articles for the NY Times who told me that he's
moved on to other stuff because the spam news is just repetitive.
He's a good reporter but he depends on us weenies for his data.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Tue, 17 Jan 2006 12:44:16 -0500

> been replace by the next thing?

The process of identifying and closing the open relays was very
helpful in closing subsequent spamming methods.

The initial reaction to identifying open relays as major spam sources
and requiring modification by their legitimate operators was
frequently responded to with reactions ranging from "why me", to "why
don't you find some other way to stop these guys?" and even "I have
every right to run an open relay if I want / my server my rules" (I
can name names.)

By and large those attitudes changed as it was made more and more
clear that open relays were a major target of opportunity for
spammers.

The activity of closing down open relays helped tremendously in
establishing the ethic that if your server is being exploited in some
obvious, fixable way by spammers you need to fix it and fix it quickly
or, e.g., find your server in netwide blocklists.

This carried over very well to similar exploits such as those found in
popular web applications. One example is mailto.pl (Doug's WWW Mail
Gateway), a perl CGI script which managed forms data for fill-in
responses on web pages.

It was popular and turned out to be exploitable by spammers; just
stick in any target address and msg, more or less, and hit a site
running the script over and over and it'd spew spam for you. In
essence just automate filling out the form. The exploits actually
allowed hundreds of target addresses per send.

I know this first-hand because it was a bane here on World for a
while. These were closed down in mass droves, after the open relay
experience few needed to be asked twice. It never occurred to us to
respond "oh why bother they'll just find another exploit?". We shut
them down actively.

Education, awareness, actual shutting down of probably tens of
thousands of open relays, preparation and distribution of easy recipes
for fixing common mail server (sendmail, postfix, exim, etc)
configurations, and subsequent releases of those server software
packages with those more secure configurations the default, and new
features improving more secure behavior.

More Importantly...

I'm skeptical of your claim of this unending list of exploits readily
available to replace zombie botnets and doubt it's a good analysis of
the situation.

Put simply, we'd see these new exploits already.

Large botnet operators are being arrested and have been sentenced to
hard time, or are facing hard time.

Running and renting botnets is becoming dangerous, legally.

If there were some other technology easily switched to they'd be
switching to it already. So what is it?

The arrest and conviction of botnet operators is a good development
and should help.

The impression is that many of them are willing to operate in the gray
areas if they believe they are unlikely to be caught and convicted but
few will persist as the behavior becomes more legally dangerous. Or
they won't be able to persist from a jail cell if nothing else.

And the fewer there are, the more likely the hardcore cases can be
identified and arrested. That fact can't be missed except by the most
naive criminals.

Finally, we're talking about spammers finding a way to send many
billions of messages per day, anonymously, with sufficient delivery
resources, and in a manner difficult to identify and block technology.

That's a long and difficult list of requirements.

Such massive exploits don't just grow on trees.

There haven't been very many successful methodologies for spammers in
the past decade (throw away accounts, cooperative and/or negligent
ISPs, open relays, botnets), and it's reasonable to assume the same
will be true in the future. Successful exploits will be few and
identifiable and we can deal with them when and if they come along.

Put another way, what's the other choice? To just allow the zombie
nets to operate because they might find another method?

-- 
        -Barry Shein

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Jan 2006 09:58:39 -0800

On Jan 17, 2006, at 8:53 AM, John Levine wrote:

>> Yes, and when that gets solved, there will be a new problem.   
>> Remember when the problem was open relays?  That's solved, spam is  
>> still here.
>
> The move to open relays and zombies tells us that fixed source spam  
> is dead.  Other evidence of that is that there are few enough fixed  
> source spammers that the tiny volunteer Spamhaus group manages to  
> keep them under control.  The bad thing about the end of fixed  
> source spam is that seven or eight years ago mail system managers  
> were reluctant to block IP addresses for sending spam, but now they  
> do it at the drop of a hat which means that they make a lot of  
> mistakes along the way.
>
> It's certainly interesting to ask whether we will ever be able to  
> lock down the mail system sufficently to make it hard for bad guys  
> to send spam through unwilling third parties.  Considering how much  
> of the net runs on MS-ware and how unable Microsoft is to make any  
> progress toward writing secure software, on I'm not holding my  
> breath.  And even if they did, they're hardly the only source of  
> design errors or implementation bugs.
>

Indeed Windows behaves like natural rubber where a pin-hole quickly  
opens into a massive hole.  Improving upon the decontamination rate  
at least directly addresses the situation and should also stem the  
infection rate.   Providers could assist by establishing conventions  
for including a signed opaque identifier that resolves to an account  
(perhaps as an extension to DKIM).  Rather than blocking providers  
when the situation becomes pronounced, services are available to  
direct accounts into obtaining a scrub, where much of this can be  
automated.  Many AV companies already offer this as a free service.

On a different note, the products and performance demonstrated at  
Macworld were impressive.  The new notebook seemed a bit warm, but  
was running 5x faster.  It appears that an OS build upon Unix  
benefits from decades of cross-platform compatibility.  Oddly, the  
one major product still needing an emulator to run was Office.  Maybe  
there is a little light at the end of the tunnel.

-Doug

---

From: Barry Shein <[email-masked]>
Date: Tue, 17 Jan 2006 13:33:43 -0500

On January 17, 2006 at 12:07 [email-masked] (Tom Petch) wrote:
 >What I do see is a lack of evidence in the form of articles

I think you're beginning to see a reaction from those involved in this
field that you must not be paying attention.

But I'll admit that's unsatisfying so here are some significant and
recent articles for your edification. I tried hard to favor major and
popular news sources:

  1. Study: Nearly a Quarter Million PCs Turned Into 'Zombies' Daily
     http://www.technewsworld.com/story/Zyd9zlwZK6bxGL/Study-Nearly-a-Quarter-Million-PCs-Turned-Into-Zombies-Daily.xhtml

  2. Shut down Sober-infected PCs, ISPs urged
     http://software.silicon.com/malware/0,3800003100,39155484,00.htm

  3. Spam Slayer: FTC's CAN-SPAM Report Card
     http://abcnews.go.com/Technology/PCWorld/story?id=1424942

     Tip of the Month Don't let your PC become a zombie: Industry
     experts estimate 60 percent of all spam is sent from zombie PCs
     whose owners have no idea their PCs are being used for such
     purposes...

   4. Don't ignore newly found booby trap in Windows
      http://www.baltimoresun.com/technology/bal-bz.himowitz05jan05,1,4817689.column?track=mostemailedlink

      ...The flaw allows programmers to execute malicious code on your
      computer when you view a booby-trapped graphic known as a
      Windows Metafile. Once you've done that, the hacker can
      literally take over your PC. He can steal critical information,
      download additional spyware or turn the machine into a "zombie"
      that attacks other systems and delivers millions of spam
      e-mails...

   5. Spammer faces up to two years in jail
      http://news.zdnet.com/2100-1009_22-6026708.html

      Daniel Lin, of West Bloomfield, along with three other men from
      West Bloomfield, was charged in April 2004 with sending spam
      over compromised computers belonging to the likes of Ford,
      Unisys and the U.S. Army Information Center...

   6. Detroit spammer faces slammer
      http://www.channelregister.co.uk/2006/01/13/detroit_spam_case/

      A US spammer likely faces at least two years in jail next week
      after he admitted using networks of compromised PCs to
      distribute junk mail messages...

      The group made in excess of $100K, according to reports...

(bzs: that last sentence is interesting...only $100K?! Now think about
the economics of spamming and why these guys have to steal resources.)

   7. Dutch extortion botnet
      http://p2pnet.net/story/7394

      ...The botnet comprised some 100,000 computers, according to the
      authorities, he says, but, "The actual number was 1.5 million
      computers" and, "I've heard reports from reputable sources that
      the actual number was 'significantly higher' " and may still be
      growing...

      ..."The bots continually scan the network and try to infect other
      machines," states Schneier...

    8. Virus disguises itself as MSN Messenger
       http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2005/12/28/BUG18GDQSJ1.DTL&type=business

      ..."It also connects your machine to a botnet server," F-Secure
      warned, meaning that a person's computer can be controlled
      remotely to attack other machines or send spam...

    9. eBay hacker pleads guilty
       http://www.tgdaily.com/2005/12/28/ebay_hacker_pleadsguilty/

       ...Anthony Clark, the hacker who launched a massive Denial of
       Service Attack on eBay in 2003, has pleaded guilty. Clark had
       taken control of 20,000 computers and formed a "botnet". He
       redirected traffic coming from the controlled computers to eBay
       and temporarily made the popular Internet auction house
       unreachable. The twenty-one year old Oregon man could face up
       to ten years in prison.

(bzs: ok, this botnet was used in a DoS attack but I think it
underscores the general theme that they exist, are dangerous, numbers
of PCs involved (20,000 in this case), and becoming legally dangerous
to their operators.)

   10. TECH NOTES
       http://www.timesdispatch.com/servlet/Satellite?pagename=RTD%2FMGArticle%2FRTD_BasicArticle&c=MGArticle&cid=1128769030716&path=!business&s=1045855934855

       ...Spam-detection experts say these pitches are emerging as
       scam rings become more savvy at using "zombie" PCs -- regular
       people's computers surreptitiously compromised by viruses and
       other vulnerabilities.

I hope that begins to make the point.

 > up by statistics, by reference to web sites etc.

These two observations are not in any way incompatible.

A) The spammers' exploit of choice are massive armies of virus
infected zombie pcs numbering from the tens of thousands to probably
something over a million in number.

B) The number of individuals/gangs using these exploits effectively is
probably somewhat low. ROKSO (www.spamhaus.org) maintains that less
than 200 individuals (and that includes multiple members of the same
gangs) are responsible for the vast majority of spam, and at some
cut-off it's probably signficantly less than that, perhaps dozens.

But A doesn't in any way contradict B, it's merely the description of
the situation.

-- 
        -Barry Shein

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 20:32:04 +0100

Barry Shein wrote:

 [9]
> bzs: ok, this botnet was used in a DoS attack but I think it
> underscores the general theme that they exist, are dangerous,
> numbers of PCs involved (20,000 in this case), and becoming
> legally dangerous to their operators.)

It also underscores why "block port 25" won't solve the zombie
problem, "block port 25" is a delusion, unless it's a temporary
step in a strategy to find and clean (multi-) infected systems.

                           Bye, Frank

---

From: "Larry Seltzer" <[email-masked]>
Date: Tue, 17 Jan 2006 15:41:29 -0500

>It also underscores why "block port 25" won't solve the zombie problem, 
>"block port 25" is a delusion, unless it's a temporary step in a strategy 
>to find and clean (multi-) infected systems.
 
It's not a solution for the DDOS problem, but it definitely would make a
massive dent in the spam problem (or at least force spammers into some other
tactic; of course you'll tell us what that would be, right?)

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
Contributing Editor, PC Magazine
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Jan 2006 13:41:24 -0800

> step in a strategy to find and clean (multi-) infected systems.

Although port 25 blocking offers a degree of containment, zombies use  
any avenue available.  Rather than waiting for keystrokes, password  
recovery allows immediate access when applications store passwords.   
The victims are also less likely to know there is a problem, as  
zombies are getting better at creating the appearance of normality  
while disabling protections.  Some even include artificial  
intelligence able to mimic someone responding real-time to concerns,  
while offering assurances everything is fine.  The social engineering  
involved and extent of the problem is rather startling.

Avenues of infection offering traceable source identifiers would  
allow tracking the infections.  Lacking conventions, a large amount  
of resource is expended in this effort.  Traceable identifiers do not  
need to expose personal identifiers any more than a MAC or IP address  
would, and, in my view, should not look like email-addresses.  The  
goal would be to locate the infected machine, not identify the author  
of a message.  Once the machine is identified, there are many ways  
users can be alerted and directed to a cleanup process.  At this  
point, scrubbing programs work reasonable well, but they must always  
adapt.  Even this aspect represents an escalating battle.

Even applying delinquent patches to the OS may result in a corrupt a  
filesystem when an older disk maintenance application becomes  
confused by modified low level APIs.  It is really depressing to see  
a file-system recovery tool estimate restoration to take tens of  
thousands of hours.  What fun.

-Doug

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 17 Jan 2006 17:07:12 -0500 (EST)

"Larry Seltzer" <[email-masked]> wrote:

> It's not a solution for the DDOS problem, but it definitely would
> make a massive dent in the spam problem (or at least force spammers
> into some other tactic; of course you'll tell us what that would be,
> right?)

Well, no.  Why give them any leads?

Seth

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 23:17:35 +0100

Larry Seltzer wrote:
 
> It's not a solution for the DDOS problem, but it definitely
> would make a massive dent in the spam problem (or at least
> force spammers into some other tactic; of course you'll tell
> us what that would be, right?

Guessing what spammers might do is something I'm not good at,
but I've given up on "spammers are stupid" getting apparently
better results with "they just act rationally from their POV".

A zombie can do everything it's former owner can do.  Hijack
587 sessions for spamming.  Harvest addresses.  Participate
in DDoS.  Everything distributed.net does, but for real and
illegal purposes.  Confiscate Paypal and other accounts of
its former owner.  Create Web mail accounts in the name of
its former owner and spam.  Redirect spamvertized URLs in an
attempt to evade SURBL.  Attack or spam IRC, jabber, Usenet,
IM, blogs,..  Port 25 SMTP is only one of many ways to cause
harm.  Spam sent by zombies is a symptom, not the disease.

                            Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 23:29:08 +0100

Douglas Otis wrote:

> What fun.

Somewhat off topic, USEFOR just hit the same "certified sender
/ sender id" issue, it's also relevsant in NetNews.  Bye, Frank

---

From: "Larry Seltzer" <[email-masked]>
Date: Tue, 17 Jan 2006 18:53:34 -0500

>>its former owner and spam.  Redirect spamvertized URLs in 
>>an attempt to evade SURBL.  Attack or spam IRC, jabber, 
>>Usenet, IM, blogs,..  Port 25 SMTP is only one of many ways 
>>to cause harm.  Spam sent by zombies is a symptom, not the 
>>disease. 

Out of this list only two are really mail spamming activities. Port 587 is
inherently authenticated, so a bot that uses it will be quickly shut down.
It's just not much of a substitute for the freedom port 25 presents. "Create
Web mail accounts in the name of its former owner and spam" - why would you
need a bot to do this? What value does a bot add? In any event, it's still
not a reason to keep port 25 open. 

Basically, you're right that there's a lot that bots can do besides spam on
port 25, but blocking port 25 would make it much, much harder for bots to be
a significant source of spam. Consequently the value of botnets would
decrease substantially.

Larry Seltzer

                            Bye, Frank

---

From: Gadi Evron <[email-masked]>
Date: Wed, 18 Jan 2006 02:14:14 +0200

>>>A zombie can do everything it's former owner can do.  Hijack

I think not many people understand what a Zombie is.. I think I will 
write on this soon.

<snip>

> a significant source of spam. Consequently the value of botnets would

Larry, I can honestly say I couldn't have put it better myself.

This is a never-ending game of cat and mouse. Once we block one route, 
the mouse opens another which we hurry to try and block, and so on and 
so forth to the end of time.

That doesn't mean we shouldn't block, or more to the point, kill the 
mouse or cut off one of its legs.. or even better, prevent it from 
creating new lil mices.

Port 25 blocking is advancing spam in the direction we want it to take, 
which I believe will be more manageable, rather than letting the 
scUmmers lead us on their own evolutionary ride, reacting to our 
reactions and getting better while they're at it.

[Nothing personal, der Mouse. :) ]

	Gadi.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Jan 2006 03:00:53 +0100

Larry Seltzer wrote:

> Out of this list only two are really mail spamming
> activities.

It wasn't meant as _complete_ list, just some simple ideas how
to cause havoc as proud owner of 20,000 PCs, limited to those
that are online.  They could also look for formail (or formmail
sp?) Web forms, and fire until the Web hoster stops that abuse.

Or scan other systems for vulnerabilities adding them to the
botnet, or use them directly to spam, if it's a system where
port 25 is not blocked.

> Port 587 is inherently authenticated, so a bot that uses it
> will be quickly shut down.

If the ESP kicks his customer.  Or if the ESP is also the ISP
and educates his customer.  We've seen how good that works for
say spamcast.

> "Create Web mail accounts in the name of its former owner and
> spam" - why would you need a bot to do this? What value does
> a bot add?

Fresh source IPs, and we're discussing ways to bypass port 25.
It might be a hard decision for receivers to block GMail, if
thousands of bots abuse it to send spam "via port 80" and
stolen GMail accounts.

> you're right that there's a lot that bots can do besides
> spam on port 25, but blocking port 25 would make it much,
> much harder for bots to be a significant source of spam.

If a zombie can't spam, neither directly nor indirectly, it
can find somebody without this restriction.  It can also help
in spam runs, e.g. load DNS server caches with the IPs for
spamvertized domains (a dummy HTTP GET will do), then the
controller shuts down his name server (so Akamai / SC won't
see it when they try), and finally he lets other bots fire.

I'm of course not sure, but sometimes I think Leo already is
at that level of the game, when SC fails to resolve IPs, but
I've no problem to get them.
                            Bye, Frank

---

From: Danny Angus <[email-masked]>
Date: Wed, 18 Jan 2006 09:39:05 +0000

Barry,

You make some good points, and althought I accept that I don't have the
answer I'll try to illustrate what I mean by rising to your challenge..
Effectively in my view, the difference between a "new" protocol and
enhancements to existing mechanisms is that a new one would be able to be
designed such that transmission of messages was denyed by default, enabled
by choice and could be revoked at will.

> Sounds good, but I claim there is no such solution, or it's never been

Thats probably true, but we can guess what elements it would include.

> So let's just have this IFUSSP design, please. Or let's stop claiming

I haven't heard anyone claim it exists, there is a key variability.
What I do know is that it is possible to design systems which satisfy
bounded requirements.
The variability comes in because no-one has yet defined those requirements
unambigously, all we have is unbounded requirements or requirements which
are based on concepts which have no commonly accepted definition (such as
"spam"), and commonly stated requirements which are sometimes incompatibly
different depending upon what role you are playing in the system.

IMHO any "IFUSSP" solution would probably need to meet the following
requirements..

1/ it would allow unknown (new) senders to *attempt* to send mail to any
user of any domain
2/ it would not involve any charge being levied for transport (even an
indirect charge like cpu cycles)
3/ it would involve the use of open standard identity and trust mechanisms
to associate levels of trust with people and domains (no one will want to
re-invent that wheel)
4/ it would not require a centralised register, nor require the use of any
commerically controlled register, it would be capable of benefiting from
operational efficiencies achieved by the use of chains of trust.
5/ it would not impose additional direct or indirect loads on external
systems, don't shoot the messenger.
6/ unit cost of normal operations would not increase. For instance if a
proposal increases the cpu cycles required to accept good mail rather than
reducing the cycles required to reject unwanted mail then as the number of
unwanted messages presented falls the total cost might fall but the unit
cost rises and any increases in allowable traffic become more expensive to
accomodate.

It might involve the exchange of trust tokens (and other domain details)
between unknown parties as means of registering allowable senders *before*
any attempt to send will be accepted. Trust tokens could be accepted at
face value where out-of-channel mechanisms for establishing trust exist
(for example between corporate domain operators) or some third party trust
provider could be required as a signatory for anonymous or less trustworthy
domains.

The recipient system would respond at its convenience when the identity of
the sender (and any other checks which the recipient chose to make) had
been verified and accepted. The senders system would then, and only then,
attempt to send mail to the recipient.

Recipients would be able to revoke this permission at any time, resulting
in an end to all traffic from the sender for a period stated in the
revokation.

Mail could be accepted into the recipients domain by checking only that it
held a validated identity.
Recipient systems could continue (as at present) to scan content, the
difference being that in the new process it would actually be possible to
block the transmission of unwanted content, not simply to can it after it
has consumed resources. If people managed to circumvent the personal aspect
whole domains could be blocked. Where chains of mail transport exist chains
of trust could be established, recipients could chose to block incoming
mail that their domain might accept.

The key is that at each step in the transport of mail it would be possible
for a recipient to effectively turn-off the source for a finite or
indefinite period of time.

Obviously without the existence of some clear (i.e. codifiable) definition
of what is accpetable one person might object to mail from a sneder which
their neighbour considers relevant and desirable, to this extent the
solution doesn't and cannot by defninition, prevent all unwanted content.
What it can do is to allow (but not compel) recipient users and automated
systems to identify the senders of unwanted content and disbar them from
even attempting to send mail.

I know this isn't the answer to your question! ButI hope it does
demonstrate that there are ideas out there which could form the basis of a
new form of SMTP which would permit some of the key requirements for
controlling the sending of unwanted mail.

d.

---

From: Danny Angus <[email-masked]>
Date: Wed, 18 Jan 2006 09:46:08 +0000

You wrote:
>A re-design effort makes sense only
> after two pre-conditions are met:

> requirements, but the efforts fail.

I couldn't agree more.

> requirements.

Yes.

d.

---

From: Danny Angus <[email-masked]>
Date: Wed, 18 Jan 2006 09:48:55 +0000

> So by your reasoning we shouldn't have bothered to close the open

A truly effective solution to the real problem would not *require* that
open relays be closed, it would involve a transaction between the sender
and the recipient, not impose a constraint on the transport layer.

---

From: John Levine <[email-masked]>
Date: 18 Jan 2006 18:03:28 -0000

>IMHO any "IFUSSP" solution would probably need to meet the following

This is a nice list.  Any chance you could work it up into a draft of
proposed criteria for anti-spam techniques?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 18 Jan 2006 13:27:34 -0500 (EST)

Danny Angus <[email-masked]> wrote:

> A truly effective solution to the real problem would not *require*
> that open relays be closed, it would involve a transaction between
> the sender and the recipient, not impose a constraint on the
> transport layer.

YM "FUSSP"

Seth

---

From: Barry Shein <[email-masked]>
Date: Wed, 18 Jan 2006 18:36:54 -0500

> I haven't heard anyone claim it exists, there is a key variability.

I think they have, every time someone prattles on about how
internet-wide deployment is a difficult constraint. A difficult
constraint on what solution, precisely?

 > 1/ it would allow unknown (new) senders to *attempt* to send mail to any

Agreed.

 > indirect charge like cpu cycles)

Unclear. TANSTAAFL, at best you can only shift the cost around.

 > to associate levels of trust with people and domains (no one will want to

Maybe, or maybe only for those who can't live with modest resource
needs. For example, I don't have to identify myself in any way to drop
a first-class letter in the postal box. But if I want to do much more
than that id requirements rise (e.g., my own postal meter.)

 > operational efficiencies achieved by the use of chains of trust.

Not clear. Again, TANSTAAFL. Maybe we've gone as far as we can on
these ideas.

 > systems, don't shoot the messenger.

Well, not without appropriate recompense or justification.

 > cost rises and any increases in allowable traffic become more expensive to

This is probably getting too close to the nitty-gritty of a possible
solution vision to bother specifying so precisely. I'm not even clear
the requirement is all that necessary, seems like more of an
efficiency measure and a platitude to try to keep efficiency constant.

 > provider could be required as a signatory for anonymous or less trustworthy

And these "trust tokens" can be managed without measurable expense? Or
the expense reasonably distributed to the end-users so dilute enough
to be negligible?

I'm not so sure, seems to wave a hand at the realities of managing
hundreds of millions of whatevers in some consistent manner.

 > attempt to send mail to the recipient.

That is, some magic token is exchanged and a system is postulated for
verifying that token against some set of trust criteria, and because
it sounds kind of difficult we'll not require that it be in real-time
even though we don't know what it is or whether it could work in
real-time or not?

I think we need the spec before deciding whether or not it might run
in real-time.

For example, characterizing most denial of service (DoS) [qattacks as
overloading a target system with transactions of some sort,
particularly if they can't be brushed aside in a lightweight,
real-time manner, DoS seems to potentially lurk in any system like
this.

 > in an end to all traffic from the sender for a period stated in the

That is, criteria for acceptance are changeable and at least in part
under the control of the intended recipient.

 > held a validated identity.

As a proper subset, sure, but that's probably the easy case.

 > mail that their domain might accept.

Chains of ... , hard part of the problem.

Also, the precedent seems to imply that someone else is blocking
content as a service, which has implications for both control, cost,
and immediacy (real-time-ness), maybe.

 > indefinite period of time.

(or other criteria, e.g., until they stop sending more than one msg
per hour to me?)

 > solution doesn't and cannot by defninition, prevent all unwanted content.

This is one of the sticky implications of "must not impose charges".

Either something is charged for fairly, or someone has to act as
policy commissar as to what merits delivery and what does not.

Perhaps in an ideal world that policy commissar making the rules is
the end-user. But as we've seen it's not as simple as that. E.g., can
I decide I want mail from a source which is threatening to bring down
my mail operator's facilities, purely on strength of policy (it's my
right to receive the mail I want), but without recompense?

So at least sometimes someone else is the policy commissar.

Unless there's some kind of fair charge in which case one can have
anything they like so long as they are willing to pay for it.

 > even attempting to send mail.

To them, but whose responsibility is this? To actually execute, I mean.

 > controlling the sending of unwanted mail.

You probably don't need much modification on SMTP to do most anything
since it's just a "COMMAND OBJECT" protocol (e.g. HELO systemid) and
can be extended just by adding another COMMAND and some typical rules
about WILL/WONT CAN/CANT and backwards compatability if desireable.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Wed, 18 Jan 2006 18:41:05 -0500

> and the recipient, not impose a constraint on the transport layer.

In other words, it'd find some other way to achieve the same effect of
closing open relays.

I suppose one could argue that simply forbidding unauthorized
third-party email to be forwarded through their system seems a
heavy-handed way to accomplish the desired effect.

But then again it's not clear how any other solution could allow
forwarding of unauthorized third-party mail w/o problem, though I
suppose variations on the basic theme could arise.

-- 
        -Barry Shein

---

From: Laird Breyer <[email-masked]>
Date: Thu, 19 Jan 2006 16:33:33 +1000

> In other words, it'd find some other way to achieve the same effect of

No, I think what Danny means is that an effective solution needs to be
end-to-end (RFC1958). Only the sender and recipient should be involved, the
intervening network should only transport bits.

I'm not sure an end-to-end censorship system is possible in an accept
and forward infrastructure such as email, but maybe there's some kind
of formal proof of that statement? I don't know.

-- 
Laird Breyer.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 19 Jan 2006 08:44:23 +0100

Laird Breyer wrote:

> I think what Danny means is that an effective solution needs
> to be end-to-end (RFC1958). Only the sender and recipient
> should be involved, the intervening network should only
> transport bits.

1958 is an informational RfC not talking about SMTP.  For SMTP
there's a point where mail from one side (MON, mail originating
network in Keith's terminology) reaches the other side (MRN, a
mail receiving network).

It's the point where a last MTA in the MON does a query=mx to
find a first MTA in the MRN.  That singularity is the point
where "unknown strangers" are forced to talk with each other.

The "path registration" schemes (Dave's terminology) focus on
precisely this one singularity to sort it out.  Any mess before
this point is the problem of the MON, and any issues behind it
are the problem of the MRN.

MAIL FROM, Return-Path, and reverse path are no metaphors, they
are used to report problems.  Where RFC 2821 said "originator
as indicated in the Return-Path" it's now in most cases a lie.

                           Bye, Frank

---

From: Danny Angus <[email-masked]>
Date: Thu, 19 Jan 2006 08:57:13 +0000

>heavy-handed way to accomplish the desired effect.

Yeah, mail should be permited/forbiden based upon the relationships between
sender and recipient, but might be actioned at any point.

Open relays weren't the root cause of the problem, but they were the place
where the least intrusive fix could be applied.

d.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Jan 2006 08:59:34 -0800

> proposed criteria for anti-spam techniques?

I like the list, too. It has promise as a vehicle for constructive discussion 
about proposals.

Perhaps the most difficult aspect of trying to flesh the list out is to provide 
solid explanations that clarify and justify each of these "requirements". 
Barry's response highlights this.

For example, the "no cost" requirements prompted his observing that there is 
always cost.  He's right, but I suspect your"no cost" reference was not meant as 
an absolute.  Or perhaps it was, at least, meant to mean that there was no 
third-party fee.  Or perhaps it meant...

Hence the need for elaborations.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Jan 2006 09:07:34 -0800

> sender and recipient, but might be actioned at any point.

I think this is quite a good and powerful summary statement.  One worth re-using 
quite a lot, though not as the sole, absolute directive for all anti-abuse/spam 
efforts.

I believe there are two, complementary sets of relationships worth focus, the 
one you cite and the one between operators.

One of the things that is interesting about DKIM is that it is mostly discussed 
as being between operators but it really is between originators and recipients, 
albeit without the final granularity of mailboxes -- it uses only the coarser 
domain name reference.  That it can be *administered* by operators is a very 
useful choice, but the fact that it does not *require* operator participation is 
fundamental.  Contrast that, for example, with SPF. Another contrast would be 
CSV, which is strictly between neighboring operators.

d/

ps. I am making the assumption that your use of "sender" means either 
rfc2822.From or rfc2822.Sender.  In general, the raw use of the word "sender" 
has become highly ambiguous, given how many intervening agents are senders.

-- 

Dave Crocker

---

From: Danny Angus <[email-masked]>
Date: Mon, 23 Jan 2006 09:15:45 +0000

Yeah I'd be happy to.
I've been trying to identify the most common reasons why we tend to
classify and dismiss proposals, often pretty brusquely.
What we seem to be doing is to compare them with a implict set of
requirements which the group subscribe to but don't publish.
We then have problems explaining to the proposer exactly why "your solution
is a ..." means that we believe it has a pimary design flaw.

Watch this space.

d.

|---------+---------------------------->
|         |           John Levine      |
|         |           <asrg@johnlevine.|
|         |           com>             |
|         |                            |
|         |           18/01/2006 06:03 |
|         |           PM               |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                 |
  |       To:       [email-masked]                                                                                                   |
  |       cc:       [email-masked]                                                                                           |
  |       Subject:  Re: [Asrg] Spam, why is it still a problem?                                                                     |
  >---------------------------------------------------------------------------------------------------------------------------------|

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.