Subject: [Asrg] 3. Requirements - Non Spam must go through

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 07 Jul 2003 17:23:36 -0400

Just ran across this quote from the John Gilmore of the EFF 
(http://www.politechbot.com/p-04927.html):

----snip----
After years of divisive discussions, a very similar pledge/oath/policy was 
what EFF was able to come to agreement on:

"Any measure for stopping spam must ensure that all non-spam messages reach 
their intended recipients."

Perhaps none of us has yet come up with a silver bullet to solve the 
problem of spam -- but it IS within our power to solve the problem of
overzealous anti-spam measures.
----snip----

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

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 07 Jul 2003 13:34:41 -0400

> their intended recipients."

  I disagree, out of principle.

  People should have a choice.  We should be implementing systems
which enforce choice (e.g. consent), rather than absolutes.

  Some people may see that rejecting some small percentage of "valid"
mail gets rid of large amounts of spam.  That is, in many cases, false
positives are inversely correlated with false negatives.  The more you
fight to lower the false positives, the more you may increase the
false negatives.

  I would rather say:

  "Any spam fighting system must be designed so as to allow the
desires of the recipients to be implemented.  No spam fighting system
should be designed so as to throw away any non-spam email as part of
its measures, unless the recipient of that email specifically
instructs the system to do so."

  By focussing on the desires of the recipient, rather than on
absolute statements, we give ourselves more flexibility in designing
systems.

  e.g.  An ISP hosts 1000 spammers, and one "real" user.  Everyone in
the world tells that ISP (or his upstream provider) that he's sending
too much spam, and they don't want to see *any* SMTP traffic from him.
The one "real" user is screwed, but only because everyone in the world
individually decides they don't want his mail.

  In John Gilmore's philosophy, enforcing the wishes of everyone in
the world (but one) would be forbidden, because one person could no
longer send mail.  Even worse, that philosophy has mandated that John
gets to make consent statements about the email I receive (I must
consent to ALL non-spam email), but I do not get to make consent
statements about my own email (I accept only PGP signed messages).

  I don't find that acceptable.  I would rather enforce consent than
embrace philosophical ideals.  Any anti-spam system must be designed
to enforce consent, and not ideals.

  Alan DeKok.

---

From: [email-masked] (Justin Mason)
Date: Mon, 07 Jul 2003 15:23:53 -0700

> to enforce consent, and not ideals.

Agreed.   This is a philosophical ideal; the real world does not operate
in a boolean, white-and-black mode; there are always grey areas and
compromises.

--j.

---

From: "Elric Pedder" <[email-masked]>
Date: Mon, 7 Jul 2003 19:23:45 -0400

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yakov Shafranovich
> Sent: July 7, 2003 17:24
> To: [email-masked]
> Subject: [Asrg] 3. Requirements - Non Spam must go through

> overzealous anti-spam measures.

I don't believe you can stop false positives -- if only because
people will have widely varying opinions on what SPAM (to them)
is.  It is, however, very dangerous to allow false positives
because if anything the perceived "reliability" of the Internet
becomes compromised.

I would recommend 

"Any measure for stopping spam must ensure that all messages
either reach the intended recipient, or are returned to the
sender, or the sender notified."
 
This is the basic principle of SMTP but many anti-spam solutions
simply discard messages or file them for the user to view later.
As Kee mentioned awhile back, this often doesn't happen.

SMTP certainly supports this architecture with minimal additional
bandwidth and anti-spam solutions could be integrated at the
SMTP level, or send notifications independently.

-- 
Elric Pedder
Mailtraq Development (www.mailtraq.com)

---

From: Barry Shein <[email-masked]>
Date: Mon, 7 Jul 2003 19:40:28 -0400

And a chicken in every pot!

    -b

---

From: Barry Shein <[email-masked]>
Date: Mon, 7 Jul 2003 20:09:07 -0400

> sender, or the sender notified."

Yeah, I'm sure Ralsky et al will thank everyone for the help.

This really only makes sense when we again think of spam like an
individual sending a msg which one may or may not want.

Howsabout when it's 200+ hijacked servers banging at you full-speed
with the same spam? That's the reality.

Is the proposal to send the hundreds of msgs per minute each a proper
handwritten no thank you note?

It's amazing to me how many different people (specifically the EFF in
this case) will step up to the plate with a shallow, harebrained,
mental model of the spam problem and begin offering authoritative
advice.

-- 
        -Barry Shein

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 07 Jul 2003 20:29:44 -0400

At 08:09 PM 7/7/2003 -0400, you wrote:

>....

Therefore just to clarify your statement, are you suggesting these spam 
emails should not be rejected but rather thrown away silently? So within 
the consent model, if you specified that you do not wish to receive email 
from dial-up IP addresses, any email coming from those addresses should be 
thrown away and not even reported or tracked somewhere?

Yakov

---

From: "Elric Pedder" <[email-masked]>
Date: Mon, 7 Jul 2003 21:50:50 -0400

> Behalf Of Barry Shein
> Sent: July 7, 2003 20:09
> To: Elric Pedder
> Cc: [email-masked]
> Subject: RE: [Asrg] 3. Requirements - Non Spam must go through

> individual sending a msg which one may or may not want.

I agree, but unfortunately the anti-spam system cannot distinguish 
those cases.  
 
> with the same spam? That's the reality.

Ideally the notification would be issued by the servers themselves
as a result of a 5xx response code during the SMTP transaction.
This may help the 200+ hijacked servers' administrators notice the
problem.

It may be a costly process, but you are only returning one 
notification for each message.  

I don't think we can expect users to monitor their SPAM traps,
and even if they did we would not have achieved much more than
convenient folder management.  Unwanted mail may be a nuisance,
but missing wanted mail is unacceptable.  The result would be
that users lose faith in e-mail itself, which I believe is too
costly an outcome.  What will we have achieved if e-mail 
becomes perceived as an unreliable medium and users have to 
phone the recipient to see if the message has been deleted.
 
> handwritten no thank you note?

I think a DSN would be sufficient, but if handwritten notes are the
policy at your MTA then that's fine too.

---

From: Pete McNeil <[email-masked]>
Date: Tue, 08 Jul 2003 01:33:31 -0400

>notification for each message.

If the policy were adaptive, then a SENDER who continues to ignore 
rejections after some number of notices could be seen as abusive under that 
policy and the rejection method could be escalated. Eventually you would 
expect the system upon experiencing abuse (either by design or by error) to 
refuse connections from the SENDER for a period of time... This might make 
a good "safety valve".

In cases where policies are shared in a COT (Circle Of Trust), other 
systems might adopt this policy and effectively disconnect misbehaving 
systems until the abuse is ceased. A collaboration between systems with a 
similar policy would allow for the "count of abuse" to be measured between 
all systems in the COT such that any "attacker" would find the "noise 
floor" in the detection system quite low... That is, they would not be able 
to counter the disconnection mechanism by simply dispersing or pacing their 
"attack" since multiple systems would be employed to measure the abuse.

A system like this would not be a direct element of a consent policy as it 
is being defined here, but the specifications for a consent policy should 
allow for mechanisms like this to become part of the decision model.

_M

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 08 Jul 2003 09:36:44 +0100

> overzealous anti-spam measures.

Unless my "anti-spam" system is perfect, there must be no silent
false-positives for this to be true. Either a sender whose message is not
delivered because of the action of some "anti-spam" system must be able to
know this. And be able to find out what they can do about it.
(This is a very strong argument for "spam" rejection to happen during the
SMTP - or whatever - transaction; we don't want to be sending DSN or
challenges to forged senders.)
Or, the "receiver" must be be informed that the message hasn't been
delivered, and be able to do something about it (but this imposes a cost on
the receiver).

--

---

From: "C. Wegrzyn" <[email-masked]>
Date: Tue, 08 Jul 2003 04:57:17 -0400

Let me tell you what I do with SPAM. I don't think this is all the 
problematic.

In either C/R mode or Filter mode (I use Cyrus with Sieve to support 
this) I move messages that I expect into my Inbox. The first line of 
defense in my system is the C/R system. When I join a list or want email 
from someone I setup the C/R system to bypass it's work by adding the 
appropriate email addresses (and where I expect to see them - To, CC, 
etc). If the address is in the list, no C/R is required. If the address 
isn't in any list, a challenge is issued. If the response is given, it 
moves into the inbox. If no response is given within a day the message 
is put in to the Junk folder. If a response is given it is moved into 
the inbox.

When I log in to my account the spam filters run (I use the Mozilla 
email reader that supports Bayesan filtering). When the filter catches 
it goes into the Junk folder. Everything else stays in the Inbox. What 
has this done: I normally reject 99% or better of spam; I get 4-5 in my 
inbox. I spend a few minutes to figure out what happened - how it got 
through - and mostly adjust my filters. Yes, occassionally I do find 
valid messages in the Junk folder, and for those I also train the filter 
to not pick them up.

Now it isn't a perfect system - it won't catch all spam and mark it as 
such. It will tag certain valid messages as spam (for instance the 
filters originally put all messages from ASRG that had SPAM in the 
hearder into the Junk folder! lol). But with a little work it does get 
rid of the problem, as far as I am concerned.

Chuck Wegrzyn

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 08 Jul 2003 11:32:44 +0100

> rid of the problem, as far as I am concerned.

I'm sure it does. This is a system under the total control of a
knowlegeable "receiver". The problem is to deliver solutions (or
frameworks for solutions) that will work for any receiver, while 
giving acceptable "reliability".

--

---

From: Andrew Akehurst <[email-masked]>
Date: Tue, 08 Jul 2003 15:59:27 +0100 (BST)

> > instructs the system to do so."

Perhaps the EFF's philosophy has something to do with the ideal of e-mail as 
freedom of speech.

In this case I'd suggest the same common-sense philosophy as for regular 
speech. You (or your company) have the right to say whatever you like. I have 
the right to ignore you, should I choose to do so.

From the point of view of the people wanting me to hear them, well that's 
tough. If I don't want to hear them, they have no right to force me to do so. 
We hear a lot of talk about rights these days and very little about the 
responsibilities that go hand in hand with rights.

You may well feel you have a right to send e-mail to me but if you use that 
right irresponsibly, then I have the right to ignore you in future.

From a common-sense point of view, if I stick my fingers in my ears when I see 
a particular (unwanted) person approach my desk, I might well miss some useful 
or even important information - maybe a colleague asking if I'd like a cup of 
coffee, for example, or in the extreme case somebody telling me there's a fire 
and that I need to leave the building.

It's my choice to block my ears and any reasonable person could understand that 
they might miss out on something if they do the same. 

... 8< ... 

> Agreed.   This is a philosophical ideal; the real world does not
> operate in a boolean, white-and-black mode; there are always grey areas
> and compromises.

Indeed. There has to be a recognition that everyone in the delivery chain of e-
mail has rights and responsibilities. Whatever solution is devised will 
inevitably involve compromise.

This doesn't mean rights aren't important, but that simply that a balance must 
be struck.

Andrew

---

From: "Madscientist" <[email-masked]>
Date: Tue, 8 Jul 2003 11:29:33 -0400

>-----Original Message-----
>Behalf Of Jon Kyme

<snip>

>Unless my "anti-spam" system is perfect, there must be no 
>silent false-positives for this to be true. Either a sender 
>whose message is not delivered because of the action of some 
>"anti-spam" system must be able to know this. And be able to 
>find out what they can do about it. (This is a very strong 
>argument for "spam" rejection to happen during the SMTP - or 
>whatever - transaction; we don't want to be sending DSN or 
>challenges to forged senders.) Or, the "receiver" must be be 
>informed that the message hasn't been delivered, and be able 
>to do something about it (but this imposes a cost on the receiver).

In general I agree with you, but I will play devil's advocate here.
Notifying the receiver that a message was not delivered is analogous to
moving messages to a "spam-review" folder. Many bulk mailers have argued
that this amounts in practice to deleting and/or blocking their messages
because the receiver never reviews this folder - and by analogy might
simply ignore any notifications (presumably due to the cost).

Since the "human component" will tend to be wildy inconsistent from a
system-wide perspective, we must assume that some amount of "silent
loss" will always occurr in any system we devise... for example, even if
the message is passed through to the end user without any modification
or redirection, the end user might simply delete it out of hand and
nobody can prevent that. Give that user sufficient technology and they
will likely use that technology to delete these messages automatically.

It could be argued that this action is an exercise of that user's
consent and so that dynamic is part of what we must consider in the
design of a consent based system.

--- I take off my devil's hat ---

It is apparent to me that we can develop a system that forces that vast
majority of reject cases to provide some appropriate notification to the
sender, and even the receiver if they wish. This rejection notification
starts on the scale of an unsubscribe request, escallates to delivery
failure notifications, then to rejections of the message during the DATA
sequence in SMTP, then to rejections of the message at the envelope
stage in SMTP, and finally to rejection of the network connection. In
all of these cases the sender would know that consent is not granted. If
we make the design of the system such that these cases are the "most
economical" (most automatic?) for the receiver then the vast majority of
cases will provide sender notification.

An side benefit of this interaction is that one can percieve a failure
to heed this notification can be considered abuse and therefore lead to
more aggressive countermeasures - such as blocking sender IPs and
Networks at gateway routers - thus denying the sender's ability to
compromize the network.

_M

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 08 Jul 2003 16:55:56 +0100

>Networks at gateway routers - thus denying the sender's ability to

Yes, you could do something like this. Also, I wouldn't be surprised if
you'd have a stronger case in law (for damages?) if the "trespass"
continues in the face of explicit rejections. But me not lawyer. Maybe
there's someone on the list qualified to give an opinion - pro bono of
course?

--

---

From: "Christopher Bird" <[email-masked]>
Date: Tue, 8 Jul 2003 11:48:29 -0500

This is similar to what I do as well. One issue I found was that the
from and replyto fields of an incoming spam ae often spoofed and have
the address of someone I know in them. This actic is becoming more and
more popular (witness the mail returned to my email address when I
didn't send it).

However that does seem to be a small price to pay for such excellent
performance.

I think there is a challenge and that is to make the handling of email a
lazy practice. I suspect that a large number of users have no interest
in doing anything but open their mail and have the stuff they want show
up and the stuff they don't want magically go away. Shades of the TV
dinner approach to eating. I want something good enough that doesn't put
me out too much.

Of course, for those of us in the network business, the issues are a bi
different. Wwe have to provide the defences, we have to keep our
customers' confidence high, we have to stop our own systems from being
inundated with junk... So what our end customers want and what we need
to do intersect, but are not congruent.

Has anyone here read David MacAuley's "Motel of the msyteries?" It is a
parable about archeologists discovering an ancient civilization (aka a
motel) that was buried when the government reduced the price of junk
snail mail. I suspect the members of this group will find the parable
instructive! I sure did.

Chris 

> Behalf Of C. Wegrzyn
> Sent: Tuesday, July 08, 2003 3:57 AM
> To: Jon Kyme
> Cc: ASRG
> Subject: Re: [Asrg] 3. Requirements - Non Spam must go through
> 
> 
> >>After years of divisive discussions, a very similar 
> pledge/oath/policy 
> >>was what EFF was able to come to agreement on:
> >>
> >>"Any measure for stopping spam must ensure that all 
> non-spam messages 
> >>reach their intended recipients."
> >>
> >false-positives for this to be true. Either a sender whose 
> message is 
> >not delivered because of the action of some "anti-spam" 
> system must be 
> >able to know this. And be able to find out what they can do 
> about it. 
> >(This is a very strong argument for "spam" rejection to 
> happen during 
> >the SMTP - or whatever - transaction; we don't want to be 
> sending DSN 
> >or challenges to forged senders.) Or, the "receiver" must be be 
> >informed that the message hasn't been delivered, and be able to do 
> >something about it (but this imposes a cost on the receiver).
> >
> >
> >
> >
> >
> >
> >--
> >

---

From: Barry Shein <[email-masked]>
Date: Tue, 8 Jul 2003 14:36:13 -0400

> emails should not be rejected but rather thrown away silently? So within 

I think when you're under that kind of attack you have little choice,
even just blocking the route tends to invite the hijacked hosts to go
into a retry loop.

 > thrown away and not even reported or tracked somewhere?

It's often a matter of survival. Or, put more pragmatically, imagine
it as a zero sum game, if you try to attend to each msg in such an
attack, even to log it, you might find yourself unable to deliver
someone else's legitimate mail in a timely manner (for example,
servers are often set to begin rejecting connections at a given load.)

I suppose one can hypothesize arbitrary amounts of computing power
(remember, we're talking about 200+ hijacked computers banging on your
servers, along with everything else) but at what point is one spending
significant money and administrative/management effort just to
accomodate spammers' resource requirements or some idealized notion of
how it all might be handled?

-- 
        -Barry Shein

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 08 Jul 2003 20:23:03 +0100

> even just blocking the route tends to invite the hijacked hosts to go

You mean not accepting connections from some host drives them to
hammer on your firewall?
I think that this is a truly exceptional situation. For which exceptions 
should clearly be made. I'm surprised that you manage to conserve resource
by accepting these connections and blackholing the messages.

--

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 08 Jul 2003 11:38:38 -0400

> You mean not accepting connections from some host drives them to

  Yes.  It increases the number of TCP SYN packets by a factor of 10
or more.

  Accepting all connections increases the total traffic, but the
number of SYN packets drops dramatically.

> I think that this is a truly exceptional situation.

  I've seen it, as have a number of other people with spamtraps.

  Alan DeKok.

---

From: Barry Shein <[email-masked]>
Date: Tue, 8 Jul 2003 16:06:44 -0400

> I think that this is a truly exceptional situation.

The term of art is "requeue & retry", which would be the standard
behavior of every MTA I've ever worked with upon connection failure.

Put 10,000 spam msgs headed for your host on some server and even 30
minute retry times don't help much, they get to the end of the list
and they're ready to start again with the first one which failed.

 For which exceptions 

-- 
        -Barry Shein

---

From: "Pete McNeil" <[email-masked]>
Date: Tue, 8 Jul 2003 16:58:11 -0400

>Sent: Tuesday, July 08, 2003 4:07 PM

> > You mean not accepting connections from some host drives 
>them to  > hammer on your firewall?  > I think that this is a 
>truly exceptional situation.
>
>The term of art is "requeue & retry", which would be the 
>standard behavior of every MTA I've ever worked with upon 
>connection failure.
>
>Put 10,000 spam msgs headed for your host on some server and 
>even 30 minute retry times don't help much, they get to the 
>end of the list and they're ready to start again with the 
>first one which failed.

Presume for a moment that a consent policy is adaptive so that it can
adjust it's "rejection policy" when abuse is detected. Abuse = a failure
to go away when told to (loosely).

I had recommended that the most aggressive level of rejection would be
to reject the connection.

Based on your comments perhaps the highest level (after that) is to
accept and silently eat messages from that SENDER or SENDERs.

Assuming that a standard consent policy framework allows systems within
a COT (Circle Of Trust) to adopt the policy decisions of their peers
under some conditions, then we might presume that a wide collection of
systems would adopt the same rejection policy.

I think this is not the final solution though - rather it is a safety
valve - a "cry for help" when a system elects this rejection policy.
What is needed at that point (or perhaps before) is DSQP (Dynamic
Squelch Propagation) where the decision to reject packets from the
offending source can be propogated as close as possible to that source -
essentially shutting it down. (DSQP is a mechanism needed for any kind
of abuse... consent policies are simply a good way to pull the trigger.)

DSQP (or some other name for the same thing) seems to be beyond the
scope of this group and ultimately would be a high-level network tuning
mechanism that effects routers. However this group should consider
making the recommendation for such a protocol and should implement the
structures needed in the consent framework to interface with protocols
like DSQP in response to abuse.

_M

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 09 Jul 2003 09:46:06 +0100

> number of SYN packets drops dramatically.

But I don't want to increase the total traffic, surely?

>   I've seen it, as have a number of other people with spamtraps.

I believe you. That doesn't make it not exceptional (i.e. normal). 

A spamtrap is a rather particular case. All messages are accepted - all
are successfully delivered ("success" and "deliver" have very particular
meanings in this context). No DSN are issued. No problem.

I think it's probably right to mention the spamtrap case in any document
dealing with filtering in SMTP (such as the one I'm *still* writing).
Thanks for bringing it up.

--

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 09 Jul 2003 11:00:03 +0100

> behavior of every MTA I've ever worked with upon connection failure.

I'm not familiar with the details of retry handling of any MTA except exim,
which manages retries per domain (or per target host). I gather from what
you say that the usual behaviour (for most MTA that bother you) is per
message.

>  > by accepting these connections and blackholing the messages.

So what sort of bandwidth saving do you make by doing this?

--

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 09 Jul 2003 07:33:30 -0400

> meanings in this context). No DSN are issued. No problem.

  You're missing a key point: The spamtrap is usually a spamtrap ONLY
because it gets so much spam that it's useless as a normal domain.

  i.e. It was getting massively attacked by spam, which is *why* it
was made a spamtrap.

  It's not the case that it became a spamtrap, and *then* started
receiveing large amounts of spam.  That would imply that the spammers
know it's a spamtrap, and increase their messages to it... which is
not realistic.

> dealing with filtering in SMTP (such as the one I'm *still* writing).

  It's also a problem with IP firewall whitelists.  If the MX for a
domain is publicly advertised, but the MTA is behind a firewall with a
whitelist, then the firewall will get whacks of TCP SYNs from
spammers.  And the rate at which the SYNs arrive will drop, once the
firewall rules are removed.

  In other words, any attempt to protect yourself from spam will
result in the spammers attacking you even more, in the hope that
*something* will get past your filters.  This increase in spam volume
means that the filters become less effective...

  Alan DeKok.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 09 Jul 2003 17:07:27 +0100

> means that the filters become less effective...

I'm still surprised that you manage to conserve much in the way
of resources by accepting these connections and blackholing the messages.
What happens if the messages are rejected hard
during the transaction - are they still retried? I'm sure I remember
postings about this in the early days of the list but I can't find the
numbers.
What do the figures look like? If you don't mind me asking.

--

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 09 Jul 2003 09:40:17 -0400

> of resources by accepting these connections and blackholing the messages.

  The number of TCP SYNs go down when there's no firewall whitelist,
but the total bandwidth used doesn't change by much.

> What happens if the messages are rejected hard during the
> transaction - are they still retried?

  Yes.

  For some reason, spammers don't appear to be following the SMTP
"best practices" documents.

> What do the figures look like? If you don't mind me asking.

  Millions of TCP SYNs per day, with a firewall whitelist.

  When all connections are accepted & email to non-user accounts
silently discarded, 500K+ messages per day.  When taken against
"real" email to me at the domain, the traffic is more than 99.9% spam.

  And it's been going up by a factor of at least 2, every year, for
about as long as I've had the domain.  This is the future of email for
everyone.

  Alan DeKok.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 09 Jul 2003 22:02:15 +0100

> but the total bandwidth used doesn't change by much.

Have I got this right? You don't save any bandwidth by accepting and
blackholing these messages?

> "best practices" documents.

I can't imagine what that reason is (apart from stupidity). Again, I'm
surprised - I guess that this isn't coming through open (but otherwise
normal) relays - It also seems rather costly for the spammer.

>   Millions of TCP SYNs per day, with a firewall whitelist.

I might be wrong about this but I seem to remember that a TCP/IP packet
with no data is about 40 octets? So I can see that sending millions of RST
to millions of SYN might add up to about the same bandwidth as accepting
hundreds of thousands of spam.

> "real" email to me at the domain, the traffic is more than 99.9% spam.

I still can't see what the issue here is. Silently failing this spam
doesn't seem to save anything much.

> about as long as I've had the domain.  This is the future of email for

I don't see how that follows, but I can't prove that you're not right.

Thanks for bearing with me.

--

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 09 Jul 2003 17:21:20 -0400

> blackholing these messages?

  That's not what I said.

  Accepting the connection means 1/10 the TCP SYNs, which means
there's that much SMTP traffic which can occur, before the messages
start taking more bandwidth than the TCP SYNs.

  How much data is in each spam message? 2k? 10K?  For 100's of 1000's
of messages, as opposed to much smaller TCP SYN packets, for millions
of packets.

  The total bandwidth is similar, to an order of magnitude or so.
There is no massive savings in spam, by either blocking, or accepting
messages.

> I can't imagine what that reason is (apart from stupidity).

  Stupidity, laziness, or malicousness, it's all the same in the end.

> hundreds of thousands of spam.

  Yup.

> doesn't seem to save anything much.

  That was most of my point.

  Spam is a permanent DDoS attack, and until it's fixed at the
source(s), there's little any one recipient can do to stop the flood.

> I don't see how that follows, but I can't prove that you're not right.

  It follows because that's been my experience over the past number of
years.  Everyone else's spam loads are going up significantly.  The
only reason why they don't have my traffic yet is that they started
off lower in the spam load.

  Since everyones spam loads are increasing, the peak loads today will
be the average loads in a few months to years.  The ONLY way to make
that statement untrue is to prevent the spam loads from increasing.

  Alan DeKok.

---

From: "Pete McNeil" <[email-masked]>
Date: Wed, 9 Jul 2003 17:24:12 -0400

>Have I got this right? You don't save any bandwidth by 
>accepting and blackholing these messages?

What about silently breaking the pipe? That is, accept the connection
(one packet) then forget about it. The sender's device would have to
time out before trying again. I know it's a low-level networking hack,
but it might save bandwidth over the other two alternatives. Thoughts?

-- at any rate, whatever response can be devise for rejecting abusive
connections, the consent policy must support the execution of any
rejection method available on the system if consent is denied... 

_M

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 09 Jul 2003 19:09:10 -0400

> but it might save bandwidth over the other two alternatives. Thoughts?

  It's a thought, but I haven't tried it myself.

  People have tried similar things with 'teergrube', and it doesn't
appear to make enough different to be worthwhile.

  Alan DeKok.

---

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 09 Jul 2003 19:20:06 -0400

The problem is the cost of opening/closing  the connection - that is a 
pretty heavy penalty. I'd be more like to just route the bits to the 
great bucket in the sky.

Chuck

---

From: Pete McNeil <[email-masked]>
Date: Wed, 09 Jul 2003 19:59:37 -0400

In general, I agree... just tell the router to drop the packets... but it 
has been said that this leads to an accelerated retry situation... so, to 
forestall that, have the router send back an acknowledgement packet (rather 
than an ICMP unreachable) and then forget all about it... That is, if it's 
from the unwanted, abusive source, replace the unreachable packet with an 
ack/est. Then be done with it.

For the system under attack it's still just one packet. For the attacking 
system it's an apparently open pipe - except when they try to send, there's 
no "there" there... but they must time-out before they know that. This, at 
least, delays the retry and requires very little overhead when compared 
with a normal rejection.

This isn't something I recommend, I think the right way to do it is just 
drop the packets, but it _may_ be a reasonable response to what has been 
called a DDoS attack if simply dropping the packets doesn't work (as 
described).

Until DSQP can be deployed so that the border router of the attacker's 
upstream disconnects them, the receivers will need to have options for 
mounting a defense.

_M

At 07:20 PM 7/9/2003 -0400, C. Wegrzyn wrote:
>pretty heavy penalty. I'd be more like to just route the bits to the great 
>bucket in the sky.
>
>Chuck
>
>Alan DeKok wrote:
>

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 10 Jul 2003 00:28:25 -0400

>I don't see how that follows, but I can't prove that you're not right.

Take a random domain with a random number of addresses.  Eventually 
they start getting spam.  Two things happen.  First, no matter what 
your churn, the addresses that got spam will continue to get 
more--even if they stop existing.  Furthermore, over time typos, 
screwed up alphabet attacks and other factors will cause more and 
more non-existent addresses to get spam.  It always grows.  It never 
shrinks.

Although somewhere.com is behind striker on the curve (only 10 
million bounces last year), I've also been seeing the factor of two 
progression for the five or six years I've been tracking it.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
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: "Jon Kyme" <[email-masked]>
Date: Thu, 10 Jul 2003 11:09:48 +0100

> more non-existent addresses to get spam.  It always grows.  It never 

It certainly seems that way, but all we actually know is that
it *has* always *grown*, it *has* never *shrunk*.

This is begging the question rather. Are addresses ever removed from
spammers lists? Will they ever be? Is there an economic argument for the
list producers to "improve the quality" of their lists? Will there ever
be? What are the effect on list dynamics of current and future anti-spam
deployments? legislation?

I guess this would come under "understanding the problem".

> progression for the five or six years I've been tracking it.

These are exactly the sort of numbers that someone should be collecting
(and aggregating). I'm not denying the truth of anyone's observations. It's
just that the predictions are also based on some assumptions about spammer
behaviour - which I don't know much about.

"I can't prove you're not right" = "not falsifiable right now" (time will
tell).

Regards,
JK

--

---

From: Walter Dnes <[email-masked]>
Date: Thu, 10 Jul 2003 06:12:33 -0400

On Wed, Jul 09, 2003 at 07:20:06PM -0400, C. Wegrzyn wrote
> pretty heavy penalty. I'd be more like to just route the bits to the 

  On the other hand, if your MTA *MERELY PRETENDS* to open a connection
(i.e. send back SYN-ACK without actually opening a connection) most
spammers will pipeline everything else through without waiting for
further responses.  They *HAVE* to do this to protect against
teergrubes.

-- 
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: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 07:40:41 -0400

I'll say from my own experience that addresses are removed only if they 
bounce at the MTA level. I tried this by "sniffing" what was going on to 
my MTA. When I killed an account and watched I noticed that it did slow 
down though it took over 6 months! I believe the problem is that when 
the address is on the "CDROM" or list spammers buy/sell you are on it 
until the list gets updated and sold. But this is merely speculation.

Chuck Wegrzyn

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 07:42:33 -0400

What I can also tell is that I have two accounts - one public and one 
very private. The public one gets spammed all the time. The private one 
hasn't ever gotten a spam message. The private one I use to communicate 
with friends, business people, etc. The public one is used on netnews 
(yes I know...talk about advertising!), lists such as this one and 
general postings. That one gets spammed all the time.

Chuck Wegrzyn

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 07:44:14 -0400

Ah, good idea! I didn't think of that one. Does anyone have a Linux hack 
for this one?

Chuck Wegrzyn

---

From: Andrew Akehurst <[email-masked]>
Date: Thu, 10 Jul 2003 15:27:21 +0100 (BST)

> general postings. That one gets spammed all the time.

How long have you had that private address? Perhaps there's something about the 
name which makes it difficult to guess in a dictionary attack.

I've been through three private addresses over a period of 5 years, all based 
at Hotmail. Admittedly it's an obvious domain for spammers to target, so that 
might be a factor in what follows. But anyway here's one insight...

The first Hotmail address got spammed because I was careless in those days, 
gave it out widely and I'm sure it found its way into various list archives and 
other web pages so it got crawled easily. Eventually I ditched it because the 
spam was overwhelming and Hotmail filtering was pretty non-existant in those 
days. Even if I hadn't given it out, it was a pretty short easily-guessed name 
and Hotmail tended to list people by default in their member directory anyway.

The second new address was still fairly simple in composition: a string of 10 
alphabetic characters representing my intials and surname. I was a lot more 
careful to keep this private but somehow spam started to trickle in and 
(perhaps because the initial trickle failed to bounce), a whole flood opened 
up. I suspect that this account was spammed by dictionary attack, particularly 
because other (very similar) addresses at Hotmail often appeared in the "To:" 
or "CC:" headers of the spam I received. Hotmail was pretty obliging about 
sending "no such user" bounces in those days so I'm sure this was an effective 
method for the spammer. (I've no idea what their bounce policy is like now.)

My latest Hotmail address I've been equally paranoid about giving out, but I 
chose a less obvious name with an underscore embedded. For the first 9 months I 
received no spam whatsoever but now some has begun to arrive. In this case I 
think either a company I corresponded with has sold my address or else 
dictionary attacks are becoming more sophisticated.

The issue of how spammers obtain e-mail addresses in the first place, and under 
what conditions they tend to stop sending to an address can be helpful to 
understanding the nature of the problem. In fact I've still kept one of my old 
addresses as a spam trap so I can collect spam and study it.

I'm guessing that many honeypot people do analysis like this all the time, only 
they're in a position to do so more rigorously than my little dabbling. Any 
insights into this would be most interesting (to me at any rate).

Andrew

---

From: "C. Wegrzyn" <[email-masked]>
Date: Thu, 10 Jul 2003 10:36:43 -0400

Andrew,

 The private email address is absolutely simple to guess. I think it has 
more to do with how I use it than the name. It also isn't part of the 
"public" email systems available - Yahoo, MSN, AOL - and I think that is 
the difference. I've often thought about keeping the private one for all 
my communications and using ".forward" on all my public persona's. In 
the public persona's I would run filters and forward only non-spam (or 
at least closer to non-spam).

I have opened up a new email account on Hotmail and within a week I had 
more than a dozen spam messages in it! I think these guys sell the email 
addresses and do nothing but contribute to spam. But it is merely a 
guess; I can think of no other way that my unused email address would 
have gotten out.

Chuck Wegrzyn

Andrew Akehurst wrote:

>>>>>>  And it's been going up by a factor of at least 2, every year,
>>>>>>            
>>>>>>
>>for
>>    
>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>about as long as I've had the domain. This is the future of email
>>>>>>            
>>>>>>
>>for
>>    
>>
>>>>>>everyone.
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>I don't see how that follows, but I can't prove that you're not
>>>>>          
>>>>>
>>right.
>>    
>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>spammers lists? Will they ever be? Is there an economic argument for
>>>      
>>>
>>the
>>    
>>
>>>list producers to "improve the quality" of their lists? Will there
>>>      
>>>
>>ever
>>    
>>
>>>be? What are the effect on list dynamics of current and future
>>>      
>>>
>>anti-spam
>>    
>>
>>>These are exactly the sort of numbers that someone should be
>>>      
>>>
>>collecting
>>    
>>
>>>(and aggregating). I'm not denying the truth of anyone's observations.
>>>      
>>>
>>It's
>>    
>>
>>>just that the predictions are also based on some assumptions about
>>>      
>>>
>>spammer
>>    
>>
>>>"I can't prove you're not right" = "not falsifiable right now" (time
>>>      
>>>
>>will
>>    
>>
>>>tell).
>>>
>>>Regards,
>>>JK
>>>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>