Subject: Re: [Asrg] Re: TitanKey and "white lies"... (Faking SMTP hard errors "improves" C/R utility?)

From: Scott Nelson <[email-masked]>
Date: Sun, 01 Jun 2003 23:07:32 -0700

At 06:21 PM 6/1/03 -0400, mathew wrote:
[edited]
>
>Now, I may be wrong, so what if users *are* prepared to go visit a web 
>site in response to a challenge from a C/R system? In that case, I give 
>it about a week before we start seeing spam that's a verbatim copy of 
>the TitanKey C/R text, followed by a URL which redirects to a porn 
>site. Users learn to associate C/R system challenges with porn spam, or 
>(even worse) their Bayesian spam filter recognizes the cloaked URL and 
>learns to filter out challenges automatically.
>
>In fact, a similar problem applies to any other C/R system--inevitably 
>we'll see spammers sending fake C/R challenges as a means of obtaining 
>confirmed e-mail addresses.
>

It's probably true of most systems in use, but any?  
Never use absolutes, they will always get you in to trouble.

Suppose that all challenges included the Message-Id: of the 
quarantined message in it's In-Reply-To: and/or References: header.
(like all DSNs should - grrr)

Then as long as mail clients can recognize message-ids they've created,
it's a simple matter to accept any you've generated, and discard any
that you haven't.  (Handy for those forged return address bounces too.)

If you're worried that spammers will start forging plausible ids 
for their In-Reply-To: headers, or that's too hard for your computer
to remember a few thousand IDs, here's a simple way to create them.
id = "UTC.N@" . md5sum(UTC, N, domain, secret);
where N doesn't repeat in one second intervals (PID is traditional),
and secret is several high quality random bits (say, 16 bytes worth).

That still leaves replay attacks using IDs scraped from 
mailing lists within the expiry date.
With a few tiny changes to the way mailing lists work,
it would actually be possible to close that hole too,
but I think that's a bit excessive for something that 
is only a remote possibility.

IMO the killer problem with C/R is the "automated notice of 
something important" message.  Frequently, those don't even have 
a valid return address, much less a human that will click 
on your web site.

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

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 2 Jun 2003 07:21:35 -0600 (MDT)

> From: Scott Nelson <[email-masked]>

> ...

Many absolutes, including that one, can get you into trouble.

> that you haven't.  (Handy for those forged return address bounces too.)

So few users know what a message-ID is, and so few of those who do
know have the least clue about the message-IDs of their last dozen
sent mail messages that it is safe to make the absolute statement that
no users could ever distinguish valid from bogus spammer challenges
with message-IDs.

> ...

How many people are going to manually check the last few days of mail
they've sent looking for the message-ID of a new challenge?  Obviously
no one, including practically all C/R advocates will bother.  If any
users were willing and able to do that, there would not be a continuous
flood of questions from people asking how their computers managed to
send spam when they weren't looking when they get a forged bounce.

Even if you modify everyone's MUA to record the Message-IDs of outgoing
mail (no, not all MUAs do that, not even when configured to record
outgoing mail), the absolute statement that no one would manually
check Message-IDs is still more than "5-nines" true.  You would have
to modify MUAs to automagically check "sent folders."

This sub-thread started with the observation that many of us can't
remember to whom we sent mail, and you want us to remember Message-IDs?
If manual (or automatic) checking of Message-IDs could work, then so
would manual (or automatic) checking of "sent folders" for recipients
(except for .forward files, aliases, etc.).

> a valid return address, much less a human that will click 

That's also a killer.

C/R systems depend on and will in practice devolve into whitelisting
systems.  It would be good to finish the C/R protocols, IDs, or whatever,
and move on to the whitelisting mechanisms that C/R systems require.
That's where most of the utility will lie.  You'll need protocols or
some sort of mechanical support to exchange self-signed certs, PGP keys,
or whatever to foil spammer attacks on the whitelisting system.

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

---

From: mathew <[email-masked]>
Date: Mon, 2 Jun 2003 16:09:32 +0100 (BST)

> that you haven't.  (Handy for those forged return address bounces too.)

There are millions of e-mail clients that don't even generate Message-IDs
and In-Reply-To: headers, let alone record the ones on sent mail.

If I name Lotus Notes and Eudora as examples, that's probably a two-digit
percentage of all e-mail for starters (Notes being the biggest-selling
enterprise e-mail system, and Eudora being second in popularity to Outlook
on the desktop). Both have been that way for decades. If C/R won't work
unless the vast majority of people upgrade their e-mail client, then I don't
see much hope for it.

As an aside... SpamAssassin with Bayesian filtering is so good that it's
weeks since I last had a false positive, and I've had only a handful of
spams in the same period, all for products that apparently hadn't been
spamvertised before.

mathew
-- 
Journal and other stuff at <URL:http://www.pobox.com/~meta/>