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 <waltdnes(_at_)waltdnes(_dot_)org> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg