Subject: RE: [Asrg] Certs required to send mail

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Mar 2003 11:36:29 -0800

What I have not seen an answer to is my point that bulk mailer 
software is already designed to drop connections that are too slow
and so the only effect tarpits is likely to have is on the most naive
spam senders and friendly fire on the innocent.

Another problem is that any hackback system can be abused by hackers.
We saw this in network security, attackers simply co-opted the
hack back systems to attack the targets of their choice.

How many tarpits are set up to be proof against a subversion attack?
Do they authenticate the information they use for targetting? 
What happens if someone poisons the distribution of the RBL?

	Phill

> Tarpits are an interesting idea, but of course they have a 
> risk.  As we
> know all spam detectors have false positives, and we must be very sure
> we don't tarpit a legitimate mailer.   In one case, when we 
> at the EFF sent
> out our newsletter including some notes about spam, 
> SpamAssassin tagged it
> as spam.  This would have put us in a tarpit if it used 
> similar algorithms
> to SpamAssassin.
> 
> However, this can work if you can make an easy system for 
> legitimate mailing
> lists to whitelist themselves to be immune from any 
> tarpitting.   I would
> recommend a wide variety of means of whitelisting, ranging 
> from the basic
> of getting your IP on a list, to certificates, to magic-tags etc.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked] (Justin Mason)
Date: Wed, 26 Mar 2003 13:44:32 -0800

> What happens if someone poisons the distribution of the RBL?

There's some incorrect use of terminology here; a "tarpit" simply answers
queries slowly, affecting only the TCP connection from the SMTP client.

There's no "hackback", there's no RBL use, there's nothing there to
subvert in order to cause attacks on third-party targets.

Running an SMTP transaction very very slowly will not cause any damage,
except possibly to cause resource limitation issues if the SMTP client
machine is operating a huge number of connections simultaneously -- ie.
a spammer (or a very large bulk mailer, conceivably).

"Honeypots" may be a different matter, though.

--j.

---

From: Brad Templeton <[email-masked]>
Date: Wed, 26 Mar 2003 14:01:31 -0800

While I know the spam definition question, though in the long term unavoidable,
is a quagmire, let me redirect to something that might not be so intractable.

That is, "what is the problem we're here to fix from an engineering perspective?"

Some in the anti-spam community have written like they think the problem
is they got a mail they didn't like or didn't ask for, and this is what
must be solved.

Let me express why I think we're here and see if people agree.

    1) Unwanted E-mail volume is sufficient to put a major burden on servers
	and pipes.
	Goal: Reduce the volume so it is a tiny fraction of desired traffic
	and thus no longer worthy of engineering notice.

    2) Unwanted E-mail volume is sufficent to reduce the signal/noise ratio
        in user E-mail boxes, making them of lower utility to their users.
	For some users (mostly outside USA), noticeable costs are also
	incurred.

	Goal: Reduce that volume to minor nuisance level, so that users are
	not averse to using E-mail because of it.  A S/N of 100 to 1 would
        certainly do this, for example.

    3) Users are afraid to reveal their E-mail address in public, mostly
        because of problem #2.

	Goal: Eliminate that fear.  May be done by eliminating problem 2, but
	there are also other ways to go after this problem.

    4) Service providers suffer undue cost handling complaints about mail
        which originated from their networks, or didn't originate there but
        appeared to originate there.

	Goal: Reduce complaint volume to manageable levels.

So while I have done nothing to rigidly define spam, I hope I have stated
why we are here, why people think there is a need to fight it, for
engineering reasons.  Is this a better place to start?