Subject: RE: [Asrg] Spam Control Complexity -- scaling, adoption, diversit y and scenarios

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Apr 2003 09:29:27 -0700

Again Dave, you are putting mechanism ahead of analysis.

This working group is charged with a purpose, to stop spam.
It is not charged with stopping spam by method X.

This group should not be proposing mechanisms that are worse
than non network based mechanisms.

Best practices statements have long been a feature of the
IETF and IRTF. These have rarely considered the purely interop
issues you are promoting.

Like many others in the IETF you appear to have the idea that
it is somehow your position to impart your learned experience
to this group. We are well aware of the issues you have raised,
you are not the first to have raised them. 

Your intervention is understood to be well intended. Understand
that this is an area where interventions by individuals whose 
interests lie in no solution being developed are likely.

What is needed at this stage is a FAQ which states the problems 
identified with the frequently proposed solutions. So each time
we get another tourist comming to propose 'Sender pays' or 
'making each person who sends me email play a little game' or
such we do not have to go through the whole education process.

I would like to propose that each proposal for a spam solution
that already appears on the list be required to start what 
solutions it proposes to the problems identified in the FAQ.
So that the next person to suggest sender pays is expected to
explain what solution they propose for the infrastructure cost,
double ended deployment problem, the freerider problem, etc.

		Phill

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Tuesday, April 22, 2003 11:20 AM
> To: [email-masked]
> Subject: Re: [Asrg] Spam Control Complexity -- scaling, adoption,
> diversit y and scenarios
> 
> 
> Folks,
> 
> There seems to be some confusion about the nature of a networking
> standard.
> 
> Networking standards are very different from software development.
> They specify conventions for inter-operation.  That is, they provide
> for some type of interaction that has functions and formats that are
> pre-speicified (ie, standardized.)
> 
> So if this group has any interesting in doing work that leads to
> networking standards that pertain to control of spam, it needs to
> focus on conventions for interaction between Internet systems.  That
> is, protocols for relevant distributed functionality, and formats for
> relevant shared information.
> 
> The list that Vernon produced provides some excellent examples.  By
> contrast, simply saying that there is a component somewhere in the
> system -- such as a filter -- does *not* provide a useful example,
> unless there is an indication of the types of conventions that should
> be standardized, to permit the filter to do its job.
> 
> d/
> 
> 
> TT> Dave Crocker wrote on 20 April 2003 02:19
> 
> >> "doubled ended" sounds like a dandy term.  what does it mean?
> >>
> >> if it means "at both ends" then i would be quite 
> interested to hear how
> >> any enhancement that involves interoperability can be 
> useful if deployed
> >> to only one component.
> 
> TT> Example 1:
> TT> Email filteroing for viruses.  Implemented at receiver's 
> end. Or at
> TT> sender's end.  Doesn't matter which.  Doesn't have to 
> implemented at both
> TT> ends for parties who wish to interoperate.  Implement at 
> receiver's end only
> TT> if you don't wish to interoperate with deliberate 
> transmitters of viruses.
> 
> TT> Example 2:
> TT> Spam filtering using a reliable BL.  Implement at 
> receiver's end.  Implement
> TT> at sender's end if you think of sender as including ISP 
> MTA as well as
> TT> end-user MUA.  But don't implement at receiver's end if 
> you don't want to
> TT> interoperate with spammers.
> 
> TT> Frankly, I think your comment is crazy. I could go on 
> listing enhancements
> TT> that can be applied at one end or at the other end or at 
> both ends and still
> TT> allow all required interworking until I got writer's 
> cramp, and still would
> TT> not have listed all the ones that I have seen implemented.
> 
> TT> Tom Thomson
> 
> 
> 
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Apr 2003 11:55:57 -0700

Phillip,

HBP> This working group is charged with a purpose, to stop spam.
HBP> It is not charged with stopping spam by method X.

You keep citing that as if it meant that the group can and should
consider anything it wants to.  As if, for example, this group would
be a reasonable venue for formulating legislation.  After all, some
people think that will "stop spam".

Alas, this is an IRTF activity. and the charter for this particular
group includes:

   "Expressing consent is more straightforward on an individual basis;
   as the solution is moved closer to the source, it is more difficult
   to express a policy that satisfies all downstream receivers. The
   research group will investigate the feasibility of: (1) a single
   architecture that supports this and (2) a framework that allows
   different systems to be plugged in to provide different pieces of
   the solution. "

For this group to spend time on anything other than networking-based
technical solution paths is seriously inappropriate, except to the
extend that study of related issues helps the group do its networking
work.

HBP> Best practices statements have long been a feature of the
HBP> IETF and IRTF. These have rarely considered the purely interop
HBP> issues you are promoting.

Pretty much everything that comes out of the IETF is about
interoperability.  BCPs, in particular, focus on the administrative
and operations aspects of making Internet protocol (and format)
specification viable in the modern, global Internet.  In effect, they
are about the *essence* of interoperability.

HBP> Like many others in the IETF you appear to have the idea that
HBP> it is somehow your position to impart your learned experience

Good job.  Slam the IETF and me at the same time.

By the way, I note that your own expertise appears to lack the ability
to follow through on discussing basic assertions you make.  In
particular, you have not yet pursued the substance of:

   1. You made an assertion about the operational superiority of
   enhancing an installed base through a core approach, rather than an
   edge approach.

   2. I asked you to cite an example of such an approach being done
   successfully (both broad and timely deployment and use) through
   architectural changes to the core, when it could have been done to
   the edge, instead.

Presumably you are not making up your assertions of fact, on the spur
of the moment, and you actually do have some "learned" experience and
thought behind them. So it would be helpful for you to offer details
about both when your assertions of fact are not automatically accepted
on blind faith. Presumably you are participating in this open exchange
with the intent of constructive dialogue?

HBP> What is needed at this stage is a FAQ which states the problems
...
HBP> I would like to propose that each proposal for a spam solution
HBP> that already appears on the list be required to start what 
HBP> solutions it proposes to the problems identified in the FAQ.

Presumably you are offering to produce the draft of that "FAQ"? It
sounds like it might be useful.

d/

---

From: Andrzej Filip <[email-masked]>
Date: Tue, 22 Apr 2003 21:57:53 +0200

Dave Crocker wrote:

>[...]
e.g. making MTAs record bounces to non existing local addresses may help 
in legal actions against "sender faking" spammers.

It woul require MTA to reject messages from <> to non existing local 
recipient in reply to "final dot" insted of reply to RCPT TO: => bounce 
but keep for possible legal action

[I suggested  it some time ago in news:comp.mail.sendmail ]

 > [...]

-- 
Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 22 Apr 2003 23:12:49 -0400

At 9:57 PM +0200 4/22/03, Andrzej Filip wrote:
>e.g. making MTAs record bounces to non existing local addresses may 
>help in legal actions against "sender faking" spammers.
>
>recipient in reply to "final dot" insted of reply to RCPT TO: => 
>bounce but keep for possible legal action

Legally require people to keep a copy of bounces to non-existent addresses?
Sigh.  Time to buy another disk I guess.

Of course there's the minor problem that that means I have to collect 
the message instead of bounce it at RCPT time.  Who's going to pay 
for the upgrade to my bandwidth?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
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.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Andrzej Filip <[email-masked]>
Date: Wed, 23 Apr 2003 09:49:39 +0200

At Apr 2003 23:12:49 -0400 Kee Hinckley wrote:

>> It would require MTA to reject messages from <> to non existing local 
>> recipient in reply to "final dot" instead of reply to RCPT TO: => 

I merely suggested making it "technically possible" and recomended, you 
suggest the logical next step - making it legally required for (some?) 
companies/ISPs.
[I will try to use more precise wording next time]

> Sigh.  Time to buy another disk I guess.

Tapes may be more suitable for the task.
How many messages from <> to non existing local users YOUR site bounces 
per day ?

> the message instead of bounce it at RCPT time.  

Replace "have to" by "can" to get what I wanted to suggest.

> Who's going to pay for the upgrade to my bandwidth?

You. Have you expected another answer ?

Are you ready to tell in public that you do not give a dam about who 
fakes sender addresses in your email domain ?

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 23 Apr 2003 08:31:14 -0600 (MDT)

> From: Andrzej Filip <[email-masked]>

> ..

> fakes sender addresses in your email domain ?

Why not?  Why would the public care?

Besides, whether your SMTP server says "550 5.1.1 asdf... User unknown"
after the "\r\n.\r\n" after the DATA command or after "Rcpt To: asdf"
and regardless of whether your SMTP server records messages bodies,
everyone with standing to ask already knows who is faking sender
addresses in your domain.  Those who have standing to ask the question
are those who have received bounces containing transcripts of the
session from the SMTP client.

There are conflicting demands here.  Worse, both sets of demands are
dubious solutions to issues that are not significant problems in the
Internet and not currently in the charter for this mailing list.  On
one hand, there are demands that bounces be suppressed or contain less
information lest spammers use them.  Some of these demands are based
on the theory that someday there might be a significant amount of spam
using bounces.  On the other hand, there are demands that bounces or
at least logs include more information in support of some sort of
legal theory.

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

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 23 Apr 2003 10:44:42 -0400

At 9:49 AM +0200 4/23/03, Andrzej Filip wrote:
>How many messages from <> to non existing local users YOUR site 
>bounces per day ?

I don't know, my mail system only logs the RCPT address in the bounce info.
I'm currently averaging 30 bounces a minute, with a peak of 96 in the 
last 24 hours.  I've seen as high as 700 per minute though.  That's 
on a site with no more than a dozen or so real email addresses.
http://www.somewhere.com/mrtg/smtp-reject.html

Actual bounce-back used to be worse when we were a common forged 
address.  I could get thousands a minute if AOL's servers were 
getting hit.

>fakes sender addresses in your email domain ?

I used to.  I don't anymore.  It's kind of like littering.  I'd like 
it to stop, but I'm not going to try and track every piece of litter 
to the source--just the big abusers.  Keep in mind, I'm a special 
case.  Millions of people forge somewhere.com.

Unfortunately the fact that I know who they are doesn't help me at 
all.  Axis (internet-enabled video cameras).  Microsoft (FrontPage 
templates).  They forged it.  I'm suffering the consequences.  Now 
what?

If you want to look at legal requirements. Give me a way of going 
after someone for forging my domain where I can claim more than just 
lost time as my damages.  Then you won't need to require people to 
store bounce-back--they'll have an incentive.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Andrzej Filip <[email-masked]>
Date: Wed, 23 Apr 2003 19:03:25 +0200

>session from the SMTP client.
I have tried to see the problem from "the court room proof" perspective 
[providing proof of big and systematic abuse over long period of time].
Such perspective make sense only if we believe that legal actions can 
"scare off" enough spammers. It seems that believers in "the law can 
help fix it" constitute a minority here.

>at least logs include more information in support of some sort of
Gathering evidence for woud be legal actions alone will not solve spam problem but it MAY constitute a part of proposed actions.

---

From: Andrzej Filip <[email-masked]>
Date: Wed, 23 Apr 2003 18:40:42 +0200

Kee Hinckley wrote:

> last 24 hours.  I've seen as high as 700 per minute though.  That's on 
> a site with no more than a dozen or so real email addresses.
> address.  I could get thousands a minute if AOL's servers were getting 
> hit.

You have provided a convincing proof that recording bounces sent to 
nonexisting addresses on your sytem does make a difference.
But anyway you talk about 1/2 messsage per second (on average), less 
than 2 messages per second in peak and 43000 messages per day.

I think (and hope) that your system situation is not typical.

> case.  Millions of people forge somewhere.com.

It is sad that I can understand you :(

> templates).  They forged it.  I'm suffering the consequences.  Now what?
>

I hope that the legal system is capable to punish big systematic 
abusers, I know it will take "some" time.

There is a chance that spammers will prefer to forge addresses in 
domains without such records I suggested ;-)