ietf-asrg
[Top] [All Lists]

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

2006-01-23 00:44:06
Walter Dnes wrote:

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

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).

1) It does not solve all spam
2) It does not make responding to CAPTCHAs easier
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



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg