Subject: [Asrg] Proposal: SMTPCR, a kinder/gentler Challenge/Response

From: "Walter Dnes" <[email-masked]>
Date: Sun, 22 Jan 2006 23:56:46 -0500

Challenge Response Authentication Protocol (figure out the acronym <g>)
has one fatal flaw in its current implementations.  It sends an email to
the alleged sender (envelope-sender or From:), and ends up reflecting
spam to innocent 3rd parties.  "In-band-signalling" doesn't work in a
hostile environment, a fact demonstrated a long time ago to telcos via
Captain Crunch whistles.  We need something outside of email messages,
and it must be done when the receiving system is in direct contact with
the sending system.  Only in this manner can we guarantee that a
challenge goes back to the actual sender rather than to innocent 3rd
parties.

  The only time the receiving system is in direct contact with the
sending system is during the SMTP transaction itself.  The challenge
must be sent during the SMTP transaction.  To avoid FUSSP status, a
proposal must work without both parties having to modify their MTAs.
I propose the following...

  - Sending MTA connects to receiving MTA
  - Receiving MTA accepts email if it is from a whitelisted sender, or
    contains the "magic password" (or whatever).
  - Otherwise, if the email is not dropped or rejected (virus, etc), the
    receiving MTA sends a 599 return *WITH A SHORT MESSAGE/URL POINTING
    TO A CAPTCHA TEST*.  (It doesn't have to necessarily be 599; this is
    just an example).
  - The sender gets the reject message, reads it, and jumps through
    flaming hoops as per current methodology

  I call this concept "SMTPCR", to indicate that it's an SMTP-stage
challenge/response system.

  What this proposal does not do...
  1) It does not solve all spam
  2) It does not make responding to CAPTCHAs easier
  3) It does not deal with relays.

  What it does do...
  It eliminates "blowback" *BY THE DESTINATION MTA* to innocent 3rd
parties.  *ANY* SMTP-stage rejection of email from a relay can cause the
relay to send a bounce message to a forged/innocent email address.
However, it's a helluva lot easier to block 1 relay *DIRECTLY*, than to
block bounces from all over the planet.

-- 
Walter Dnes <[email-masked]> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca

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

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 23 Jan 2006 05:29:30 +0000

On Jan 22, 11:56pm, Walter Dnes wrote:
}
}   - Otherwise, if the email is not dropped or rejected (virus, etc), the
}     receiving MTA sends a 599 return *WITH A SHORT MESSAGE/URL POINTING
}     TO A CAPTCHA TEST*.  (It doesn't have to necessarily be 599; this is
}     just an example).

This technique is already "in the wild". It'd take me some considerable
digging to find the site, as it was a few weeks ago (it might be UC
Davis, but I really don't remember for sure), but I have encountered
an SMTP rejection where the 5.7.1 response text pointed to a web page
instucting one to paste the returned email message in a text area and
type the text from an image into another input field.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 23 Jan 2006 08:28:31 +0100

Walter Dnes wrote:

>   - Receiving MTA accepts email if it is from a whitelisted
>     sender, or contains the "magic password" (or whatever).
>   - Otherwise, if the email is not dropped or rejected
>     (virus, etc), the receiving MTA sends a 599 return *WITH
>     A SHORT MESSAGE/URL POINTING TO A CAPTCHA TEST*.  (It
>     doesn't have to necessarily be 599; this is just an
>     example).
>   - The sender gets the reject message, reads it, and jumps
>     through flaming hoops as per current methodology

That doesn't work as expected for the 1123 5.3.6(a) "user not
local" 251-style forwarding case.  In that scenario it's the
forwarder getting the 5xx reject, and because it already had
accepted the mail it's forced to create a bounce message to
the alleged Return-Path.

That's of course an innocent bystander, the Return-Path was
forged.  This type of forwarding cannot work after RfC 1123
eliminated reverse paths.

What you get is essentially SPP with 5xx-CAPTCHAS instead of
sender policies.  All other ingredients are identical, it
works at the border MTA (MX) of the receiver, but not behind
that point.  It doesn't work with the 251-forwarding concept
in 1123.  It has no issues with 1123 5.3.6(b) redistribution
(mailing lists).

> 3) It does not deal with relays.

Yes, my comment is covered by your point 3.

> it's a helluva lot easier to block 1 relay *DIRECTLY*, than
> to block bounces from all over the planet.

Okay, squeeze out 1123 5.3.6(a) is a good plan, forwarders can
try SMTPCR to make sure that what they got is not forged.  Bye

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 23 Jan 2006 18:38:15 +0100

>     flaming hoops as per current methodology

I believe I suggested almost the same mechanism almost exactly a year
ago in response to ISACS:
http://www.mhonarc.org/archive/html/ietf-asrg/2005-01/msg00078.html

It was pretty much ignored then. Maybe I should just implement it and
see how it works.

	hp

-- 
   _  | Peter J. Holzer    | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR       | geeignet sind, um sich was zu merken.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Holger Lembke in dan-am
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chris Callahan <[email-masked]>
Date: Tue, 24 Jan 2006 08:46:56 -0800 (PST)

> type the text from an image into another input field.

Perhaps from a departmental system or some such, but definitely not from
the central campus mail servers. We *do*, however, hand back these:

reject=550 5.7.1 Your mail server has been marked as sending spam. Visit
http://email.ucdavis.edu/rbl/index.php?ip=$&{client_addr} for more
information

to a lucky few.

Each night a script trawls our mail logs, and any IP which has handed
off to us more than 20 messages, of which more than 85% were tagged by
SpamAssassin, is added to our local RBL. Subsequent connection attempts
by a listed IP are met with the message above, which points people to
our RBL delisting request form.

As an aside, entries only reside in our RBL database for 60 days and are
then purged. ATM, we have > 26,500 entries; we've only received a total
of 338 delisting requests *total* since we implemented the blocking list
at the beginning of June. We currently reject 80,000-100,000 connections
per day based on the contents of our RBL.

There's no way we'd ever implement any C/R-like system on the central
servers.

-C
--
#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!#!
Chris Callahan - UCD Information Technology - [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"[T]he most important point being debated here today is whether
governments have the right to intrude on the privacy of their
citizens in such a way that citizens ultimately cannot have a
private conversation. I should be able to whisper in your ear,
even if your ear is a thousand kilometers away."  --Philip Zimmerman