Subject: [Asrg] Seeking volunteers for C/R documents (was: Washington Pos t: Earthlink to Deploy a Challenge-Response System for )

From: Paul Judge <[email-masked]>
Date: Sat, 10 May 2003 10:05:56 -0400

Yes, a BCP for designing and deploying C/R systems would be useful.
Additionally, a proposal for a C/R protocol would be useful. This would
permit interaction between different C/R systems and allow integration into
MTAs and MUAs.

Does anyone have a set of thoughts in either of these two directions that
they would like to put together and move forward?

> -----Original Message-----
> From: John Fenley [mailto:[email-masked]] 
> Sent: Friday, May 09, 2003 12:16 PM
> To: [email-masked]
> Subject: Re: [Asrg] Washington Post: Earthlink to Deploy a 
> Challenge-Response System for 
> 
> 
> Someone mentioned writing some guidelines for responsible 
> Challenge/Response 
> systems. Any chance we could officially ask Earthlink to hold 
> off deployment 
> for a month so we can get something together to guide them?
> 
> Perhaps even a list of fatal flaws and suggested best 
> practices would help.
> 
> These are my suggestions for a beginning list of problems:
> 1. Avoid infinite loops.
> 2. Allow all Opt-in mail.
> 3. take steps to prevent spammer evolution.
> 4. Provide proof that the challenge is legitimate.
> 5. Avoid simple reply style challenges that are easy to 
> autorespond to. 6. Use generous auto whitelisting. 7. support 
> all types of  identity proofs including new ones. 8. Don't 
> just delete everything that doesn't respond correctly, perhaps 
> reward correct challenges by placing them at the top of the inbox.
> 
> John Fenley
> 
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Sat, 10 May 2003 14:15:38 -0700

On Sat, 10 May 2003 10:05:56 -0400 
Paul Judge <[email-masked]> wrote:

> Additionally, a proposal for a C/R protocol would be useful. This
> would permit interaction between different C/R systems and allow
> integration into MTAs and MUAs.

Given that the response portion and the transport used for the response
(email, web, phone, IM, XML/RPC, other) are unstandardisable, that only
leaves the challenge side.  

Is there anything required by a challenge that's different from a
vacation bot?

> Does anyone have a set of thoughts in either of these two directions
> that they would like to put together and move forward?

For *JUST* C/R, the vacation bot spec seems sufficient.  If you're
trying to glue C/R into another system, like a consent token system,
them I've already written a little on that aspect.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 10 May 2003 19:26:36 -0600 (MDT)

> From: J C Lawrence <[email-masked]>

> ...

I disagree.  From the point of view of the sender of the original
message, a challenge and the required response is not unidirectional
like a `vacation` or "out of office" notice, but like an "opt-in
subscription confirmation."  A standard for SMTP (or SMTP+HTTP)
confirmation of a bulk mail subscription request would surely look
very similar to an email based C/R system underneath the user interfaces.

Note that opt-in subscriptions to bulk mail can involve other than
email for any or all of the three messages (original request,
confirmation request, and confirmation).

I don't recall where subscription confirmations might be documented.
If they are not, then it might be good to produce a single
challenge-response/opt-in document.

By the way, which RFC contains the documentation of what we all know
a "vacation" notice should and should not be?  The only reliable
specification I know of for what it should be is the BSD source.
Where has what it shouldn't be documented, besides in some secret
Outlook specification?  (To be fair, lately I've not seen much of the
Outlook out-of-office noise that plagues the main IETF list).

Vernon Schryver    [email-masked]

Disclaimer:  I'm not a fan of C/R systems, and so should not and am
  not volunteering to push them.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Sat, 10 May 2003 23:02:07 -0400

On Sat, May 10, 2003 at 02:15:38PM -0700, J C Lawrence wrote
> them I've already written a little on that aspect.

  Probably raising my BI on this issue, but here goes...

  1) I am *NOT* a fan of "C/R by default", but I believe that C/R does
have its place.  Specifically, I use a variant of C/R as a safety net in
conjunction with aggressive blocking.  This safety net has given me the
necessary confidence to start using SPEWS.  I divide my email into 4
classes...
     a) whitelist - a small subset of the net is unconditionally accepted
     b) greylist  - the vast majority of the net is accepted if it
                    doesn't flag out via DNSbls or local blocklist rules
     c) blacklist - a small subset of the net is  blocked via DNSbls and
                    other rules.  As part of the 550 reject message, the
                    sender gets a URL on my personal website to a page
                    that lists the current temporary unfiltered email
                    address at which I may be contacted.
     d) blacklist with extreme prejiduce - a small set of CIDRs from
                    which I do not want to hear.  They do not get pointed
                    to my filter bypass page.

     Current C/R systems challenge everybody except whitelisted
addresses.  Given moderately aggressive filtering, I get hardly any spam
from the greylist, so I let it through.

  2) In an effort to bypass spamblocks that check for invalid "From:"
domains, spammers now forge addresses from valid domains.  Occasionally
the forged addresses are real, and an innocent 3rd-party gets deluged
with bounces.  The default C/R method of sending a challenge email would
make this even worse.  That's why I prefer making the challenge part of
an SMTP-stage reject.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric Dean" <[email-masked]>
Date: Sun, 11 May 2003 10:26:08 -0400

Sure, I'm in...it appears we have a small BoF that'll at least document some
of the issues with C/R as well as propose some potential standards

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul
> Judge
> Sent: Saturday, May 10, 2003 10:06 AM
> To: John Fenley; [email-masked]
> Subject: [Asrg] Seeking volunteers for C/R documents (was: Washington
> Post: Earthlink to Deploy a Challenge-Response System for )
>
>
>