Subject: [Asrg] 0. General

From: "denny " <[email-masked]>
Date: Tue, 21 Oct 2003 09:43:39 -0400

Hello everyone!
I have a lot to say and I hope it's worth hearing....
I am new here and in the process of reading the papers I have found and learining the "rules" for the whole IETF deal. let me start by saying a few things about my background as it relates to my view on the whole "SPAM" subject.
 
I have been using computers and networks for at least 15 years, my first networks were NOVELL Lans and the local schools. in the mid-to-late90's I was working in Califonia for an ISP where in 3 years we went from about 2,000 customers to over 30,000. along the way growing the email system was a major challenge as traffic grew.
 
now I am more in the database applications side of things than the network side of it but have done some of everything. I have done a lot of work with RADIUS to create SQL databases to record and search for IP useage ... sometimes it was needed to locate crooks.
 
I am not generaly in favor of "more goverment" but belive that some laws will be needed to help controll spam.
 
Ok .... on with some comments that might count:

some things I belive at this time are:
 
1)  make the sender "Pay Postage" will get us further than trying to filter the junk / spam.
2)  the SMTP email system needs to get modified to make forgery of headers very difficult.
3)  common practice, the law and the SMTP software need to make "accountability" a requirement not an option.
4)  as has been stated elsewhere: classifing "SPAM" via program is difficult and requires constant adaptation.
5)  the problem is as much , perhaps mostly an issue of total traffic volume and the burden it puts on the whole community.
6)  the traffic and related handling of it costs us real money.
7)  today the recipent bears the cost of the unwanted traffic.
 
does anyone belive that the 7 points are wrong?

if my points are right then I would say that fighting an up-hill battle over classifiying spam which is technicaly very difficult and will never really be possible in our lifetimes unless we develop some very major computer AI systems is almost a waste of our time.
 
Instead I would say that we should shift the effort to the elements of the network and it's infrastructure that we can manage effectivly and then come back to the issues of "SPAM Vs. HAM" later on.
 
I would say that if we add accountability to SMTP and make it difficult if not impossible for the orginator to "Hide" and also perhaps make it a criminal issue when an originator attemtps to misdirect the reciver then we will be much closer to winning the spam wars.
 
I would adopt to some degree the model used by phone companies, when the originator sends more traffic to the reciver then the orginiator pays the reciver a fee based on the units sent.
 
the fee can be small for each message.
 
why I feel this is the right way to go:
 
1) it would motivate each mail system operator to care about the volume of traffic they generate.
2) it would shift the burden of generating high outbound traffic back to the orginating party.
3) it woulf give the "victims" funds to pay for the exess unwanted traffic.
4) it would shift the legal stance on dealing with the problem as follows: it is difficult to create a solid legal definition of "SPAM" and due to the inherent subjective nature of any definition leaves room for argument. also if we try to "Block SPAM" or "Outlaw SPAM" then they can claim unfair restraint , bias , censorship and so on. if we move to a business accounting basis then there can be no argument that the process is unfair. you have to "Pay your bills" if you want to use the network. and if you do not pay your bills then you can't keep ending me traffic. and thats not a "Blacklist" it's not "Censorship" and so on.... it's basic legal business practice.
 
I would say the the effect of this would be to reduce the total SPAM by a huge amount.
 
it would force the hidden relays, the forged headers and other garbage to stop or slow to a crawl.
 
then the reciver would know who sent them the ad for whatever and be able to complain to them directly. and the indiviudal would have a much simpler time banning the senders.
 
the real chalenge with this approach would be getting the right kinds of laws / regulations in place to allow a victim to make thier case.  but that issue is there now... but due to the lack of accountability and the ease of email forgery it places a heavy burden on the victim.
 
well what do you think?

--
=============================================
Denny Figuerres
[email-masked]
---------------------------------------------
Twenty billion junk e-mail messages sent per day may
potentially take 20 billion seconds to delete. A human life is a
mere two billion seconds long. In effect, spammers kill ten
people each day.

--

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 21 Oct 2003 11:13:12 -0400

> I am new here and in the process of reading the papers I have found and learining the "rules" for the whole IETF deal. let me start by saying a few things about my background as it relates to my vi…

Hi Danny and welcome to the ASRG.

> 1)  make the sender "Pay Postage" will get us further than trying to filter the junk / spam.

There are scaling and other implementation problems with e-postage which 
must be solved before its implemented. See the following:

http://www.taugh.com/epostage.pdf
http://www.templetons.com/brad/spam/estamps.html#bad

> 3)  common practice, the law and the SMTP software need to make "accountability" a requirement not an option.

Installed base makes it very hard PLUS anonimity is an issue. See the 
following document:

http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt

> 4)  as has been stated elsewhere: classifing "SPAM" via program is difficult and requires constant adaptation.

Correct.

> 7)  today the recipent bears the cost of the unwanted traffic.

This is outlined in our charter as well.

> the fee can be small for each message.

 From the technical considerations document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt):

"    The idea of replacing SMTP is appealing because it
      permits thinking in terms of creating an infrastructure
      that has accountability and restrictions built in.
      Unfortunately an installed base the size of the
      Internet is not likely to make such a change anytime
      soon.  It seems far more likely that successful spam
      control mechanisms will be introduced as increments to
      the existing Internet mail service.

      Moreover, the feature of SMTP that is most responsible
      for spam is the ability to receive mail from strangers.
      Without this feature, there would be no flood of spam,
      but many of the most valuable Internet commercial and
      individual activities would also be impossible.
      Replacing SMTP with a protocol that allows strangers to
      send each other mail would not stop spam any more than
      SMTP-AUTH stopped spam, contrary to insistent claims to
      the contrary, before SMTP-AUTH became widely available
      and used.
"

and:

"    A key construct to examination of adoption and benefit
      is "core-vs-edge".  Generally, adoption at the edge of
      a system is easier and quicker than adoption in the
      core. If a mechanism affects the core (infrastructure)
      then it usually must be adopted by most or all of the
      infrastructure before it provides meaningful utility.
      In something the scale of the Internet, it can take
      decades to reach that level of adoption, if it ever
      does.

      Remember that the Internet comprises a massive number
      of independent administrations, each with their own
      politics and funding. What is important and feasible to
      one might be neither to another. If the latter
      administration is in the handling path for a message,
      then it will not have implemented the necessary control
      mechanism. Worse, it well might not be possible to
      change this.  For example a proposal that requires a
      brand new mail service is not likely to gain much
      traction.

      By contrast, some "edge" mechanisms provide utility to
      the first one, two or three adopters who interact with
      each other. No one else is needed for the adopters to
      gain some benefit. Each additional adopter makes the
      total system incrementally more useful. For example a
      filter can be useful to the first recipient to adopt
      it. A consent mechanism can be useful to the first two
      or three adopters, depending upon the design of the
      mechanism.
"

> 4) it would shift the legal stance on dealing with the problem as follows: it is difficult to create a solid legal definition of "SPAM" and due to the inherent subjective nature of any definition l…

E-postage has problems which must be solved first.

> it would force the hidden relays, the forged headers and other garbage to stop or slow to a crawl.

There are other mechnanisms such as RMX, etc. which allow authentication 
for servers as opposed to individual clients, and tend to stop relays 
and hijacked home computers. There is a currently a small sub-group 
working on reconciling several RMX proposals, but than again 
implementation will be difficult.

---

From: Andreas Saurwein <[email-masked]>
Date: Tue, 21 Oct 2003 12:02:33 -0200

>I have a lot to say and I hope it's worth hearing....

Welcome and go ahead :)

>3)  common practice, the law and the SMTP software need to make 
>"accountability" a requirement not an option.
>4)  as has been stated elsewhere: classifing "SPAM" via program is 
>difficult and requires constant adaptation.
>5)  the problem is as much , perhaps mostly an issue of total traffic 
>volume and the burden it puts on the whole community.

Personally I dont agree with 1, 5 and 7.
1) that changes the whole concept of internet mail.
5) mail traffic may be heavy but that is not really the concern of most 
network operators given the current traffic produced by P2P and "multi-media"
7) that actually makes up only a very small part of the cost, when you 
define recipient as "end-user" instead of "the organization to which the 
recipient belongs"

>4) it would shift the legal stance on dealing with the problem as follows: 
>it is difficult to create a solid legal definition of "SPAM" and due to 
>the inherent subjective nature of any definition leaves room for argument. 
>also if we try to "Block SPAM" or "Outlaw SPAM" then they can claim unfair 
>restraint , bias , censorship and so on. if we move to a business 
>accounting basis then there can be no argument that the process is unfair. 
>you have to "Pay your bills" if you want to use the network. and if you do 
>not pay your bills then you can't keep ending me traffic. and thats not a 
>"Blacklist" it's not "Censorship" and so on.... it's basic legal business 
>practice.

How does your approach deal with hijacked computers and the like? Make the 
computer owner pay? (Probably not even a bad idea, people would start to 
care what is running on their computers.)

Cheers
Andreas

---

From: "Denny Figuerres" <[email-masked]>
Date: Tue, 21 Oct 2003 14:40:41 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andreas Saurwein
> Sent: Tuesday, October 21, 2003 10:03 AM
> To: [email-masked]
> Subject: Re: [Asrg] 0. General
> 
> 

.....

Well I am thinking of a few things... I just got a reply that mentioned
"RMX" which sounds close to what I am thinking.

Perhaps a DNS type of approach that requires an SMTP server to be
"Verified"
And if you are a customer of an ISP other other service operator then
you should be using their SMTP server to reach other SMTP servers.
(yes that's a relay, but a closed relay supervised by the ISP -- the
network operator keeping the chain of accountablity in tact)

Some of this can be done by the operators blocking outbound SMTP ....
Kinda draconian but it would cut back on "Rouge Servers"

And if you want to run a server you shuld not have a fit over having to
tell your ISP and agree that you will be accountable for any damges you
cause.

In many ways I'd take the SSL model, I will exchange trusted data only
with a partner I can verify as "reputable".

So if some worm go in and hijacked some Windows / Linux PC and started
to try and blast out spam it would fail unless they could hack the fire
wall and the public key / trust database.
If done right the PC user would get a call from the local ISP telling
them to fix the computer ASAP and take it off the net.

---

From: Walter Dnes <[email-masked]>
Date: Tue, 21 Oct 2003 22:39:23 -0400

On Tue, Oct 21, 2003 at 09:43:39AM -0400, denny  wrote

> I am not generaly in favor of "more goverment" but belive that some
> laws will be needed to help controll spam.

  [...major snippage...]

> the real chalenge with this approach would be getting the right kinds
> of laws / regulations in place to allow a victim to make thier case.
> but that issue is there now... but due to the lack of accountability
> and the ease of email forgery it places a heavy burden on the victim.
>  
> well what do you think?

  There are *ALREADY* enough laws in place that *IF THEY WERE ENFORCED*
would end the spam problems we now face.  There are already laws against
  - hijacking computers
  - selling controlled drugs without a doctor's prescription (and
    prescribing controlled drugs without a physical visit from the
    patient)
  - pump-n-dump stock scams
  - Nigerian 419 scams
  - theft of cable-TV services
  - selling pirated computer programs
  - forged headers (in some jurisdictions only)

etc, etc, etc.  Police forces usually won't get involved unless actual
damages exceed $50,000.  Passing additional laws simply means that even
more laws won't get enforced.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 22 Oct 2003 05:51:17 +0200

> "RMX" which sounds close to what I am thinking.

    http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt
    http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-04.txt
    http://www.ietf.org/internet-drafts/draft-brand-drip-01.txt
    http://www.irtf.org/asrg/draft-vixie-repudiating-mail-from.txt
    http://spf.pobox.com/draft-mengwong-spf-01.txt 
    http://nospam.couchpotato.net/

Choose one. They all break all sorts of existing Internet mail structure
like oversized DNS packets or totally breaking forwards.

> you should be using their SMTP server to reach other SMTP servers.

And that does help what?
I have cleaned out the mailqueue of one of our mailservers on Satuerday
of > 4000 messages that still stuck after 2 hours response time and
where injected via a hacked Win2000 server at a customers authentifying
via SMTP AUTH.

> network operator keeping the chain of accountablity in tact)

Accountability for what?
They did not do it and being to fscking braindead to maintain a computer
connected to the Internet is not a criminal act that will get you your
head chopped off. It's a "unlucky thing" that happens to everyone. So no
judge will prosecute you for that.
The customer pays the traffic and if we're really lucky he'll pay the 1.5
hours techsupport. If we have bad luck he'll terminate contract because
I shut him off for the weekend and we presume to have him pay for
something e did not do.

> tell your ISP and agree that you will be accountable for any damges you

You have two major problems:
could/should and internationalization.
The Internet is a commercial net for quite some time and the "grey guys"
make their money with the fact that they are less restrictive than the
"white guys". As long as there are enough "grey guys" you can't get rid
of the easily because maybe some big companies are their customers.
So strongly being a "good guy" mainly brings bankruptcy these days, as
you lose customers. So this could/should is something we are all aware
but nobody can enforce it.
This is true even more as the Internet is a worldwide net and lots of
countries have lots of different legislation.

> with a partner I can verify as "reputable".

Please define how the transition period will work.
Please define who to enforce the SSL model.

> them to fix the computer ASAP and take it off the net.

Big deal. Our bandwidth/port scan monitors show this already and we call
the customers. How long can you have some support personnel on phone
to help a luser that can just find the PowerOn button and has no ideas
of antivirus and that pays 10 USD/month. How much of them (support and
lusers) can you afford?

I was idealistic 20 years ago, and even 5 years ago, but it looks like
reality has me in its claws now ...

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Richard Rognlie <[email-masked]>
Date: Wed, 22 Oct 2003 00:09:43 -0400

On Wed, Oct 22, 2003 at 05:51:17AM +0200, Markus Stumpf wrote:
>     http://www.ietf.org/internet-drafts/draft-brand-drip-02.txt

As one of the authors of DRIP, I protest.  it does not break anything.
it simply allows a site to check the validity of a connection coming from
IP x.y.z.t and claiming to be mail.gamerz.net on the EHLO line

It's not much of an anti-spam widget, but it is very useful for the
malware virii that are wreaking such havoc on the net these days.

e.g.   as the owner of gamerz.net, I can specify in simple DNS A records
that play.gamerz.net MUST be coming from 66.92.144.25

    *.ipv4.relays._email_.play.gamerz.net.              IN A 0.0.0.0
    66_92_144_25.ipv4.relays._email_.play.gamerz.net.   IN A 66.92.144.25

in addition, I can prevent any other use of anything ending in 
gamerz.net with the setting up of

    *.ipv4.relays._email_.gamerz.net.              IN A 0.0.0.0

So now, a site using an MTA that is DRIP aware, gets HELO command
claiming to be play.gamerz.net... if the IP is NOT 66.92.144.25,
you can reject the msg (or use that info as part of your scoring
or whatever).

If you get a connection from foobar.gamerz.net, you'll lookup
x_y_z_t.ipv4.relays._email_.foobar.gamerz.net and get NXDOMAIN
one thing the draft recommends is that you strip the leading
domain part and try again (in an effort to see if the domain
supports DRIP at all)

This time you'd look for x_y_z_t.ipv4.relays._email_.gamerz.net 
and get back 0.0.0.0.  This tells you that gamerz.net support DRIP
and that the HELO argument as stated is bogus.

And remember, I'm not specifying that mail from [email-masked]
has to come from "the" gamerz.net RMX... just taht the HELO line
claiming to be play.gamerz.net (my MTA) must be the specified
IP (or one of the specified IPs).

So, we don't break forwarding at all.  And I've been having quite 
good luck with blocking all kinds of mail directed at my domain
claiming a HELO line of my domain (when the IPs in question have
absolutely nothing to do with me).

The miltered version of DRIP is available at

    ftp://ftp.gamerz.net/pub/dripmilter.pl

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
 /  \__/ | 
 \__/    | CAUTION: may contain Mature material......but I doubt it.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 22 Oct 2003 01:11:59 -0400

>of the easily because maybe some big companies are their customers.

Ran into a recent example of this.  There's a guy sitting on Level3's 
network (name and address available upon request :-).  He does bulk 
mail delivery for porn sites.  I actually don't consider him a 
particularly bad spammer.  I suspect they just give him the list and 
he delivers.  He is, however, a very bad coder.  When faced with the 
fact that some servers return 5xx errors on account full, he decided 
to ignore all 5xx errors.  That's right.  He just completely ignores 
them.  But the real killer is that if you give him a 5xx at connect 
time and then close the connection, his software thinks it got a 
network error and immediately retries the connection... a lot... 
frequently.  I was getting slammed with half a million connection 
attempts in the period of a few hours.  Repeated every 12 to 24 
hours.  Despite the fact that we'd immediately close them, it was 
saturating a 768kbs DSL line.

The only way I managed to get Level3's attention was that I didn't 
mention the word spam.  I billed it as what it in essence was... a 
DoS attack.  It took a week to get them to respond.

They claim to be talking to him about the problem.  Then again, he 
claimed to me he would stop sending my domain email and he didn't, so 
who knows.  I seriously doubt they'll throw the guy off their 
network.  He's paying for some serious bandwidth.  He's got dozens of 
machines delivering email, and he's been on the SpamHaus list for at 
least a year.

Welcome to the gray market of email hosting.  In an ideal world you'd 
tell the guy to get off the network until he cleaned up his act.  But 
it's not an ideal world.

Of course, on the hardcore spammer side, we have things that are 
really serious DoS attacks.  I saw mail this evening from a site 
admin who got hit with a dictionary attack.  12-15,000 messages per 
hour over a 12 hour period, coming from over 61,000 different IP 
addresses.  And at the end of the 12 hours, the volume suddenly 
doubled to 30,000 messages per hour.  After trying to deal with that 
for a while  the domain owner gave up and removed the A record for 
the domain that was being attacked.  Fortunately that was an option. 
Ironically the domain being attacked had no valid email addresses, 
although the server hosted other domains that did.  The subject of 
the spam?  Ads for anti-spam software.

61,000 machines engaged in a coordinated spam attack on a single machine.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 22 Oct 2003 19:42:22 +0200

> absolutely nothing to do with me).

I am sorry and I'd like to apologize. I was too general.
I had a quick glance over the abstracts to refresh memory and
you don't mention HELO in the abstract ;-)

Sorry,

	\Maex

---

From: Brad Knowles <[email-masked]>
Date: Thu, 23 Oct 2003 01:49:45 +0700

At 1:11 AM -0400 2003/10/22, Kee Hinckley wrote:

>                                                   When faced with the

	Simple to solve.  Tar-pit him.  Make sure that you always take 
the full five minutes to respond to each command, and slow him down 
to the full limits of the protocol.  Also make sure that you don't 
give him a 5xx response on connect, wait for the "RCPT TO" before you 
do that, to help slow him down even more.  If he tries to connect to 
you multiple times in parallel, tar-pit all connections from him.

	No matter what he does, he'll only be able to talk to you very 
slowly, and he'll probably remove you from his lists because he 
doesn't like having his server tied up.

	Postfix does this easily.

>  61,000 machines engaged in a coordinated spam attack on a single machine.

	That's a much tougher problem to solve.  Greylisting plus 
tar-pitting (by sender domain) would be a start, but you'd still have 
very large numbers of simultaneous connection attempts to deal with.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Brad Knowles <[email-masked]>
Date: Thu, 23 Oct 2003 01:44:25 +0700

>  IP (or one of the specified IPs).

	Trivially easy to by-pass.  Just claim to be 127.0.0.1, or 
10.0.0.1, or some other IP address.  Or maybe your "real" external IP 
address (assuming you have some reliable way of determining that, 
even though you might be behind a NAT or whatever).

	There's a reason why the RFC says that you don't validate the 
hostname claimed in HELO/EHLO.  It takes too much time, and is too 
easy to by-pass.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 22 Oct 2003 21:26:34 +0200

> you multiple times in parallel, tar-pit all connections from him.

We have some busy mailservers running a connenction limit of 250 parallel
connections at all.
While I have noticed I have no problems with 50 connections in tarpit from
different hosts (some from the same) you can easily run in a homegrown
DoS if the number of concurrent tarpitted connections becomes too high.

I have written a wrapper (which is far from being in a state for a
release) that connects to a (central) server and sends "CONNECT <ip>".
The server has rules like
    - connections per timeframe  (both freely configurable)
    - max concurrent connections
it checks the IP against the ruleset for that IP and either sends "OK"
or "REJECT <reason>". The wrapper forks()s the smtpd in case of an "OK"
and waits for termination to send a "DISCONNECT <ip>" to the server.
In case of a "REJECT" it sends a "4xy reason" and drops the connection.
The client/server architecture makes it possible to group mailservers
to a cluster and enforce the policies for the cluster.

For a quick and dirty solution to overzealous senders I find it useful
to (in Unix environments) add a route like
    route add <attacker_ip> 127.0.0.1
One doesn't have a firewall kernel on each machine and that way one
doesn't have to mess with the firewall config at all.

	\Maex

---

From: David Maxwell <[email-masked]>
Date: Wed, 22 Oct 2003 16:07:26 -0400

> even though you might be behind a NAT or whatever).

So, connections from nameless IPs probably deserve to be weighted as
'spam-likely' in your consent decision. Perhaps even 'spam, guaranteed'.

> hostname claimed in HELO/EHLO.  It takes too much time, and is too 

That design decision was made before the current situation came into
being. Now, my spamassassin installation spends far more time doing
content inspection on spam messages than the 'too much time' it would
take to validate the provided hostname.

The network environment has changed, the assumptions about overhead need
to be re-evaluated.

-- 
David Maxwell, [email-masked][email-masked]

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 22 Oct 2003 16:32:22 -0400

At 1:49 AM +0700 10/23/03, Brad Knowles wrote:
>	Simple to solve.  Tar-pit him.  Make sure that you always 
>take the full five minutes to respond to each command, and slow him 
>down to the full limits of the protocol.  Also make sure that you 
>don't give him a 5xx response on connect, wait for the "RCPT TO" 
>before you do that, to help slow him down even more.  If he tries to 
>connect to you multiple times in parallel, tar-pit all connections 
>from him.

Then you enter into an interesting resource battle.  Who has more 
resources that they can afford to keep around doing nothing?  That's 
a dangerous game to play.  But in any case, my mail server doesn't 
support it.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

---

From: David Maxwell <[email-masked]>
Date: Thu, 23 Oct 2003 13:18:14 -0400

> At 4:07 PM -0400 2003/10/22, David Maxwell wrote:
> 	That's fine, but keep in mind that this has collateral damage 
> 	consequences.

It's my choice to accept those consequences - it's _my_ consent
decision.

> 	Use DRIP (or DRIP-like techniques) as a whitelist, and that can 
> be abused, too -- Plenty of spammers are perfectly happy to 
> authenticate in whatever way you want, and will make sure that their 
> reverse DNS fully matches, etc... just to get their mail through. 

That's not an abuse of DRIP. DRIP provides a layer upon which I can add
a white/grey/blacklist by domain. Without DRIP (or RMX, etc), I cannot
whitelist by domain, since spammers can forge spam claiming to be from
one of the domains I whitelist.

> Then there are the virus/spammers who use victim machines distributed 
> around the world, most of whom probably are properly configured to 
> use outbound mail relays that are likewise correctly configured.

Many of the viruses forge email source. If they didn't, I could easily
contact the sender and tell them to cleanup their machine.

> 	Then your spamassassin configuration is not correctly configured. 
> You shouldn't be using it that way unless you can make sure that you 
> can conform to the same kinds of situations and response times as 
> were anticipated when the RFC was written.

I'm not rejecting the mails in the SMTP phase - so the RFC specs are not
relevant - however, the fact that I cannot implement
white/grey/blacklists leaves content inspection as the only method to
identify spam. That 'guesswork' takes a lot of CPU time, and gives me a
very non-deterministic answer anyway.

> 	Re-writing the RFC is a different matter, something which I 
> believe we are also participating in.  However, until the RFC is 
> re-written and gotten to at least the "Proposed Standard" stage, you 
> should not be knowingly in violation of it.

I'm not violating it - I'm discussing changing it.

						David

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 23 Oct 2003 13:40:33 -0400

Brad Knowles <[email-masked]> wrote:
> the HELO line

  The IP in EHLO not matching the source IP of the SMTP session is a
strong indication of spam.  The IP in EHLO being the IP of the
recipient MTA is an even stronger indication of spam.

  And the use of an IP in EHLO is correlated with spam, at least in
my experience, and for the people I've talked to.

> hostname claimed in HELO/EHLO.  It takes too much time, and is too 

  Not quite.  RFC 2821, Section 4.l.4, paragraph 6 discusses the
correlation of host name in EHLO to IP, and says that a lack of
correlation doesn't mean anything.

  For the purposes of RMX-style solutions, that correlation is never
checked, and is therefore never used to make a decision about the SMTP
transaction.  That section of RFC 2821 is therefore not violated by
RMX-style solutions.

  Alan DeKok.

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 23 Oct 2003 15:14:43 -0400

At 7:23 PM +0700 10/23/03, Brad Knowles wrote:
>>                             But in any case, my mail server doesn't
>>  support it.
>
>	I'm sorry to hear that.  ;-(

"My" is ambiguous there.  The one I use for internal use 
(CommuniGate) doesn't.  Messagefire's anti-spam proxy server supports 
it, but we are still experimenting to find the right balance.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

---

From: David Maxwell <[email-masked]>
Date: Mon, 27 Oct 2003 17:27:06 -0500

> At 1:18 PM -0400 2003/10/23, David Maxwell wrote:
> 
> 	That's fine -- up until the time where you tell other people that 
> they should be doing the same thing.

No, I'm suggesting that other people should be able to make that choice.

You seem to be arguing that recipients shouldn't be allowed to refuse to
consent to messages frmo anonymous senders.

Also, I never saw an answer to my question - "Are your activists sending
to recipients to whom they are known, or are they sending to random
recipients?"

> 	If you want to insert lit explosive devices into your body, 
> that's one thing.  But when you start encouraging other people to do 
> the same, that's totally different.

I think that if I were a bit smarter, I would accept that as close
enough to a Godwin's law offense that I would cancel this message.

> 	They could do that anyway.  Remember the previous discussion of 
> DNS cache poisoning?  Even if your servers are immune to cache 
> poisoning, what are the odds that the advertised nameservers of all 
> your whitelist domains are also secure?

A DNS server being compromisable is an implementation flaw, not an
infrastructural one. It's also more difficult than forging an email
address is today, thereby raising the bar for spammers.

> 	Just forge the username.  Unless you contact the system 
> administrator at that ISP and get them to match the username against 
> the IP address at that particular time, you'd never know (that's 
> assuming they have accurate logs for that time, or that they're 
> willing to do this for you since you're not a paying customer).  Or, 
> forge the username within any of the other domains which are hosted 
> by those machines.

The later would be difficult for a virus to 'know'. The former would
still leave me with a good guess as to whose address book I might be in
- and at the very least, lets me contact the ISP who I know can do
something about it, with the information they need (source IP and time
of connection) so that they can inform the virus-infectee.

> 	Of course, another issue with open caching/recursive servers is 
> that you can get anyone in the world to effectively host your domain 
> for you, and combined with wildcards they could appear to be hosts 
> for virtually all domains on the Internet.

I don't understand your example.

> 	You're going to be forced to do that anyway.  You're just going 
> to force the spammers to get that bit more crafty to by-pass your 
> so-called protection mechanisms.

Right, it's raising the bar, and it's also enabling other tools.

As an example:

(All the following is with the exception of point-to-point user
verification, such as PGP signed messages.)

Without (verified) domain names, you can't have verified email
addresses.

Without (verified) email addresses, you can't have reliable user based
whitelists.

I believe that for many users, a short whitelist would be a highly
practical solution to the spam problem. It wouldn't be for myself,
personally - but for my mother, and my aunts...

Any white or black listing proposal which doesn't address the need for
authentication of the list compared data may be worked around.

							David

---

From: Brad Knowles <[email-masked]>
Date: Wed, 29 Oct 2003 13:33:08 +0100

>  address is today, thereby raising the bar for spammers.

	No more difficult than writing a virus to compromise millions of 
PCs world-wide and make them available to you as open proxy servers.

>  The later would be difficult for a virus to 'know'.

	Easy to find out, especially if the site has implemented DRIP and 
RMX type solutions.

>  I don't understand your example.

	Then you don't understand enough about DNS security issues to be 
able to pass judgement on these matters.

>  Right, it's raising the bar, and it's also enabling other tools.

	It's not raising the bar.  It's moving the bar, but merely 
horizontally.  You're not improving the situation.  Moreover, because 
you're moving the bar into territory where many admins have much less 
knowledge and experience, in many ways you're making the situation 
worse than it was before.

>  Without (verified) domain names, you can't have verified email

	Not true.

>  Without (verified) email addresses, you can't have reliable user based

	Not true.

>  personally - but for my mother, and my aunts...

	It wouldn't be useful for anyone who doesn't understand the 
details of the technical implementation, and who doesn't know what 
the potential failure modes are and what to do about them.

	In other words, the people it would be least useful for would be 
your mother or your aunts.

>  authentication of the list compared data may be worked around.

	Anything which causes the trust boundary to be crossed can (and 
will) be gamed.  This is where joe-jobs come from.  Authentication 
methods won't change this fact, unless they are based on a secure 
protocol which uses strong crypto at the core -- which means that 
they cannot possibly be implemented through the DNS.

---

From: David Maxwell <[email-masked]>
Date: Fri, 31 Oct 2003 14:46:40 -0500

> PCs world-wide and make them available to you as open proxy servers.

You didn't respond to my comment. I said A > B. You said B !> C.

> able to pass judgement on these matters.

No, you simply weren't clear enough about your example. I can't use the
argument "it isn't" to accuse you of naivety in matters of foreign
currency exchange, and you can't conclude anything about my
understanding of DNS security issues with a comment like the above.

> worse than it was before.

Saying that 'things will be different, and people will have to adapt' is
not a reason by itself to not make a change, otherwise no changes could
ever be made. It raising the bar - it will allow detection/rejection of
a particular class of abuse - including the forgeries from well known
sites, such as paypal and ebay.

For the below, you clipped a critical line of context from my reply, so

> > Without (verified) domain names, you can't have verified email

Care to back that up with an explaination? The only one I see is the
cryptographic solution (which I mentioned as an exception, though you
clipped it). Cryptographic solutions have keying issues, which gives
solutions not dependent on crypto certain advantages, particularly in
implementation.

> > Without (verified) email addresses, you can't have reliable user based

Care to back that up with an explaination? Simply negating my statements
does not contribute to the discussion.

> the potential failure modes are and what to do about them.

What? Please explain how my mother would need to understand the
technical implementation in order to be able to say "I accept mail from
[email-masked], and [email-masked], period."

> they cannot possibly be implemented through the DNS.

You're talking in absolutes, but I think there's a range of gray area
here.

In my view, joe-jobs come from the protocol accepting 'MAIL FROM:' (or
HELO, or the message header) on faith, and performing no checks on it
whatsoever. Sure, adding checks which aren't cryptographically strong
means that people will try to work around the checks, but it would still
be better than no checks.

You seem to be arguing that we shouldn't do _anything_ if it isn't
perfect. Since no solution will ever be perfect by everyone's
definition, they we will never to anything.

Come to think of it, I've never seen you mention what spam solutions you
think are beneficial - only interfere with discussions of solutions you
don't like. What solutions do you like?

							David