Subject: Re: [Asrg] Quarantines and block lists

From: <[email-masked]>
Date: Sat, 27 Jan 2007 19:43:23 -0600

> [On second thought, I DON'T want to define spam as UBE. 
>Labeling UBE  
> as spam labels the sender as a spammer which carries a 
>negative  
> connotation. I just want to block UBE without calling 
>anyone a  
> spammer and getting sued]

Again, all these problems are eliminated once you allow 
the RECIPIENT to determine what they do and don't want to 
receive and read.

I think it's also worth considering a subtle but perhaps 
important distinction between recommending that the 
recipient customer delegate the choice(s) to the ISP, as 
compared to "suggesting" rules that the recipient customer 
can choose to select (or not).

A litigious spammer could still sue an ISP for 
implementing rules (especially if those rules change after 
the customer recipient delegates the authority) which 
disadvantage the spammer.

> Here is my proposal. I'm sure I haven't thought of 
>everything so  
> please tell me where it breaks or how spammers are going 
>to game it.  
> The goal is to stop the majority of the spam while not 
>loosing ANY  
> legitimate email (broken MTAs don't count). 

To begin with, crude IP blocks will ALWAYS lose legitimate 
mail, because a single IP address can send both legitimate 
and zombie-generated mail.  I propose that NO ISP-based 
software will be capable of differentiating one from the 
other... but the recipient possibly will know how to do 
that, at least for familiar senders.

> This is not intended to  
> replace existing blocklists but to handle the initial 
>onslaught from  
> a spam source until the source can be properly 
>categorized and listed.
> 
> 
> Proposal #1 is a quarantine for new sources:
> 
> Connections from unknown source addresses would be 
>initially rejected  
> by returning a temporary error code (4xx) for a 
>probation period. The  
> probation period could be as short as 5 minutes 
>depending on how fast  
> the blocklists can respond. The reject would occur after 
>the  
> recipient list is accepted so the recipients can be 
>checked against  
> local spamtraps and valid user lists. After the 
>probation period,  
> global blocklists would be queried to find the current 
>reputation of  
> the source.

While spamtraps and valid user lists are helpful 
sometimes, they will not trigger if the spammer is using 
"fresh" E-mail address lists which are also devoid of 
spamtrap E-mail addresses.

> Proposals #2 & #3 are for a fast global block advisory 
>and  
> distribution network
> 
> Any email addressed to a spamtrap would generate a 
>report to a local  
> trap handler. The local trap handler would forward 
>appropriate  
> reports to the regional or global blocklist managers. 
>The blocklist  
> managers would publish advisories based on the 
>reputations and counts  
> of the traps that were hit by the sending IP. 

IP address blocking, again, is simply too crude.  A 
further and more serious problem is that you have 
basically no way to be 100% sure of who the "sending IP" 
actually is.

For just one example, Yahoogroups send millions of E-mail 
messages per day, from (doubtless) a large server farm. 
 Different Yahoogroups vary dramatically in terms of how 
attentively they are moderated.  Some are moderated with 
great care;  other groups have been abandoned or stranded 
by their owners and have been operating on autopilot, some 
for many years, and many such groups have been 
'discovered' and are heavily abused by spammers.  (Indeed, 
it seems that many Yahoogroups send very little OTHER than 
spam).  So what IP address(es) do you plan to block?  All 
of Yahoogroups?  That's obviously a non-starter.

Or let's say that Aunt Gertrude's machine gets infected by 
a worm, which starts sending out E-mails using Aunt 
Gertrude's account at the ISP, via the ISP's mail server. 
 Are you going to block everything coming from that mail 
server?  What if it is a VERY large ISP?  Obviously, it 
would have been nice if that ISP's outgoing mail rules had 
caught the messages, but in this case let's recognize that 
they didn't.

> If the source is  
> emitting a sufficient volume of spam this happens before 
>the initial probation period expires.

Again, that's part of what I said about spammers 
engineering their mails so they squeak under whatever 
threshold is established to trigger spam alarms.  That can 
be done on content, sending rate, or any other 
generally/widely used criteria.

> DNS is probably a poor choice for distribution of the 
>global fast  
> response block advisories. 

Obviously, since a change in status doesn't propagate 
quickly enough.

> I think a form of flood 
>distribution  
> through a mesh of peer nodes would be more robust. The 
>distribution  
> would feed local databases that could be queried 
>directly or through  
> a DNS front end. The mesh can handle data from multiple 
>sources and  
> needs no central authority.

And how do you propose to prevent worms from targeting and 
flooding or doing other Denial of Service attacks on that 
mesh?

> Proposal #4 is back reporting unsolicited email:
> 
> If email addressed to certain spamtraps is received from 
>a sender  
> that has registered to accept back reports, 

Original sender?  A forwarding sender?  An aggregating 
sender?  How does the objecting MTA make sure?

> accept the 
>mail but  
> return a specific code in the response that the sending 
>MTA can  
> interpret to make a determination if the sender is 
>spamming.  
> Alternatively, the site may register a different 
>protocol to use for  
> the back report. The spamtraps used for back reporting 
>should be  
> different from those reported to global blocklists to 
>prevent  
> disclosing the traps to rogue ISPs that would forward 
>them to  
> spammers. Only some of the traps would be used for back 
>reporting to  
> any given network or host.

I'm not convinced that returning ANY "spamming!" status to 
any imagined source is really worthwhile.  To begin with, 
I think that most such reports will be discarded or 
archived, and just create additional worthless traffic on 
the Net.  Secondly, if the "back reporting" can be 
misdirected (by counterfeiting E-mail or ISP addresses) 
then the creative spammer can induce the bounce message 
MTA to effectively be the "proxy" "sending source" of the 
spam, tricking it into sending the bounce message to the 
third party.  (I used to get a fair amount of such 
apparently-intentional bogus bounces... and indeed, I 
still get a lot of antispam bounces into my "catch-all" 
E-mail account at a vanity domain, generally resulting 
from spammers who are counterfeiting randomly generated 
"From" addresses supposedly within my domain).

> Proposal #5 is a quarantine while a site is listed in a 
>block advisory.
> 
> Established sources that get listed in local or global 
>block  
> advisories should have their mail quarantined while the 
>mail is  
> sorted out. The best place to quarantine the mail is on 
>the sending  
> server. It's already queued there and if it is 
>eventually determined  
> that it should be rejected, 

And on what basis or set of rules do you propose that such 
determination be made?  I will suggest that (at least for 
some non-obvious cases) that determination could be 
difficult or even impossible to do accurately.

Apart from (as previously noted) the problem of 
determining after the fact with any real accuracy just who 
the "sending server" actually is, particularly for 
multi-hop mail deliveries.   It's easy enough to forget 
that not all E-mail deliveries are simple 
user->ISP->ISP->user transfers.

Vanity domains that provide mail forwarding are just one 
example of a way that intermediaries enter into a mail 
delivery chain.  Aggregators/forwarders like Yahoogroups 
are another.

> that can be done with a 5xx 
>on the next  
> delivery attempt instead of sending a bounce. 

And what if the next E-mail coming from that IP address is 
legitimate, non-spam E-mail?

> If the sending ISP is  
> on their toes an offending user or host will be shut 
>down quickly and  
> the remaining mail will be delivered when the block 
>advisory is  
> lifted or expires. 

And what happens to their legitimate outgoing mail in the 
meantime?

> Local whitelists can be used to allow 
>mail to  
> bypass the quarantine.

That's fine, but (again) I believe that traditional, 
simple "whitelists" are not nearly adequate.  I believe 
that a viable whitelist MUST comprise a recipient/sender 
pair of addresses, AND additional criteria regarding what 
the recipient expects to receive from the sender in 
question.

More to the point, once THAT is done, I believe that IP 
address blocking becomes essentially superfluous (and 
indeed, COUNTER productive).

> -- Dan Oetting

[comment #2]

> Subject: HTML-burdened email (Re: [Asrg] Re: bounces, 
>and anti-spam principles)

> } I don't consider that ANYBODY has the right to blindly 
> } haul off and presume that I'm willing to accept 
> } HTML-burdened E-mails from them.
> 
> You're welcome to take that position, but it doesn't 
>seem to fit with
> the rest of your argument that what gets accepted should 
>be controlled
> on a per-user basis.  

Yes, it does.

Certainly a user COULD configure their default behavior to 
allow HTML (perhaps a limited 'subset' of HTML) from 
non-whitelisted senders.  I wouldn't consider that 
anything remotely like a "best practice", and one would 
hope that the great majority of users would use the 
recommended defaults if they wanted effective spam (and 
virus/worm) blocking.  Educating the users toward that end 
would be to the ISP's advantage, obviously.

> Elsewhere you wrote:
> 
> } Even 2% legitimate traffic is too much to block, if 
>that 
> } 2% is critically important stuff.
> 
> How is blocking legitmate email because it contains HTML 
>less wrong
> than blocking it based on point of origin?

1)  You in the general case will have difficulty 
determining the REAL "point of origin".  Whether a message 
contains HTML or not is far less subjective.

2)  If the sender has not previously been in contact with 
the recipient, they can not be sure that the recipient is 
capable of handling HTML-burdened E-mail (they might have, 
for example, a text-only E-mail client).  Sending 
HTML-burdened E-mail BEFORE establishing that the 
recipient is willing and able to handle it violates every 
"best practice" for that area.  (I have gotten HTML-only 
mail from senders with "clickable links" to say I want 
plain-text mail.... which obviously is laughable for the 
great majority of less-tech-savvy users).

3)  Content-based antispam determination can be FAR more 
efficient and FAR more accurate if all the various 
HTML-based ruses are simply banned from the get-go.  Users 
who suddenly see a great reduction in spam, pfishing, 
viruses and worms (and with the explanation of why) are 
likely to quickly become believers.  :-)

> } It doesn't matter.  You simply block (by default) ALL 
> } images (whether embedded or attached) coming from 
> } unfamiliar/first time senders.  If they want to send 
> } images, they first negotiate that permission with the 
> } intended recipient.  (And that permission, of course, 
>can 
> } be revoked by the recipient if the privilege is 
>abused).
> 
> [...]
> 
> } There is NEVER the NEED to send 
>HTML/attachments/scripting 
> } to someone in an INTRODUCTORY E-mail.  Not until 
>you've 
> } established that they are willing and able to receive 
>that 
> } kind of content from you.
> 
> This presumes a whole lot of effort on the part of the 
>recipient in a
> variety of circumstances.

No.  If the software is well-written, the effort required 
by the recipient is relatively trivial.

It could be as simple as NO effort, if (for example) the 
introductory E-mail from a not-previously-seen sender is 
NOT marked as spam by the recipient upon reading it (which 
might enable, for example, a slightly more liberal 
filtering on subsequent mail from that same sender). 
 Again, that's a detail of the implementation of the 
client software, where presumably clever programmers can 
do good things.  :-)

> (1) I'm shopping at a major retailer's website and 
>decide to sign up
> for their newsletter.  What happens if the confirmation 
>message uses
> HTML content (not uncommon)?  

Obviously, it SHOULD NOT use HTML content, for the simple 
reason that said retailer CAN NOT be certain that the 
person asking to be on their newsletter list is able to 
handle (or WANTS to receive) HTML-burdened mail messages.

The first such "welcome to our mailing list" message ought 
to be sent in plain text, asking for permission to send 
HTML (or, perhaps better, at the time the user requests to 
be placed on the mailing list, they should be able to 
specify HTML or plain text, and with the explicit mention 
that if the HTML option is chosen, they might need to 
enable that option from the sender in question).

> But let's presume everyone 
>has bought
> into your scheme, so a plain text confirmation arrives. 
> I now have
> to take the additional step of confirming (where? has my 
>email client
> but updated to include an interface for this?) 

Ideally, yes, the client software ought to include 
awareness of and support for this capability.  I've been 
trying to talk Microsoft into adding such a capability 
into both Outlook and Outlook Express, for example.  (Who 
knows whether I've caught the ear of anybody worthwhile 
with the concept yet, or not).

> that I'll 
>accept HTML
> from the same source in the future.  

Hopefully that's capable.  One approach would be for such 
an "aware" client to pop up a box with a "this is the 
first time you've gotten E-mail from this sender, what do 
you want to do with mail from them in the future?" dialog 
box.  There could be a variety of options (discard, 
forward, redirect, archive, I'll decide later/ask me again 
for future nonconforming mail from this sender, whatever). 
 There could be different choices for "conforming" versus 
"nonconforming" messages, perhaps.  I don't think we have 
to design the user interface to that level HERE, in any 
case.

> Assuming that the confirmation
> and the newsletter come from the same source, that is, 
>which also is
> not always the case.

True, although if that is recognized as important to 
legitimate mailers, they can certainly correct such 
questionable behavior.

> (2) I'm working with an HTML design firm.  They're doing 
>a rush job
> for me, which has to be confirmed on Saturday so it can 
>be turned over
> to my IT staff to be installed on the company website 
>before Monday
> morning; but I'm going to be out of town, so I want a 
>copy of the work
> sent to another address such as a freemail service so I 
>can easily
> review it.  

1)  You can certainly simply have them post their work to 
a Web site (theirs?) and send you an e-mail with the URL.

2)  If you're working with an HTML design firm, obviously 
you can whitemail their E-mail address to send you HTML.

> The HTML contains images and scripts, but 
>the design firm
> has never sent mail to that freemail service before, and 
>I don't know
> which of their team of designers might be sending the 
>final product.

Either ask, or have them post the page to a (private) Web 
site where you can go and review it.

Even if you don't know which specific designer might be 
sending you the message, nothing in my proposal would 
prevent (for example) the capability of the software 
allowing you to whitelist by domain, regardless of what 
user there sent the mail (you might have a different 
"catch-all" default permissions list than the per-user 
permissions list).

> How much effort must I go to up front to be able to tell 
>them they can
> send me an attachment that I know will reach me?

Again, I don't see a problem here.

> (3) My biggest customer is a giant corporation which 
>requires its
> employees to use Microsoft Outlook and to attach a 
>vCard-like signature
> to every email, using a background stationery and having 
>an image of
> the company's latest logo because they're engaged in a 
>major rebranding
> initiative.  Not surprisingly, they have massive 
>turnover, so the
> people there who send email to a variety of people at my 
>company
> changes every several weeks.  Who's responsible for 
>upkeep of all of
> those individual agreements to exhange HTML with each 
>other?

Again, the recipient could presumably set up a "catch-all" 
whitelisting which would enable selected E-mail HTML 
features and selected attachment types from any user at a 
given company's domain.  For example, allow (hell, even 
REQUIRE) V-card attachments or JPGs for mail from that 
domain, but (for example) not allowing scripting, 
executable attachments, or ActiveX.

[comment #3]

> Subject: Re: [Asrg] Re: bounces, and anti-spam 
>principles

>>> Our overall system is designed towards _zero_ false 
>>>positives.  In at
>>> least one way, we're theoretically (and near 
>>>effectively) there.  With
>>> DNSBLs and other techniques.
>> 
>> Obviously, I'd have to reserve judgement until I've 
>>experienced your
>> "zero false positives" idea.  Let's just say that I've 
>>got a healthy
>> degree of skepticism.
> 
> I have 10+ years worth of exposure to this model (I 
>built the thing)
> with a user population of 60-120K and extreme FP 
>aversion all the way up
> to the CEO, you're welcome to come visit and I'll 
>demonstrate it for you.
> 
> It only fails to be "zero false positive" when the 
>legitimate sender
> fails to read/follow the rejection notice.  Which 
>happens a lot more
> than I'd like, but if the message isn't worth that much 
>to the sender,
> it's probably not worth doing much about it on our end 
>either.

1)  How do you determine who the actual "legitimate 
sender" is?

2)  How do you make sure they receive it?

>>> Not everyone has that small a set of correspondents to 
>>>cope with, and
>>> the "new correspondent" issue remains a big problem.
>> 
>> The total set of correspondents doesn't have to be 
>>small. It just needs
>> to have a relatively small number of NEW correspondents 
>>that NEED to use
>> "advanced"/riskier features and therefore require 
>>whitelisting.
> 
> The question is how do you even know of the new 
>correspondents, when
> you're being bombarded with dozens or hundreds of new 
>correspondents per
> day.

To begin with, conforming E-mails from new correspondents 
(no HTML, no attachments, size within limits, and passed 
by SpamAssassin or similar) will sail right through.  No 
problem.

Presumably each recipient could configure the "what to do 
with nonconforming e-amils from unknown senders" option as 
the user wished.  Discard mercilessly, allow me to look at 
the text part, or whatever.

> It's all well and good, if the spammers aren't forging 
>names, to allow
> them one bite before you null the sender, but today's 
>reality isn't like
> that.  The "one bite" on sender, or even on url or 
>content, essentially
> means you have to eat almost all spam.  Because spammers 
>mutate their
> content and senders that much.  

Absolutely.  They generate random From; addresses and 
random Subject: information (and random other stuff too, 
like Received: lines indicating bogus original senders). 
 But of course, we here all ought to know that full well.

That's why my personal recommendation for "best practice" 
is to simply block -all- HTML messages from unfamiliar 
senders, on the idea that they are trying to conceal 
something, or at the very least are being inconsiderate 
and clueless enough that I don't want to hear from them.

Others might well choose diffeently, of course.

> We're tracking spammers 
>who use in
> excess of 1000 different domains in urls.  Can per-user 
>techniques cope
> via whitelisting or blacklisting?  Not a chance.

That's what makes blacklisting not work... there are 
infinitely many E-mail addresses you need to blacklist.

A fine-grained whitelist (and one which allows mail from 
reasonable but non-whitelisted users) DOES offer a finite 
task, that can be relatively easily handled.

> The only way your techniques can work effectively is if 
>you assume that
> the recipient is getting very little spam.  

I don't think it's particularly volume-sensitive... other 
than the fact, of course, that ANY system could 
conceivably be flooded by a sufficiently determined DoS 
attack.

> Well, 50% of our users are
> being sent almost no spam.  

Your users are very fortunate.  Perhaps they haven't had 
those E-mail addresses for very long, or don't do much 
with them.

> But that doesn't help with 
>the guy getting
> sent 4000/day.  Or even the hundreds getting 50 or more.

I don't see why my approach won't handle such cases with 
ease.

> The only way your technique works is if you're one user 
>with a limited
> variety and volume of spam.  But not everybody is in the 
>same situation
> as you.

Again, I don't agree with your conclusion.  My proposed 
default rule and fine-grained whitelisting (combined with 
SpamAssassin or similar content scanning on the remainder) 
with have a VERY high efficacy at detecting and dealing 
with spam.

>> Ideally, each such correspondent only requires ONE click 
>>(one time) for
>> the user to agree to allowing them to use the more 
>>advanced features. 
>> That might be done following an initial negotiation 
>>E-mail where the
>> sender introduces themself and requests the ability to 
>>send more
>> elaborate mails.
> 
> You seem to be focussing on only blocking "advanced 
>features".  A large
> percentage of spammers don't use them anyway.  If all 
>your spam consists
> of mutating text-only spam with mutating headers, your 
>technique has no
> effect.

That's true, if the SpamAssassin component is unable to 
make a reasonable determination.  On the other hand, mail 
that has passed the initial fine-grained-whitelist 
criteria is at least going to be devoid of most of the 
tricks which make things VERY problematical for the 
content scanners.

Some users COULD choose to ONLY allow E-mail from the 
whitelisted E-mail addresses, if they decide that is the 
approach that makes them happiest.  (e.g. set the "default 
maximum size accepted" to zero bytes).

>> Introductory E-mails should NOT automatically presume 
>>the desire or
>> willingness of the recipient to receive HTML-burdened 
>>E-mails.
> 
> But if all spam were indistinguishable from 
>"introductory e-mails",
> where are you then?

No worse than at present.

And BETTER, since the "no attachment, no HTML" default 
rule would seriously cripple zombie spambot army 
recruitment.

> And indeed, probably most spam isn't distinguishable 
>from some vague
> notion of "introductory e-mails" by your technique.

That at least switches the problem to a relatively simpler 
problem of improving the antispam content-based 
detection... i.e. making a better version of SpamAssassin.

At least the future SpamAssassin is relieved of nearly all 
of the nearly impossible cases it is forced to (not?) deal 
with today.

>> The main problem with content filtering is caused by 
>>ruses based on HTML
>> and attachments.  These techniques serve to obscure the 
>>content of the
>> E-mail, and ALL BY THEMSELVES the presence of such 
>>content in E-mails
>> (at least in E-mails from unfamiliar senders) can be a 
>>priori evidence
>> of hostile intent, or spamming.
> 
> If you can _detect_ those ruses.  

Of course.  Some of my filtering code I've written, for 
example, looks for things like "obscured" URLs, or 
obfuscated IP addresses in URLs.

> You and I may be able 
>to detect it in
> on a per-message basis with visual inspection, but 
>computers generally
> can't, say, identify sentences generated using random 
>words.  Try
> building a filter for hipcrime some day...  Plain text. 
> Random headers.
> No "advanced features".  Good luck.

You're also faced with things like foreign language 
E-mails (Chinese, for example).  Even using grammar tests, 
E-mails might have a large amount of bogus 
respectable-looking content (say, ten jokes followed by 
the 'payload' spam).  Again, at some point you're going to 
see some spam slide through.  I believe my approach would 
take a BIG bite out of it, though.

> Much of the recent evolution in spam content techniques 
>has been to get
> away from ruses that are detectable as ruses.  It used 
>to be a common
> technique to insert random invalid html tags in spam. 
> Defeatable by
> simply looking for invalid html tags or meta (eg: 
>tag)/content ratios.
> But they don't do that anymore, do they?  

I don't know... since the filters I most recently wrote 
T-canned all that stuff anyhow.  But I don't doubt that 
spammers will eventually mutate to try to avoid schemes 
that don't work anymore.

One of my goals is to HUGELY increase that set.  :-)

> And 
>meta/content ratios can be
> _extremely_ high in legitimate email (just look at the 
>gunk that outlook
> produces for simple emails some day).

Are you talking about HTML?

> Look for identical gifs?  Well, they stopped emitting 
>identical gifs
> months ago.

I'd block ALL mail containing GIFs (or any other kind of 
attachment) by default, from unknown senders.  Such tricks 
hit a solid brick, impenetrable wall.

> I had some luck with looking for gif geometry (scan for 
>gif prefixes
> containing identical image dimensions).  That stopped 
>working too.

Yeah, I don't think such schemes have much potential.

>>>> Again, when you have a LOT of users (and possibly MANY 
>>>>servers) behind a
>>>> NAT router, denying mail from that IP address results in 
>>>>simply too much
>>>> collateral damage. More to the point, it's a very blunt 
>>>>instrument for
>>>> the job, and it's relatively simple to do very much 
>>>>better.
>>>
>>> So far, there's no indication of the latter being true. 
>> 
>> I do note you don't refute my objection on principle. 
>> :-)
> 
> But in fact, I do.
> 
> Let's cut to the chase.  Your argument about source IP 
>blocking being a
> blunt instrument is well-taken and true.  It _is_ a 
>blunt instrument.
> 
> So's a sledgehammer.  You wouldn't use a sledgehammer to 
>install window
> trim would you?  But a carpenter probably still has and 
>uses a
> sledgehammer for a different part of the same job of 
>building a house.
> 
> Your argument assumes that IP-blocking is the ONLY 
>technique being used
> - - if all you have is IP-blocking, trying to 
>discriminate between good
> and bad content from a given IP (say an ISPs MTA) 
>doesn't work.
> 
> Well, yeah, duh ;-)
> 
> Your argument assumes that the administrator hasn't made 
>any effort to
> make an intelligent choice on which DNSBL to use - and 
>is hence at the
> mercy of capricious listings of any old random IP.
> 
> Well, yeah, if you've chosen to use BLARS, you get what 
>you deserve.
> 
> Yup both true.  But so what?
> 
> What's to prevent you from doing the intelligent thing 
>and using
> multiple complementing techniques simultaneously? 

Nothing at all, and in fact that's what I'm proposing.

I just happen to believe that IP address reputation is 
neither necessary nor sufficient (and perhaps not even 
particularly desirable) as a component in that.

> The XBL, for example, is _extremely_ reliable at 
>detecting compromised
> end-user machines.  All by itself it will block 70-85% 
>of all spam.  

Fine.  But it also blocks LEGITIMATE mail coming from 
those machines, right?

> By it's very nature it doesn't list real MTAs (eg: ISP 
>smarthosts).  

What if the spam is sent through ths "smarthost"?  You 
might claim that's not being done today, but nothing 
prevents spammers from doing that.

> It has
> a false positive rate lower than virtually any content 
>filter.
> Certainly _way_ lower than any notion of trying to block 
>spam based on
> detecting "advanced features".

Fine, if you're a believer in IP address filtering, then 
use that as a component.  But I still believe that it's 
not as good as a better differentiation technique, with 
less collateral damage.
  
> Why not let the users choose?  How many of your users 
>know what the XBL
> is?  About 5 of mine _might_.  I'm not even sure you do. 
> How many of
> them have spent the manhours needing to learn what knobs 
>do a good job?

I think the nature of 'knobs' given to end users will OF 
COURSE be different than the type of 'knobs' given to 
IETF-types.

> Less than that.  How many of them would do nearly as a 
>good job at it?

Few, IF they were adjusting IETF-type knobs.  That's NOT 
what I'm proposing.

> Even I, with over 10 years of experience in this game, 
>could not do an
> acceptable job on email landing in my _own_ mailbox 
>using your
> techniques.  

I guess a lot depends on what you consider "acceptable", 
and how good the content scanner is that you have.

[comment #4]

> Subject: Re: [Asrg] Re: bounces, and anti-spam 
>principles

>> [how users configure their whitelist rules]
>> 
>> >The problem being that out of the 60,000 seats here, 
>>perhaps less
>> >than 10 of them are able to competently configure a set 
>>of rules like
>> >what you have.  
>> 
>> That's a software implementation issue, not an inherent 
>> problem in the approach.  I envision a button to click 
>>on 
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I guess that's the main reason why your ideas aren't met 
>with wild
> enthusiasm here. You "envision" that this would be 
>simple to build and
> to use, but it's not even clear that you have even built 
>a prototype
> which you use yourself, much less deployed the system 
>for "ordinary
> users", which aren't quite sure what an "HTML mail" is, 
>and have never
> heard about an "ActiveX component".

I've built and have used portions of what I propose. 
 Obviously it will work best if the proposed default rules 
are widely used.

As for "deploying it for ordinary users", I think I could 
make the same claim regarding all these DNS-based 
proposals that y'all are so fixated on.  Again, good 
software implementation doesn't have to depend on users 
understanding those details (but it COULD offer that level 
of detail, for advanced users who cared).  Since I don't 
work at an ISP, and I'm not being paid to do this stuff, 
what I build and use myself is more a function of what the 
effort/payback looks like for ME as an individual user.

I don't think where things fall on that particular 
equation are especially relevant to whether the approach 
would be a good one for more widespread adoption.  :-)

>> that simply says "allow E-mails like this from the same 
>> sender in the future" and where the software will open 
>>the 
>> keyway JUST enough to allow that type of message if seen 
>> again from that sender.
> 
> So Uncle Bob will see that a mail from Aunt Matilda was 
>blocked because
> it contained an "executable attachment". Since he wants 
>to get mail from
> Aunt Matilda (and Aunt Matilda is a nice lady, she 
>wouldn't send him
> anything bad, would she?) he clicks on "allow E-mails 
>like this from the
> same sender in the future". Oops!

Presumably he could tell from the rest of the content in 
the mail message that it really didn't look like E-mail 
from Aunt Matilda.  And clicking on the option could be 
followed by a suitably dire dialog box, explaining the 
risks of executable attachments and asking if he is REALLY 
REALLY sure that the mail in question is REALLY from who 
it claims to be.  It could even suggest that the user call 
the sender on the phone to verify the legitimacy of the 
E-mail message, if they are not 100% sure.

And, presumably if he later found that his faith was 
misguided, he ought to be able to later revoke that 
permission...!

>> How that recognition is accomplished, whether by 
>>something crude like
>> simple GREP-type scanning, or something brain-damaged 
>>like RegEx
>> pattern matching,
> 
> You know what the two middle characters in "grep" stand 
>for, do you?

Regular expressions.

Which can be used in more elaborate ways than a simple 
pass with something like GREP normally allows, thus the 
distinction I tried to (ineffectively, it seems) make.

Gordon Peterson
http://personal.terabites.com
1977-2007  Thirty year anniversary of local area 
networking

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

---

From: Dan Oetting <[email-masked]>
Date: Sun, 28 Jan 2007 00:56:12 -0700

On Jan 27, 2007, at 6:43 PM, [email-masked] wrote:

>> Here is my proposal. I'm sure I haven't thought of everything so   
>> please tell me where it breaks or how spammers are going to game  
>> it.  The goal is to stop the majority of the spam while not  
>> loosing ANY  legitimate email (broken MTAs don't count).
>
> To begin with, crude IP blocks will ALWAYS lose legitimate mail,  
> because a single IP address can send both legitimate and zombie- 
> generated mail.  I propose that NO ISP-based software will be  
> capable of differentiating one from the other... but the recipient  
> possibly will know how to do that, at least for familiar senders.

I guess I didn't think to include a definition for "Lost Email".

Lost Email is any email that is sent but not presented to the user  
and does not generate a DSN to the sender. When referring to a  
receiving system loosing email it is assumed that the sending system  
is following standard procedures.

>> This is not intended to  replace existing blocklists but to handle  
>> the initial onslaught from  a spam source until the source can be  
>> properly categorized and listed.
>> Connections from unknown source addresses would be initially  
>> rejected  by returning a temporary error code (4xx) for a  
>> probation period. The  probation period could be as short as 5  
>> minutes depending on how fast  the blocklists can respond. The  
>> reject would occur after the  recipient list is accepted so the  
>> recipients can be checked against  local spamtraps and valid user  
>> lists. After the probation period,  global blocklists would be  
>> queried to find the current reputation of  the source.
>
> While spamtraps and valid user lists are helpful sometimes, they  
> will not trigger if the spammer is using "fresh" E-mail address  
> lists which are also devoid of spamtrap E-mail addresses.

Is there evidence that spammers have 100% spamtrap free lists? Where  
are they getting their addresses from and why can't we seed spamtrap  
addresses there? It cost almost nothing to try different forms of  
spamtrap seeding. I'd like to open this part up to all the armchair  
anti-spammers with a distributed process. The trap submissions could  
be scored on the basis of their verified spam counts and derated for  
getting non-spam.

>> Proposals #2 & #3 are for a fast global block advisory and   
>> distribution network
>> Any email addressed to a spamtrap would generate a report to a  
>> local  trap handler. The local trap handler would forward  
>> appropriate  reports to the regional or global blocklist managers.  
>> The blocklist  managers would publish advisories based on the  
>> reputations and counts  of the traps that were hit by the sending IP.
>
> IP address blocking, again, is simply too crude.  A further and  
> more serious problem is that you have basically no way to be 100%  
> sure of who the "sending IP" actually is.
>
> For just one example, Yahoogroups

That's obviously a non-starter. Yahoogroups is a subscription based  
service. A valid spamtrap would not be subscribed to any group  
(unless it was designed to catch spammers harvisting group addresses  
in which case it would take special precautions to exclude group  
related emails from the spamtrap reports).
>
> Or let's say that Aunt Gertrude's machine gets infected by a worm,  
> which starts sending out E-mails using Aunt Gertrude's account at  
> the ISP, via the ISP's mail server. Are you going to block  
> everything coming from that mail server?  What if it is a VERY  
> large ISP?  Obviously, it would have been nice if that ISP's  
> outgoing mail rules had caught the messages, but in this case let's  
> recognize that they didn't.

Spam has to be stopped somewhere. But read the full set of  
proposals...  If a site has never received email from that IP before  
it would quarantine the first emails from that IP as in proposal #1.  
The automatic spamtrap network would generate an advisory that the IP  
is sending UBE. Then depending on the reputation of that IP from all  
sources the site would choose to a: continue the quarantine, b:  
accept the email and possibly apply additional filtering or c: reject  
the email from that IP.

>> If the source is  emitting a sufficient volume of spam this  
>> happens before the initial probation period expires.
>
> Again, that's part of what I said about spammers engineering their  
> mails so they squeak under whatever threshold is established to  
> trigger spam alarms.  That can be done on content, sending rate, or  
> any other generally/widely used criteria.

So I've forced the spammer to send less spam. This I call progress.

>> DNS is probably a poor choice for distribution of the global fast   
> Obviously, since a change in status doesn't propagate quickly enough.
>
>> I think a form of flood distribution  through a mesh of peer nodes  
>> would be more robust. The distribution  would feed local databases  
>> that could be queried directly or through  a DNS front end. The  
>> mesh can handle data from multiple sources and  needs no central  
>> authority.
>
> And how do you propose to prevent worms from targeting and flooding  
> or doing other Denial of Service attacks on that mesh?

What port and IP address is the worm going to target? You won't know  
unless you've talked with the admin of that node and even then you  
might have a private port that only you know about. And even if you  
do manage to take out one node (or a dozen) the mesh survives and  
routes around the damage. The affected nodes re-negotiate the links  
with their peers and are back on line in short order.

>> If email addressed to certain spamtraps is received from a sender   
> Original sender?  A forwarding sender?  An aggregating sender?  How  
> does the objecting MTA make sure?

That should be "sending MTA". Although an ISP might register an  
alternate protocol to report suspect email for an entire net block.  
The registration is primarily to prevent sending reports directly to  
a spambot.

>> accept the mail but  return a specific code in the response that  
>> the sending MTA can  interpret to make a determination if the  
>> sender is spamming.  Alternatively, the site may register a  
>> different protocol to use for  the back report. The spamtraps used  
>> for back reporting should be  different from those reported to  
>> global blocklists to prevent  disclosing the traps to rogue ISPs  
>> that would forward them to  spammers. Only some of the traps would  
>> be used for back reporting to  any given network or host.
>
> I'm not convinced that returning ANY "spamming!" status to any  
> imagined source is really worthwhile.  To begin with, I think that  
> most such reports will be discarded or archived, and just create  
> additional worthless traffic on the Net.  Secondly, if the "back  
> reporting" can be misdirected (by counterfeiting E-mail or ISP  
> addresses) then the creative spammer can induce the bounce message  
> MTA to effectively be the "proxy" "sending source" of the spam,  
> tricking it into sending the bounce message to the third party.  (I  
> used to get a fair amount of such apparently-intentional bogus  
> bounces... and indeed, I still get a lot of antispam bounces into  
> my "catch-all" E-mail account at a vanity domain, generally  
> resulting from spammers who are counterfeiting randomly generated  

1. Read in this proposal where I said "registered". 2. Do you know  
what a response code in SMTP is? 3. I never "bounce" anything.

>> Proposal #5 is a quarantine while a site is listed in a block  
>> advisory.
>> Established sources that get listed in local or global block   
>> advisories should have their mail quarantined while the mail is   
>> sorted out. The best place to quarantine the mail is on the  
>> sending  server. It's already queued there and if it is eventually  
>> determined  that it should be rejected,
>
> determination be made?  I will suggest that (at least for some non- 
> obvious cases) that determination could be difficult or even  
> impossible to do accurately.

The determination to quarantine email while waiting for additional  
information to become available or the possibility that the sending  
site will clean up the spam first should be easy to make. Are you  
perhaps referring to the rules for implementing proposal #2?

> Apart from (as previously noted) the problem of determining after  
> the fact with any real accuracy just who the "sending server"  
> actually is, particularly for multi-hop mail deliveries.   It's  
> easy enough to forget that not all E-mail deliveries are simple  

First you have the intranet delivery on the sending side

	user-> (users ISP internal servers) -> Sending MTA

Then you have the internet delivery

	Sending MTA ----> Receiving MTA
or
	Sending MTA ----> (open relay) ---> Receiving MTA

And finally the intranet delivery on the receiving side

	Receiving MTA -> (receiving ISP internal servers) -> destination

I am only concerned with the internet delivery. Anything else the  
ISPs can handle on their own. So all internet email deliveries are  
simple ISP->ISP transactions.

> Vanity domains that provide mail forwarding are just one example of  
> a way that intermediaries enter into a mail delivery chain.   
> Aggregators/forwarders like Yahoogroups are another.

If the vanity domain allows you to create hundreds or thousands of  
forwarders to addresses you don't own to make it look like a spammer  
site it deserves to be blocked.

>> that can be done with a 5xx on the next  delivery attempt instead  
>> of sending a bounce.
>

If the decision is to reject all mail coming from that IP then  
returning the 5xx response will cause the sending MTA to generate a  
DSN that will be returned to the legitimate sender.

>> If the sending ISP is  on their toes an offending user or host  
>> will be shut down quickly and  the remaining mail will be  
>> delivered when the block advisory is  lifted or expires.
>
> And what happens to their legitimate outgoing mail in the meantime?

It sits in the quarantine until the block advisory is lifted and then  
gets delivered normally. Nothing is lost except for some sleep by the  
admin on duty for the sending ISP.

>> Local whitelists can be used to allow mail to  bypass the quarantine.
>
> That's fine, but (again) I believe that traditional, simple  
> "whitelists" are not nearly adequate.  I believe that a viable  
> whitelist MUST comprise a recipient/sender pair of addresses, AND  
> additional criteria regarding what the recipient expects to receive  
> from the sender in question.
>
> More to the point, once THAT is done, I believe that IP address  
> blocking becomes essentially superfluous (and indeed, COUNTER  
> productive).

None of my proposals say "block" anything. I say issue advisories in  
proposal #2, some users might want that information. I propose  
quarantining email when it's looking suspicious. The sending ISP  
knows where the email came from which is something that the receiver  
cannot know in all cases. If anybody is going to decide that email is  
spam it is the sending ISP that has the best information to make that  
decision. Proposal #4 provides the one key piece that the sending ISP  
doesn't have to determine that their user is sending UBE (aka spam).

If you as an ISP are offered these free tools to help control spam  
emanating from your network are you going to say "no thanks, we'll  
just send the spam and let everybody else clean it up"?

-- Dan Oetting

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 28 Jan 2007 12:33:19 +0100

On 2007-01-27 19:43:23 -0600, [email-masked] wrote:
> and zombie-generated mail.

We've been using the spamhaus dnsbls for several years and I can't
remember a single false positive. IP adresses which send legitimate
mails are simply not listed there (or if they are, there are so few of
them that it's indetectable). 

It is true that they aren't sufficient, but they reduce spam by quite a
bit (they're by far the most frequent reason for a permanent error) with
practically zero false positives.

I don't know why you insist that they would have to list a single IP
address which sends both legitimate and zombie-generated mail. Just look
at spamhaus and you can see that this is false.

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 28 Jan 2007 14:50:56 +0100

> >and anti-spam principles)

Please don't answer mails from different people in different subthreads
in the same mail. Your mails are already too long, and an argument is
hard to follow if the answer the content of one mail is in the answer to
a different mail.

> >(1) I'm shopping at a major retailer's website and decide to sign up
> >for their newsletter.  What happens if the confirmation message uses
> Obviously, it SHOULD NOT use HTML content,

But it does. And if you're a small ISP or IT department and your users
can't get their newsletter, guess who they'll blame? You or the major
retailer? And what's more likely to change? The way you filter mail or
the way the major retailer sends their newsletter?

You can do that if you're the DoD. The DoD recently banned HTML and they
can get away with it, because almost everyone they exchange mail with
is more interested in talking to the DoD than the DoD is talking to
them. If the DoD doesn't get your mails, that's your problem, not
theirs.

> for the simple reason that said retailer CAN NOT be certain that the
> person asking to be on their newsletter list is able to handle (or
> WANTS to receive) HTML-burdened mail messages.

He doesn't care. 99% of his prospective customers can handle it, and
they will be enticed by the pretty pictures. He can afford to lose 1%
(who are probably the more critical customers anyway).

> >Assuming that the confirmation and the newsletter come from the same
> >source, that is, which also is not always the case.
> 

That "questionable behaviour" is pretty much standard, and there are
good reasons for it.

> >(3) My biggest customer is a giant corporation which requires its
> >employees to use Microsoft Outlook and to attach a vCard-like
> >signature to every email, using a background stationery and having an
> >image of the company's latest logo because they're engaged in a major
> >rebranding initiative.  Not surprisingly, they have massive turnover,
> >so the people there who send email to a variety of people at my
> >company changes every several weeks.  Who's responsible for upkeep of
> >all of those individual agreements to exhange HTML with each other?
> 

Yes, he could. But he doesn't want to. It's not his job to worry about
which types of content a certain user (which he not even know) might
send to him in the future.

> conceivably be flooded by a sufficiently determined DoS 

It's a DoS attack on the user, not on the system. The user has to look
at the mails, decide whether they are legitimate, which of their
features he wants to accept from that sender (and whether "that sender"
means only that particular address, or the whole domain or something in
between).

> >Well, 50% of our users are being sent almost no spam.  
> 
> Your users are very fortunate.

Nope. That's the normal distribution. Many users get almost no spam,
many get a an intermediate amount of spam and a few literally drown in
spam.

> Perhaps they haven't had those E-mail addresses for very long, or
> don't do much with them.
> 
> >But that doesn't help with the guy getting sent 4000/day.  Or even
> >the hundreds getting 50 or more.
> 

That guy has to scan through 4000 messages each day to check if there
wasn't one which he did want. Maybe not every day, but at least every
time he suspects that a mail might have been blocked.

> >>Introductory E-mails should NOT automatically presume the desire or
> >>willingness of the recipient to receive HTML-burdened E-mails.
> >

Depends on what you define as "better" and "worse". You will get less
spam (about 50% less, I would guess from looking through my spambox),
but you will also get less legitimate mail (I don't know how common HTML
mail is on average - that seems to vary a lot). 

> rule would seriously cripple zombie spambot army 

Only if it is widely adopted. Which it won't be, because the early
adopters will have to deal with severe problems.

> Fine.  But it also blocks LEGITIMATE mail coming from 

There is no legitimate mail coming from those machines. Maybe a message
or two for every million messages being blocked. Probably less.

> prevents spammers from doing that.

Then there is an ISP to complain to and the ISP knows which of their
users has a compromised machine and can do somthing about it. If the ISP
doesn't do something about it, he may find that some may refuse to
accept mail from him or apply more stringent filters to it. But that
doesn't have anything to do with the XBL.

You are assuming that IP-based reputation is used in an all-or-nothing
way. It isn't. There is more than one list, and just because an IP
address is or isn't on a specific list doesn't mean that all mails from
this address are rejected or accepted. It is one criterion among many.

> >>>The problem being that out of the 60,000 seats here, perhaps less
> >>>than 10 of them are able to competently configure a set of rules
> >>>like what you have.  
> >>
> >I guess that's the main reason why your ideas aren't met with wild
> >enthusiasm here. You "envision" that this would be simple to build
> >and to use, but it's not even clear that you have even built a
> >prototype which you use yourself, much less deployed the system for
> >"ordinary users", which aren't quite sure what an "HTML mail" is, and
> >have never heard about an "ActiveX component".
> 
> proposals that y'all are so fixated on.

No, absolutely not. Apart from not being fixated on "DNS-based
proposals" (if anything, I'm fixated on bayesian filtering), I see two
very important differences here: 

1) DNSBLs like Spamhaus' SBL+XBL aren't "proposals". They have been
operational for years and their strengths and weaknesses are well-known.

2) The user has absolutely nothing to do with them. I can simply enable
them on a system-wide basis and be confident that I will maybe have to
deal with one complaint every few years. 

> Again, good software implementation doesn't have to depend on users
> understanding those details

I doubt that. In real life users get mails with "advanced features" all
the time and if they have to decide whether they can safely enable them
they need to understand them. I predict that the average user will
either have configured that system to accept anything from anybody
within a week or give up on email entirely.

> would be a good one for more widespread adoption.  :-)

It is irrelevant whether it "would be good". User's simply won't adopt
it. Period. It will ask them questions they don't understand twenty
times a day, so they will resort to either clicking "yes" all the time
or "no" all the time. As a result they won't get the mail they want and
they will still get mail they don't want. In addition they will feel
dumb because they don't understand all those questions, and they will be
angry at the computer (it should handle that stuff without asking stupid
questions) and the IT staff or ISP (it's their job to handle that
stuff). A week later the system will be shut off again and the poor guy
who thought "it would be good" will be fired.

> >>that simply says "allow E-mails like this from the same sender in
> >>the future" and where the software will open the keyway JUST enough
> >>to allow that type of message if seen again from that sender.
> >
> >So Uncle Bob will see that a mail from Aunt Matilda was blocked
> >because it contained an "executable attachment". Since he wants to
> >get mail from Aunt Matilda (and Aunt Matilda is a nice lady, she
> >wouldn't send him anything bad, would she?) he clicks on "allow
> >E-mails like this from the same sender in the future". Oops!
> 
> from Aunt Matilda.

To do that he has to read it. What good is an anti-spam scheme which
requires me to read all my spam?

	hp

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 28 Jan 2007 23:56:30 -0500

> many get a an intermediate amount of spam and a few literally drown in

Indeed.  Such a distribution is consistent with everyone I've talked to
who have made such measurements.

>> Perhaps they haven't had those E-mail addresses for very long, or

Some of them have had them for many years and get almost none.  Others
have had them for a matter of months, and drown.

One of the leading causes of getting deluged is being a member of IETF
lists....

> time he suspects that a mail might have been blocked.

It's physically impossible to find one or two legits out of 4000/day.

> mail is on average - that seems to vary a lot). 

It's _very_ high here.  Corporate likes their HTML and attachments.

> or two for every million messages being blocked. Probably less.

We go several days between seeing an XBL FP (out of 1.6M blocked per
day).  And they're fixed - we whitelist and help the sender get their
systems disinfected so they can stay out of the XBL.  Email not lost,
sender's machine is fixed, less spam hits the Internet.

Is that a win-win or what?

Like I keep saying, we get higher FPs out of our content filters.

Even the extremely obvious - HELO'ing as our domain - we see
_legitimate_ (home brew) MTAs doing it.

>> prevents spammers from doing that.

It's harder.  And we have a blocking solution for that.

You don't have to run ONLY DNSBLs.  What's that I keep saying?  _Hybrid_
filtering systems.

> this address are rejected or accepted. It is one criterion among many.

He's also assuming that if you're using DNSBLs you're somehow prevented
from using other techniques simultaneously.  That is simply not the case.

> operational for years and their strengths and weaknesses are well-known.

And default recommendations in many packages.  Such as SpamAssassin.

> deal with one complaint every few years.

We have a few more than that, but we fix them.

> within a week or give up on email entirely.

If we tried that here, the average user would be screaming at me why
their filters weren't working.  Or working too well.

> requires me to read all my spam?

What good is an anti-spam scheme that, after you've seen the one good
html email from Aunt Matilda, blindly delivered you the virus her
machine sends the next day?  Or the spam forged in her name?

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 29 Jan 2007 10:11:39 -0500

Dan Oetting wrote:
>>> please tell me where it breaks or how spammers are going to game it. 
>>> The goal is to stop the majority of the spam while not loosing ANY 
>> because a single IP address can send both legitimate and
>> zombie-generated mail.  I propose that NO ISP-based software will be
> Lost Email is any email that is sent but not presented to the user and
> does not generate a DSN to the sender. When referring to a receiving
> system loosing email it is assumed that the sending system is following
> standard procedures.

By that definition, our filters NEVER EVER lose an email.

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 29 Jan 2007 10:22:38 -0500

> at spamhaus and you can see that this is false.

He seems to be rather inconsistent in his position:

1) IP blocking _may_ (if you're not careful on what IPs you block) list
mixed sources.  Yeah, but, the content filtering methodologies he
proposes have false positives _too_. Not to mention that the content
filtering he's proposing has higher FPs than most DNSBLs.

2) If you use IP blocking, somehow you're magically restricted to ONLY
using that one technique (and hence will miss spam from mixed sources).
 Yet, he uses multiple techniques so that he can catch the things that
one technique misses with another technique.  Why is he insisting that
IP blocking can only be used on its own, when he's using multiple
techniques himself?

Say, yahoogroups.  Why does he feel that someone using DNSBLs is
restricted to using DNSBLs to block spam from yahoogroups?  Nothing can
be further from the truth.

DNSBLs are just one of many spam filtering techniques.  There's nothing
special about them that prevents you from using it in combination with
others.  Especially if you use it in a scoring methodology like
SpamAssassin.

---

From: Barry Shein <[email-masked]>
Date: Mon, 29 Jan 2007 15:30:15 -0500

Here's an idea.

Let's list a few easy to agree with, egregious, spam (let's not
quibble the word I'm just talkin' here) methodologies such as zombie
bots in broad terms, outline the harm (undermines faith in the
internet as surely as counterfeit money does in currency, fraud, etc),
call on all govts of the world (kinda like that guy in "The Day The
Earth Stood Still") to not only legislate but to actually FUND
enforcement of that legislation with some of the usual dire warnings
everyone tosses in with such calls to action (if you don't act
decisively CHILDREN WILL DIE!)

Wrap that up in an RFC and publish it with a bunch of announcements to
the press and some fanfare.

I mean, c'mon, the internet is a globalized, probably trillion dollar
business and spam is a corruption in that business and needs, as one
aspect of its eradication, some doors kicked in and front page photos
of miscreants being dragged away in shackles and having their lives
wrecked for their efforts. Otherwise it's just a technological parlor
game.

I believe that govts, not all but ya gotta start somewhere, whose job
it is to enforce some reasonable civility and ground rules in the
business sphere, await some leadership and we could provide it.

If nothing else it's more productive than typing in war stories about
RBLs which is kinda like trying to focus a light beam by tossing
broken shards of a mirror in the air...likely to cause seven years bad
luck as well.

-- 
        -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: Douglas Otis <[email-masked]>
Date: Mon, 29 Jan 2007 13:48:48 -0800

On Jan 29, 2007, at 12:30 PM, Barry Shein wrote:

> If nothing else it's more productive than typing in war stories  
> about RBLs which is kinda like trying to focus a light beam by  
> tossing broken shards of a mirror in the air...likely to cause  
> seven years bad luck as well.

The US Federal government allows bulk sending of unsolicited email.   
While this is spamming, US law permits it.   Providers with customers  
that are bulk sending unsolicited email must rely upon AUPs to be  
able to exclude this behavior.  Other countries ignore egregious  
behaviors that might also be seen as possible revenue sources.   
Effective measures may require international agreements.  What rules  
should be adopted to improve behavior on the Internet?  With spam  
establishing the principle, what is left remains a discussion of price.

-Doug

---

From: Barry Shein <[email-masked]>
Date: Mon, 29 Jan 2007 17:48:44 -0500

> The US Federal government allows bulk sending of unsolicited email.   

To be precise the "US Federal government" allows nothing specifically
in this realm. There are activities which are expressly or by
implication of law illegal or subject to regulatory or civil
limitations.

If you know of a US law which says "you can send unsolicited email",
other than by implication of the absence of any express prohibition, I
would be interested in seeing a reference to that law or similar.

That said, much noxious email is sent via computers which have been in
effect "hijacked" by use of viruses, trojans and other malicious
software. These are often called "zombie botnets", a commonplace term
of art which could be more precisely defined, and I referred to them
specifically in the email to which you are responding but you elided
that phrasing in your response.

Creating or exploiting "zombie spambot" behavior is illegal in the US
and elsewhere, and has been occasionally prosecuted. The problem, thus
far, has been lack of enforcement.

 > behaviors that might also be seen as possible revenue sources.   

Such countries might exist, perhaps de facto, but their intention,
e.g., for the revenue sources, as you claim, versus a simple lack of
prioritization of enforcement activities is unclear.

If you know of any country which has expressly stated in a policy,
memo, legislation, or other publicly memorialized statement what you
claim above I'm sure it would be edifying to this group.

I personally know of no such document and as such where you claim the
lack of expressed intent, policy, or judgement as intentioned I will
claim that same silence as mere negligence and the intent as quite the
opposite.

Otherwise I have to assume your statement is a purely speculative
inference into the /mens rea/ of more than one nation (you use the
plural) whom you do not even list. Could you at least provide an even
partial list of these nations whose intentions you are relating?
Better would be the specifics you base your claims upon.

 > Effective measures may require international agreements.  What rules  

This is a weak attempt to make the best the enemy of the good.

Nations, as a rule, have legal sovereignty over their own
citizenry. There is no need for international agreement to enforce a
nation's own laws on their own citizens.

If a citizen of a country is breaking that nations' laws, such as
fraud or electronic trespass, even if the act is not ultimately within
that nation, they would have legitimate claim to first juridiction in
any criminal, regulatory, or similar matter, generally by exercise of
long-arm statutes or limitations thereof.

Where there might be exceptions they could be dealt with in the future
as a refinement of the proposed action. Thus, making the best the
enemy of the good.

I reject the proposition that because there might be some case which
requires more broad and as yet non-existant powers to prosecute that
therefore we must not encourage the prosecution of behaviors which
easily fall within the current purview of each nations' sovereignty.

That, to repeat, is merely an attempt to make the best the enemy of
the good which is a highly undesireable goal.

 > establishing the principle, what is left remains a discussion of price.

Lawful nations recognize a duty to enforce their laws, particularly as
they relate to their own citizenry's behavior. The mere existance of
unlawful nations does not argue against that point.

There is nothing new or unusual about criminal fraud, trespass,
vandalism, or similar which may arguably cross international
boundaries whether it involves postal, telephony, telegraphy, wire
transfer, internet, or other means.

My suggestion was simply a suggestion that we produce a document
ultimately issued by the IETF urging more effective enforcement of
laws as they stand.

Whether further refinement would help is a separate matter and
unnecessary a priori, even if a desireable goal. Sufficient unlawful
behaviors enable "spam", such as zombie botnets, that it would be
progress to simply make a public request that the laws (&c)
prohibiting those behaviors be better enforced.

Absence explicit substantiation of your claims I consider your point
of view purely speculative, and not meriting further discussion. But
by all means provide detail as suggested.

-- 
        -Barry Shein

---

From: Douglas Otis <[email-masked]>
Date: Mon, 29 Jan 2007 21:46:11 -0800

On Jan 29, 2007, at 2:48 PM, Barry Shein wrote:

> To be precise the "US Federal government" allows nothing  
> specifically in this realm. There are activities which are  
> expressly or by implication of law illegal or subject to regulatory  
> or civil limitations.

,---
|CAN-SPAM Act of 2003:
|SEC. 3. DEFINITIONS.
|(16) SENDER-
| (A) IN GENERAL- Except as provided in subparagraph (B),
| the term `sender', when used with respect to a commercial
| electronic mail message, means a person who initiates
| such a message and whose product, service, or Internet
| web site is advertised or promoted by the message.
|
| (B) SEPARATE LINES OF BUSINESS OR DIVISIONS- If an entity
| operates through separate lines of business or divisions
| and holds itself out to the recipient throughout the
| message as that particular line of business or division
| rather than as the entity of which such line of business
| or division is a part, then the line of business or the
| division shall be treated as the sender of such message
| for purposes of this Act.
|...
| (5) INCLUSION OF IDENTIFIER, OPT-OUT, AND PHYSICAL ADDRESS
| IN COMMERCIAL ELECTRONIC MAIL- (A) It is unlawful for any
| person to initiate the transmission of any commercial
| electronic mail message to a protected computer _unless_
| the message provides--
|   (i) clear and conspicuous identification that the message
|       is an advertisement or solicitation;
|  (ii) clear and conspicuous notice of the opportunity under
|       paragraph (3) to decline to receive further commercial
|       electronic mail messages from the sender; and
| (iii) a valid physical postal address of the sender.
'___

OPT-OUT allows 10 days before messages related to a line of business  
must stop.  Prior to receiving the OPT-OUT request, email-addresses  
can be exchanged with other entities.  Valid domain names, lines of  
businesses, and physical addresses can change every 10 days and  
remain within the guidelines of the CAN-SPAM act, even when each spam  
does obtain an OPT-OUT request.

This act is specifically allowing the bulk sending of unsolicited  
email and demands recipients to stop the abuse which may continue  
unabated for 10 days.  Following that point in time, a new entity can  
carry forward the abuse.

> If you know of a US law which says "you can send unsolicited  
> email", other than by implication of the absence of any express  
> prohibition, I would be interested in seeing a reference to that  
> law or similar.

The key word here is "unless".

> That said, much noxious email is sent via computers which have been  
> in effect "hijacked" by use of viruses, trojans and other malicious  
> software.

The same noxious email can be sent in bulk legally from non-hijacked  
computers.  It is hard to know which SMTP clients have been hijacked  
via malware.

> These are often called "zombie botnets", a commonplace term of art  
> which could be more precisely defined, and I referred to them  
> specifically in the email to which you are responding but you  
> elided that phrasing in your response.
>
> Creating or exploiting "zombie spambot" behavior is illegal in the  
> US and elsewhere, and has been occasionally prosecuted. The  
> problem, thus far, has been lack of enforcement.

It is much easier to detect when a computer is sending bulk  
unsolicited emails.  The problem is rather simple.  When it is legal  
to send bulk unsolicited bulk email, spamming fails to provide  
actionable evidence of a crime.

>> While this is spamming, US law permits it.   Providers with  
>> customers that are bulk sending unsolicited email must rely upon  
>> AUPs to be able to exclude this behavior.  Other countries ignore  
>> egregious behaviors that might also be seen as possible revenue  
>> sources.
>
> e.g., for the revenue sources, as you claim, versus a simple lack  
> of prioritization of enforcement activities is unclear.

When one country bombards another and calls the spam traffic legal,  
this may tend to diminish a level of cooperation in other areas.

> memo, legislation, or other publicly memorialized statement what  
> you claim above I'm sure it would be edifying to this group.

There are several countries that offer an undesirable level of  
cooperation.  One such country is the USA.

> I personally know of no such document and as such where you claim  
> the lack of expressed intent, policy, or judgement as intentioned I  
> will claim that same silence as mere negligence and the intent as  
> quite the opposite.

Review the CAN-SPAM Act of 2003.

> plural) whom you do not even list. Could you at least provide an  
> even partial list of these nations whose intentions you are  
> relating? Better would be the specifics you base your claims upon.

One should not point to others, when at least three fingers point  
back toward yourself.

>> Effective measures may require international agreements.
>

When talking about spam, it is hard to describe a law that permits  
spam as being even within the realm of being good.

> citizenry. There is no need for international agreement to enforce  
> a nation's own laws on their own citizens.

The Internet requires a level of cooperation between different  
countries, as network related crime easily extends beyond geographic  
boundaries.

> fraud or electronic trespass, even if the act is not ultimately  
> within that nation, they would have legitimate claim to first  
> juridiction in any criminal, regulatory, or similar matter,  
> generally by exercise of long-arm statutes or limitations thereof.

We are not talking about what is illegal, but what is consider legal,  
but damaging.

> Where there might be exceptions they could be dealt with in the  
> future as a refinement of the proposed action. Thus, making the  
> best the enemy of the good.

What proposed action?  This is a problem of _no_ action.

> I reject the proposition that because there might be some case  
> which requires more broad and as yet non-existant powers to  
> prosecute that therefore we must not encourage the prosecution of  
> behaviors which easily fall within the current purview of each  
> nations' sovereignty.

Each country is not independent with respect to the Internet.  While  
each router falls within the purview of each owner, cooperation among  
owners must be sustained for the network to function.

> the good which is a highly undesireable goal.

I think you mean some ridiculous set of guidelines that prescribe how  
to send bulk unsolicited email is the enemy of practical  
protections.  There is no practical means to know whether a computer  
is spamming due to malware.  We both agree that BOTs have become a  
serious problem.  Ask good citizens via laws to stop spamming and  
focus attention on those that continue.

>> What rules should be adopted to improve behavior on the Internet?   
>> With spam establishing the principle, what is left remains a  
>> discussion of price.
>
> Lawful nations recognize a duty to enforce their laws, particularly  
> as they relate to their own citizenry's behavior. The mere  
> existance of unlawful nations does not argue against that point.

The principles of behavior are compromised when resources are abused  
for unfair, unsafe, and impractical promotion just to make a buck.

> transfer, internet, or other means.

The subject line is about spam.  Trespassing and vandalism are  
clearly poorly considered by the CAN-SPAM Act of 2003.

> ultimately issued by the IETF urging more effective enforcement of  

These laws must change.  One can not start with the premise that  
spamming is okay provided there is some method to opt-out.

> unnecessary a priori, even if a desireable goal. Sufficient  
> unlawful behaviors enable "spam", such as zombie botnets, that it  
> would be progress to simply make a public request that the laws  
> (&c) prohibiting those behaviors be better enforced.

Knowing what is a due to malware and what is legal can not be  
determined as long as spamming remains legally sanctioned.

-Doug

---

From: Barry Shein <[email-masked]>
Date: Tue, 30 Jan 2007 02:28:57 -0500

I was thinking of something like this (sketchy outline, any use of
"spam" is simply short-hand for "Insert Better Term"):

Spam (definition) currently comprises over 90% (cite) of email
traffic.

The enabling technology for the vast majority of spam are botnets
(description.)

Botnets are particularly problematic because:

  a) They allow spammers to command far more resources for sending
  spam than the underlying business activity could ever fund; the
  resources used are all stolen. Literally hundreds of millions of
  copies of a message can be sent out for little or no cost to the
  spammer.

  b) They allow for address mobility; spam sources can shift between
  thousands of purloined computers rapidly thus defeating
  identification of the source of the spam for the purpose of blocking
  or, where warranted, criminal investigation.

  c) They are a fundamentally criminal enterprise relying on the
  injection and exploitation of malicious software into victim
  computers.

Although technological schemes are constantly being developed to
counter this trend there are limits to the effectiveness of these
schemes without a framework of effective law enforcement.

The sheer volume and nature of botnet spamming activity, largely
unchallenged legally, presents a problem which even a reasonably
effective technological solution can not counter.

It is likely that absent these botnets spammers as we know them would
be rendered largely impotent. As stated earlier their business model
does not allow for the enormous resources we see their activities
currently consume.

Investigation, apprehension, and conviction of operators and customers
of these botnets are few and far between. They operate with little
fear of legal consequence currently.

We therefore request, as a body whose primary mission is the
reliability, integrity, and advancement of the internet, increased law
enforcement resources be devoted to providing an effective legal
challenge to these botnets as an adjunct to our own technological
efforts.

-- 
        -Barry Shein

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 30 Jan 2007 07:23:00 -0500 (EST)

On Mon, 29 Jan 2007, Douglas Otis wrote:

>> To be precise the "US Federal government" allows nothing specifically in 
>> this realm. There are activities which are expressly or by implication of 
>> law illegal or subject to regulatory or civil limitations.
>
> ,---
> |CAN-SPAM Act of 2003:
> |SEC. 3. DEFINITIONS.
> |(16) SENDER-

While I agree that this provision represents an amazing lack of spine on 
the part of the congress, it isn't as though I get any spam that conforms 
to all three of these identifiers. In fact, no more than a couple of 
percent include even one (usually (i)). So this provision does not yet 
represent a barrier to anti-spam activity. No doubt if the FTC or DOJ took 
some action against US based spammers, they would make hast to conform to 
the law, but that hasn't happened yet. And nothing in the law interferes 
with private action to reject messages, spam or not.

Daniel Feenberg

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 30 Jan 2007 07:35:17 -0500 (EST)

>  injection and exploitation of malicious software into victim

...

Isn't the solution to decline ALL mail from obvious pool addresses? I hear 
the argument that you can't put pool addresses in a DNSBL because next 
week the bot will have a different address. So put the whole pool in the 
BDSBL. Again, I hear the argument that a legitimate MTA may get the 
address next.  In our tests last year we didn't find any legitimate 
correspondes (to us) behind pool addresses. I hesitate to say so, but 
isn't much of the noise from critics of blocking pool addresses from 
self=styled political revolutionaries and paedophiles who (mistakenly) 
think that the FBI won't read mail if it doesn't travel through the ISP 
MTA? As for the operators who claim that their ISP MTA is slow, can't 
those handfull of malcontents just get another smarthost? (see
http://www.nber.org/sys-admin/smarthost.html ) I'd be willing to do 
without their messages in the meantime.

Looking at my after-Spamhaus connecting MTAs, virtually all are pool 
addresses, or no reverse name lookup. Do other MTAs get legitimate mail 
from pool addresses? Spamhaus has just last week started to offer a 
listing of dynamic addresses, but it is only mildly effective so far. But 
so far no FPs, either.

Daniel Feenberg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 30 Jan 2007 10:58:16 -0500

Daniel Feenberg wrote:

> Isn't the solution to decline ALL mail from obvious pool addresses? I
> hear the argument that you can't put pool addresses in a DNSBL because
> next week the bot will have a different address. So put the whole pool
> in the BDSBL. Again, I hear the argument that a legitimate MTA may get
> the address next.  In our tests last year we didn't find any legitimate
> listing of dynamic addresses, but it is only mildly effective so far.
> But so far no FPs, either.

[Aside: the PBL (Spamhaus's "policy blacklist", which is essentially the
same as "pool addresses" was pre-primed with NJABL dynablock and has
been growing since.  That is _not_ "mildly effective". See
http://www.sdsc.edu/~jeff/spam/cbc.html]

In the large scale the difficulty is identifying what's a "pool".  One
effort to determine that in terms of rDNS names is called "Enemies List"
(aka "EL") - which is some 15,000 regexes.  That's 3 years of
accumulated knowledge by the guy who runs it.

Many ISPs aren't good at naming of pools and properly renaming them when
the machine becomes "non-generic", or placing non-pool in the middle of
pools.  So there is always a significant problem with non-poolish
machines having poolish names.  There's a substantial number of
providers who don't understand that naming their servers (mail or
otherwise) something other than 1.2.4.5.example.com is bad.

An effort to RFCize (probably BCP) naming conventions has been going on
for quite some time by one "lone crusader", but unfortunately, _even_ on
the anti-spam side where they'd really love to see it, it's long been
dismissed as foolishly naive and will never happen.

EL and PBL/dynablock _work_ rather well.  But, don't kid yourself, there
are FPs with it.  It isn't a solution per-se, perhaps best demonstrated
that despite how good they are, the XBL still does better.

The problem isn't just pool addresses, much as it isn't just other subsets.

Even if it were "the solution", the PBL with something like 5-6 years of
accumulated "pool addresses" behind it (from many many sources) should
demonstrate that it's no easy task.  Pool listings are _frightfully_
expensive in man-hours to maintain.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 Jan 2007 07:56:19 -0800

> with private action to reject messages, spam or not.

The mere fact that a computer is spamming is not automatically a
violation of the law that would permit an order to stop.  There are some
spammers giving the appearance of following these guidelines, in some
cases even making it difficult for providers with poor AUP to stop their
traffic.  Expecting private individuals to ignore this traffic
represents a fundamental lack of international cooperation.

This act also removes an ability for private citizens to seek
compensation.  Without official action of enforcement, nothing happens.
As there is seldom any financial incentive to take action, spam
officially has been made into something that everyone is expected to
endure.  Attempting to enforce the act will just make it more difficult
recognize legitimate messages, but spamming will continue.  So why
bother?

Marking messages, just as with the Do Not Spam list, is another concept
that appears to have been dropped from the act as well.

-Doug

---

From: Dan Oetting <[email-masked]>
Date: Tue, 30 Jan 2007 10:34:59 -0700

On Jan 30, 2007, at 5:35 AM, Daniel Feenberg wrote:

> Isn't the solution to decline ALL mail from obvious pool addresses?

Would it help to have a wiki for Asrg? Somewhere that each concept  
can exist in it's own space spanning time so it doesn't have to be  
brought up over and over and rehashed with all the same arguments.  
The wiki would be a useful group resource to list what has been tried  
and how it succeeded or failed.

-- Dan Oetting

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 30 Jan 2007 12:35:10 -0500 (EST)

On Tue, 30 Jan 2007, Chris Lewis wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel Feenberg wrote:
>

The addition of the PBL to the sbl-xbl mildly increased the effectiveness 
of blocking. I agree that the total amount blocked is substantial, but the 
PBL does not yet contribute much.

> accumulated knowledge by the guy who runs it.

A few dozen of those regexs cover 90% of the total. It would be great to 
have the rest, but missing a few isn't fatal to the project.

> otherwise) something other than 1.2.4.5.example.com is bad.

Of course the nicest naming scheme is 1.2.3.4.pool.example.com, and the 
worst is pool-1-2-3-4.example.com, simply because of the way dns wildcards 
work. *.pool.example.com is only one line. pool*.example.com is supported 
by bind (or anything else that I know of).

> that despite how good they are, the XBL still does better.

The more MTAs use these tools, the fewer false positives there will be.

> The problem isn't just pool addresses, much as it isn't just other subsets.

I don't understand - why is that an argument against solving part of the 
problem?

> expensive in man-hours to maintain.

More expensive than fixed sources of spam? The PBL is handicapped by its 
rule not to list any address without the permission of the ISP. When they 
drop that rule and it will be quite effective.

One has to remember that MAPS killed open relays quite quickly - behavior 
modification works. The operators of MTAs behind generic addresses are 
almost all insignificant and can easily adopt a smarthost once they 
realize they need one. I understand it is hard to make major ISPs kowtow 
to RFCs. This isn't in that league of difficulty at all.

Daniel Feenberg

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBRb9rF53FmCyJjHfhAQJdnQP9E/fAOm6BCZcjNuDDWArJMCxfN3xswKJx
> H4+a95UR576nZGiQRnZJzg8XvnqJw8dcZkv/IMNZSTrw1Oz2IBZqTSQ2NNfSZmCH
> ZLGNYhY+osN4Lj18lq0ujUsbXVc0qrmp8Iu6AcrBE1fD1qLNSUSwjvdRjDe6jlXK
> IxvNIqAV3yU=
> =ywLI
> -----END PGP SIGNATURE-----
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 30 Jan 2007 10:25:39 -0800

Daniel Feenberg wrote:
> One has to remember that MAPS killed open relays quite quickly - 
> behavior modification works. The operators of MTAs behind generic 
> addresses are almost all insignificant and can easily adopt a 
> smarthost once they realize they need one. I understand it is hard to 
> make major ISPs kowtow to RFCs. This isn't in that league of 
> difficulty at all.
Talk about the law of unintended consequences. This gives an immense
amount of control to providers who have many, many built in conflicts. It's
not just email that's at stake here, but end user servers/services in 
general.
If we force everybody who would have the audacity to run their own services
to go through their local unfriendly ISP, then we might as well  rebuild the
circuit switched network with its stellar track record of delivering new and
innovative services. The ability to route around damage was one of the key
innovations of the net. I'd much rather keep that and look for other ways to
deal with our problems than reverting back to known dysfunction.

       Mike

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 30 Jan 2007 13:47:54 -0500

> The addition of the PBL to the sbl-xbl mildly increased the
> effectiveness of blocking. I agree that the total amount blocked is
> substantial, but the PBL does not yet contribute much.

Even incrementally.  Check out Makey's stats.  Going from 80K -> 100K
ain't small potatoes, when you consider that even _before_ that,
Spamhaus typically been 70-85%.

> worst is pool-1-2-3-4.example.com, simply because of the way dns
> wildcards work. *.pool.example.com is only one line. pool*.example.com
> is supported by bind (or anything else that I know of).

When it boils down to it that that sort of difficulty makes little
difference to the concept.  Even if you had almost "perfect" pool
coverage, there's still a _very_ high volume of junk from non-pool areas.

> I don't understand - why is that an argument against solving part of the

It isn't, only that it's perhaps not as major a contributor to the
solution as it may appear to you.

> rule not to list any address without the permission of the ISP. When
> they drop that rule and it will be quite effective.

Ah, no.  You're missing some important detail about the PBL.  Go reread
the PBL web pages, and understand the difference between the 127.0.0.10
and 127.0.0.11 returns.

> addresses are almost all insignificant and can easily adopt a smarthost
> once they realize they need one. I understand it is hard to make major
> ISPs kowtow to RFCs. This isn't in that league of difficulty at all.

I have a lot of experience behind trying to deal with people on "pools".
 It's not as simple as you think.  Not the least being the vast number
of poorly enumerated pools.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 Jan 2007 11:35:03 -0800

On Jan 30, 2007, at 10:25 AM, Michael Thomas wrote:

> The ability to route around damage was one of the key innovations  
> of the net.  I'd much rather keep that and look for other ways to  

A great deal of dysfunction and risk is caused by SMTP extensions as  
well.  SPF/Sender-ID is a good example of a protocol that may cause  
hundreds of DNS transactions relating the bounce, PRA, or a DKIM  
domain with an SMTP client IP address.  (DKIM still allows replay.)   
Had the SMTP client name been validated, association with _any_ other  
originating domain within a message could be assured within a single,  
small, and safe DNS transaction.

Obfuscating roles of the client transmitting messages continues with  
the DKIM protocol.  Imposing a limitation on who's behalf the message  
is signed offers transmitting clients a means to extort private keys  
from domain owners using the service.  This will result in a security  
disaster when an MTA holding thousands of private keys becomes  
compromised.  Clients transmitting or signing email MUST be  
identifiable and spam MUST be made illegal.  Lack of SMTP client  
identification and spamming is _directly_ responsible for the spread  
of much of today's malware!

The criminal element has demonstrated individuals can not be easily  
tracked in today's Internet.  Those in the business of transmitting  
messages should identify their clients and not abuse network  
resources by allowing bulk unsolicited promotions of any sort.   
Identifying the client transmitting or signing messages does not mean  
individuals are being identified or that freedom has been lost.

-Doug

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 30 Jan 2007 15:15:50 -0500 (EST)

On Tue, 30 Jan 2007, Michael Thomas wrote:

>> almost all insignificant and can easily adopt a smarthost once they realize 
>> they need one. I understand it is hard to make major ISPs kowtow to RFCs. 
>> This isn't in that league of difficulty at all.

Not everybody, only those with dynamic addresses. and only for port 25, 
and only when communicating with strangers, and they could use any 
smarthost that would have them, not just that of their ISP.

Dan Feenberg

---

From: Barry Shein <[email-masked]>
Date: Tue, 30 Jan 2007 17:52:54 -0500

To be more specific, I was thinking of an RFC which adds to RFC2635
(FYI00035), FYI00038, and builds on ideas expressed in RFC4686,
RFC2505 (BCP00030), and FYI00036 but aimed at trying to delineate
where law enforcement (e.g., zombie bot armies) efforts would be
important and useful.

A published document expressing the need for more law enforcement
involvement in certain areas of this problem could help policy makers
et al allocate resources appropriately.

Put another way, it would be naive to wait for LEOs, policy-makers,
regulators, et al, to discover for themselves how they can help.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Tue, 30 Jan 2007 18:09:31 -0500

Besides the reasonable technical problems expressed with identifying
pools there's another consideration.

Blocking pools as a general rule is a serious retreat and, though it
might be stopgap, it's not technological progress.

However necessary blocking pools strikes me as, at best, a necessary
(and with luck temporary) evil, analogous to telling people to stay
out of a public park at night because of the danger of criminal
attack. It yields a huge front to the criminals.

It sets the stage for the widespread balkanization of the net. Next
might be having to pay for accounts with blessed hosts to send email
at all to large swaths of other hosts (e.g., fortune 500.)

-- 
        -Barry Shein

---

From: [email-masked] (Justin Mason)
Date: Tue, 30 Jan 2007 23:11:56 +0000

> regulators, et al, to discover for themselves how they can help.

For what it's worth, LEOs are certainly attending plenty of conferences
and private get-togethers that cover these points; APWG, London Action
Plan, and probably others, all feature law enforcement.

I do believe they're already quite aware, and are working on the problem
(although silently and behind closed doors, for some reason, which
in my opinion is not a great way to proceed).

--j.

---

From: Barry Shein <[email-masked]>
Date: Tue, 30 Jan 2007 18:14:19 -0500

On January 30, 2007 at 11:35 [email-masked] (Douglas Otis) wrote:
 > tracked in today's Internet.

Gosh, they seem to round them up by the hundreds when child
pornography is involved.

I think it's more a matter of will than means.

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 31 Jan 2007 01:18:50 -0000

>Plan, and probably others, all feature law enforcement.

Indeed.

R's from the MAAWG meeting in San Francisco,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 Jan 2007 17:44:26 -0800

On Jan 30, 2007, at 3:14 PM, Barry Shein wrote:
>> The criminal element has demonstrated individuals can not be  
>> easily tracked in today's Internet.
>

This is not a forum to discuss how individuals remain anonymous.   
Those with a larger incentive (and perhaps more likely traced) seem  
to know the needed steps.  Almost any server used to send on port 25  
is traceable.  Remaining anonymous is arranged prior to the outbound  
public server, as might be needed for good reasons.  Those entities  
that control the public services should be held accountable when  
permitting unsolicited bulk email.  Those transmitting messages into  
the public should include a signature clearly acknowledging their  
role.  These signatures should also be permitted to indicate that  
they were signed for anyone.  Signatures should not demand prior  
arrangements be established by the email-address domain, as is now  
the case for DKIM. : (

Recipients should not be expected to bear the cost of bulk  
unsolicited email.  There are plenty of appropriate forums on the  
Internet.  Those in the business of publicly transmitting messages  
should clearly and unambiguously identify themselves.  This precludes  
domain indirection permitted by SPF/Sender-ID scripts, or using  
someone else's DKIM keys.  When there is a problem reported, these  
entities must receive the reports and take steps to curtail future  
events.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 30 Jan 2007 22:14:54 -0500

> Plan, and probably others, all feature law enforcement.

Eg: MAAWG.

> in my opinion is not a great way to proceed).

Not entirely closed, but you may have to be near the door to know it exists.

This is not to suggest that you can sit back and wait, but at least,
there is some traction as people are getting a better idea of what they
face, begin to learn how to deal with it, and array the right people.

---

From: Barry Shein <[email-masked]>
Date: Wed, 31 Jan 2007 14:51:42 -0500

> Plan, and probably others, all feature law enforcement.

I'm not surprised there's some interest, but that's not quite the same
as trying to generate the thrust for an Operation Asimov: Kill the
misbehaving zombie robots and bust their human masters.

That takes money, resources, and drive at a high level, as we've seen
US Atty Genl Gonzales' office internet child porn initiatives.

Some confirmation from respected sources might help.

-- 
        -Barry Shein

---

From: John Levine <[email-masked]>
Date: 31 Jan 2007 21:52:35 -0000

>Some confirmation from respected sources might help.

Well, at this moment, I am sitting in a session at MAAWG where the
FTC's lead spam investigator is telling us about his investigation
process and he and ISP reps are going over issues like whether they
notify customers when they get a subpoena.  Also present are the
Canadian competition bureau, analogous to the FTC, and I believe I saw
some guys from DOJ.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Wed, 31 Jan 2007 18:32:24 -0500

> Canadian competition bureau, analogous to the FTC, and I believe I saw

Well that's of course great but some publicized thrust and focus from
the IETF couldn't hurt the thinking of the policymakers who have to
actually allocate budgets and other priorities.

Is there any disagreement that if we could just snap our fingers and
make the zombie botnets disappear (or 90% disappear) that "spam" (and
related) wouldn't immediately have all the emotional punch of
"off-topic posting", some odd msg you get and delete?

Put another way, zombie botnets are the enabling technology of spam
(phishing, etc.)

Easier said than done I realize, but it's inherently illegal to create
and operate zombie botnets, and I don't mean just in the US, most
anywhere on the planet.

The law enforcement and regulatory agencies of the planet have a lot
more resources they can muster than we ever could.

Even if we could come up with the FUSSP we'd still probably face
enormous hurdles of deployment.

Vigorous legal pursuit wouldn't preclude technical efforts in parallel
unless of course spam just disappears as a result.

There is no other way we know of to send out on the order of one
billion emails per day for a cost which even approaches the expected
value of those messages and would so successfully evade already
commonplace blocking and filtering methods.

Does anyone disagree with that?

Can't we say that in some very public way? Does anyone doubt that's
true?

Sometimes I think the problem otherwise insightful technical people
have in thinking about spam is wrapping their heads around what it
takes to send out O(billion) messages a day from a handful of base
sources and we keep retreating to imagining spam as being much like
sending this message other than the content and intent.

It's not.

It's as if I could make this message appear in 100 million mailboxes
in the next few hours, despite many efforts to the contrary.

I couldn't. You couldn't.

It takes a zombie botnet.

There are other issues, but I'm focusing on this one as the most
egregious and, I hope, easiest to agree on in terms of contribution to
the problem and legal/moral unambiguity.

-- 
        -Barry Shein

---

From: Douglas Otis <[email-masked]>
Date: Wed, 31 Jan 2007 18:27:06 -0800

On Jan 31, 2007, at 3:32 PM, Barry Shein wrote:

>> process and he and ISP reps are going over issues like whether  
>> they notify customers when they get a subpoena.  Also present are  
>> the Canadian competition bureau, analogous to the FTC, and I  
>> believe I saw some guys from DOJ.
>
> Well that's of course great but some publicized thrust and focus  
> from the IETF couldn't hurt the thinking of the policymakers who  
> have to actually allocate budgets and other priorities.
>
> Is there any disagreement that if we could just snap our fingers  
> and make the zombie botnets disappear (or 90% disappear) that  
> "spam" (and related) wouldn't immediately have all the emotional  
> punch of "off-topic posting", some odd msg you get and delete?
>

Put another way, legalizing spam enables high infection rates needed  
to support the existence of Bot-Nets.  Malware content within an  
email message and websites (required to OPT-OUT) provide bad actors  
ample opportunity to leverage exploits that exist in email or website  
browsers.  The completely absurd stipulations of OPT-OUT is satisfied  
by a link to a web site of all things.  CAN-SPAM mandates victims  
expose themselves to two very likely modes of infection.  Browsers  
continuously have new and complex features added, where many flaws  
exist and can be exploited.  Bulk messaging with embedded links  
provides a highly dangerous infection vector.

> Easier said than done I realize, but it's inherently illegal to  
> create and operate zombie botnets, and I don't mean just in the US,  
> most anywhere on the planet.

By making spam illegal, the act of transmitting a high volume of  
unsolicited messages would then clearly serve as evidence of crime.   
This would place accountability onto the provider.  The efforts  
behind SPF and DKIM are aimed at passing blame to a hapless  
customer.  Thousand of domains might share an SPF authorized server  
which is likely to have only a few IP addresses.  The identity  
limitations with DKIM ensures providers will also control their  
customer's private keys.  Who sent and signed the message is  
_designed_ to remain a mystery.  Some mode of accountability.

> The law enforcement and regulatory agencies of the planet have a  
> lot more resources they can muster than we ever could.

Providers must acknowledge they are primarily responsible for much of  
the mess that exists.  Providers must be held accountable when any  
high volume of unsolicited messaging emerges from their networks.

> enormous hurdles of deployment.

The first step would be to make spam illegal.  Illegal for  
individuals to send, and for providers to ignore.  After all,  
providers control access.  Allow those damaged to seek relief.   
Making spam illegal would make networks many orders of magnitude safer.

> Vigorous legal pursuit wouldn't preclude technical efforts in  
> parallel unless of course spam just disappears as a result.

Twice the technological effort is attempting to pass blame to some  
likely hapless customer.  Make a law that requires providers sign all  
public messages with their own keys.  There should even be laws that  
prohibit signing with a customer's key.  Customers can reference  
specific keys used on their behalf instead.  There should be laws  
against the use of highly danger authorization schemes, such as SPF/ 
Sender-ID.  Poisoning or destroying DNS is easily accomplish with  
this loathsome technology.  A technology also aimed at side stepping  
accountability.

> billion emails per day for a cost which even approaches the  
> expected value of those messages and would so successfully evade  
> already commonplace blocking and filtering methods.
>

Enforcement must make any spam illegal AND hold providers  
accountable.  To ensure enforcement, allow anyone damaged to seek  
legal relief.

> Can't we say that in some very public way? Does anyone doubt that's  

There are few providers that want to consider their accountability as  
part of the cost of doing business.  No one can afford to clean up  
the mess being made.  Just as was done to control the abuse of fax  
machines, the same must be done with respect to email.  At least with  
a fax machine, programs were not in jeopardy, just resources.

> sending this message other than the content and intent.

Content or intent do not need to be considered.  The volume and lack  
of solicitation provides key differences.  The lack of solicitation  
allows for rather easy methods of enforcement.  One grows weary  
logging trespasses that can only be considered privately as bad.   
Those making these private assessments remain exposed to civil  
proceeding as a result.  Spam must be illegal to stop it.  There are  
very few legitimate businesses using spam to promote their products,  
and yet the US Congress has legalized spam.  OPT-OUT is a dangerous,  
impractical, and an immoral excuse.

> It's as if I could make this message appear in 100 million  
> mailboxes in the next few hours, despite many efforts to the contrary.

The number of messages does not matter.  The number of unsolicited  
messages does.

> I couldn't. You couldn't.

Not true.  There are some rather large mailing lists where such  
volumes are possible.  Lists enjoying a large number of subscribers  
are also typically well managed.

> It takes a zombie botnet.

There are many other techniques.  Malware provides many avenues to  
exploit networks.  Make spam illegal to slow the spread of malware.

> egregious and, I hope, easiest to agree on in terms of contribution  
> to the problem and legal/moral unambiguity.

You seem to have the cart before the horse.  In addition to spam,  
perhaps other rules could be considered regarding system scanning.   
This again would require that providers take action to block access.   
Vista comes equipped with what is likely an ideal command and control  
system for controlling Bot armies.  The system must protect from the  
spread of infection.  Prevention is worth a pound of cure.

-Doug

---

From: Barry Shein <[email-masked]>
Date: Wed, 31 Jan 2007 21:54:08 -0500

You seem to prefer a technological solution, possibly with some new
legislation making "spam" illegal. I have no particular problem with
that, in spirit.

But I do believe that a more immediate goal of urging law enforcement
(et al) to better enforce existing laws (&c) regarding the creation
and operation of, e.g., zombie botnets is valuable without in any way
detracting from other efforts stated.

Put another way, we don't board up all our windows and let burglars
run free. We try to make burglary dangerous for burglars.

-- 
        -Barry Shein