From kevindd@ama-assn.org Tue Mar 3 08:14:02 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3CD3A677D for ; Tue, 3 Mar 2009 08:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.815 X-Spam-Level: X-Spam-Status: No, score=-43.815 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERslVYcEU4+l for ; Tue, 3 Mar 2009 08:14:01 -0800 (PST) Received: from alrajhibank.com.sa (unknown [189.71.43.226]) by core3.amsl.com (Postfix) with SMTP id 156C03A6953 for ; Tue, 3 Mar 2009 08:13:58 -0800 (PST) To: Subject: Email Handling Opinion Needed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090303161400.156C03A6953@core3.amsl.com> Date: Tue, 3 Mar 2009 08:13:58 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.slickquick.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://slickquick.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 0, B646. 808 Clements Road. London. SE44 9DG

From nermall@amada.com Tue Mar 3 11:23:37 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2842C3A695E for ; Tue, 3 Mar 2009 11:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.229 X-Spam-Level: X-Spam-Status: No, score=-12.229 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjOWgZ3b9FQ3 for ; Tue, 3 Mar 2009 11:23:30 -0800 (PST) Received: from 200-158-51-232.dsl.telesp.net.br (200-158-51-232.dsl.telesp.net.br [200.158.51.232]) by core3.amsl.com (Postfix) with SMTP id B4FCF3A6825 for ; Tue, 3 Mar 2009 11:23:29 -0800 (PST) To: Subject: Invoice from itunes.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090303192329.B4FCF3A6825@core3.amsl.com> Date: Tue, 3 Mar 2009 11:23:29 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B815. 702 Clements Road. London. SE83 3DG

From julian@aimpr.com.tw Tue Mar 3 11:55:31 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350973A6B3E for ; Tue, 3 Mar 2009 11:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.262 X-Spam-Level: X-Spam-Status: No, score=-33.262 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcqT60p3cOOK for ; Tue, 3 Mar 2009 11:55:24 -0800 (PST) Received: from aldeasa.com (unknown [189.72.184.169]) by core3.amsl.com (Postfix) with SMTP id DD90B3A67F9 for ; Tue, 3 Mar 2009 11:55:18 -0800 (PST) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090303195521.DD90B3A67F9@core3.amsl.com> Date: Tue, 3 Mar 2009 11:55:18 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B364. 444 Clements Road. London. SE61 3DG

From lexikonthermometerh@amateurmatch.com Sun Mar 8 21:07:52 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BEF3A6819 for ; Sun, 8 Mar 2009 21:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.988 X-Spam-Level: X-Spam-Status: No, score=-42.988 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knsYW5Lx4DRh for ; Sun, 8 Mar 2009 21:07:46 -0700 (PDT) Received: from afterbeat.co.jp (unknown [124.82.203.137]) by core3.amsl.com (Postfix) with SMTP id 81C353A6403 for ; Sun, 8 Mar 2009 21:07:40 -0700 (PDT) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090309040741.81C353A6403@core3.amsl.com> Date: Sun, 8 Mar 2009 21:07:40 -0700 (PDT)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.aromaboost.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://aromaboost.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B191. 951 Clements Road. London. SE67 6DG

From masa0902@agate.plala.or.jp Mon Mar 9 07:04:01 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557503A68F0 for ; Mon, 9 Mar 2009 07:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgjchkUxowIY for ; Mon, 9 Mar 2009 07:03:55 -0700 (PDT) Received: from pool-72-78-169-127.phlapa.east.verizon.net (pool-72-78-169-84.phlapa.east.verizon.net [72.78.169.84]) by core3.amsl.com (Postfix) with SMTP id 5A59F3A6CA5 for ; Mon, 9 Mar 2009 07:03:12 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090309140313.5A59F3A6CA5@core3.amsl.com> Date: Mon, 9 Mar 2009 07:03:12 -0700 (PDT)

We ship Worldwide! To all countries! To all destinations!

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 8, B045. 814 Clements Road. London. SE36 6DG

From _nifer.ding@ampire.com.tw Wed Mar 11 11:46:02 2009 Return-Path: <_nifer.ding@ampire.com.tw> X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788AD3A6358 for ; Wed, 11 Mar 2009 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.722 X-Spam-Level: X-Spam-Status: No, score=-36.722 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98OT41lXVjCS for ; Wed, 11 Mar 2009 11:46:01 -0700 (PDT) Received: from accordfin.com (unknown [122.161.151.173]) by core3.amsl.com (Postfix) with SMTP id 083813A6B17 for ; Wed, 11 Mar 2009 11:45:58 -0700 (PDT) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090311184600.083813A6B17@core3.amsl.com> Date: Wed, 11 Mar 2009 11:45:58 -0700 (PDT)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.droolaware.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://droolaware.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B243. 428 Clements Road. London. SE89 1DG

From larndt@amilink.com Thu Mar 12 02:44:24 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F053A68F7 for ; Thu, 12 Mar 2009 02:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.885 X-Spam-Level: X-Spam-Status: No, score=-13.885 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e9eSmf-2ues for ; Thu, 12 Mar 2009 02:44:24 -0700 (PDT) Received: from agricoreunited.com (unknown [122.162.132.22]) by core3.amsl.com (Postfix) with SMTP id 6E0143A6403 for ; Thu, 12 Mar 2009 02:44:18 -0700 (PDT) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090312094421.6E0143A6403@core3.amsl.com> Date: Thu, 12 Mar 2009 02:44:18 -0700 (PDT)

We ship Worldwide! To all countries! To all destinations!

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B383. 957 Clements Road. London. SE14 1DG

From lsampaio@agora.com.br Thu Mar 12 13:51:43 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E0C28C110 for ; Thu, 12 Mar 2009 13:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.672 X-Spam-Level: X-Spam-Status: No, score=-18.672 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuadxuN+qveV for ; Thu, 12 Mar 2009 13:51:42 -0700 (PDT) Received: from advpayroll.com (unknown [190.49.204.70]) by core3.amsl.com (Postfix) with SMTP id A228F3A68FD for ; Thu, 12 Mar 2009 13:51:33 -0700 (PDT) To: Subject: Order Shipped -- Order #02952 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090312205136.A228F3A68FD@core3.amsl.com> Date: Thu, 12 Mar 2009 13:51:33 -0700 (PDT)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.tinyideal.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://tinyideal.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 8, B090. 614 Clements Road. London. SE30 8DG

From beepwg-bounces@beepcore.org Fri Mar 13 04:06:49 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39453A6A60 for ; Fri, 13 Mar 2009 04:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SAVELE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfLczq3NbFf7 for ; Fri, 13 Mar 2009 04:06:42 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 47DFB3A694C for ; Fri, 13 Mar 2009 04:06:40 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id DF773781448; Fri, 13 Mar 2009 12:07:08 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.101.196]) by hl27.dinaserver.com (Postfix) with ESMTP id CC77069B688 for ; Fri, 13 Mar 2009 12:06:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 77BA16C00A; Fri, 13 Mar 2009 12:05:13 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBiXaaccxl2P; Fri, 13 Mar 2009 12:05:07 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id 101C86C009; Fri, 13 Mar 2009 12:05:07 +0100 (CET) From: Francis Brosnan Blazquez To: BEEPwg Content-Type: multipart/mixed; boundary="=-jFTX1RHkxr17LPWnn4f2" Organization: Advanced Software Production Line, S.L. Date: Fri, 13 Mar 2009 12:06:21 +0100 Message-Id: <1236942381.17324.180.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Vortex Subject: [beepwg] A couple of features to limit BEEP no reply attack X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: DF773781448.A182D X-DinaScanner-From: beepwg-bounces@beepcore.org --=-jFTX1RHkxr17LPWnn4f2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, I've been working on a couple of features that will allow limiting how BEEP implements some reply requirements that may be used to setup an attack. It would be great to known your opinion about this. Cheers! -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. --=-jFTX1RHkxr17LPWnn4f2 Content-Disposition: attachment; filename=draft-brosnan-beep-limit-close.txt Content-Type: text/plain; name=draft-brosnan-beep-limit-close.txt; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Limiting BEEP no reply attack F. Brosnan Blazquez Advanced Software Production Line, S.L. March 13, 2009 Limiting BEEP no reply attack Abstract This document describes two features for the BEEP [RFC3080] protocol to allow peers to negotiate and control reply time limit for a channel and to enable a BEEP peer to not require all replies to be received to proceed with channel or session close with the intention to limit BEEP no reply attacks. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 2 2. Security motivation . . . . . . . . . . . . . . . . . . . . . . 2 3. Points were a BEEP session may be blocked . . . . . . . . . . . 2 4. Features proposed . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Imposing limits to remote BEEP replies: "reply-limit" . . . 3 4.1.1. Disabling "reply-limit" on channel 0 . . . . . . . . . 5 4.1.2. Activating "reply-limit" feature for user channels . . 5 4.1.3. Measures for "reply-limit" exceeded . . . . . . . . . . 5 4.2. Enabling no reply interactions: "no-reply" . . . . . . . . 6 4.2.1. How applies "no-reply" feature to channel 0 . . . . . . 7 4.2.2. Activating "no-reply" feature . . . . . . . . . . . . . 7 4.3. How "no-reply" and "reply-limit" relate to each other? . . 7 4.4. Does "reply-limit" protect against permanent negative close? . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 5.2. No normative references . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Brosnan Blazquez [Page 1] BEEP close limit Limiting BEEP no reply attack March 2009 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Security motivation Experience with BEEP development shows that its session close (described at [RFC3080], section 2.3.1.3) provides many interesting features, not found in other protocols, like: 1. Providing a way to ensure all content is flushed in both directions, for all channels, before closing the session. 2. The hability to deny a channel or session close, for both peers. However, these features may be used by malicious software to setup an attack based on connecting and then blocking replies causing a BEEP listener to not be able to close a session unless it closes the transport layer (and even in that case, it is not a complete solution). I call this BEEP no reply attack. This document identifies these points and provides two features that allows a BEEP peer to ask or advise it will implement a reply limit and a no reply check during the BEEP session. 3. Points were a BEEP session may be blocked The list of blocking points that may be used to lock a BEEP session is, setting up a BEEP no reply attack: 1. To not reply to a channel start request. Though this may not be a big deal in request/response escenarios where a listener is the only party that may block a channel start request, this problem becomes more apparent when BEEP is used in a full peer to peer environment where not only the listener but the initiator accepts channels to be started. Additionally, not replying to a start request causes all subsequent start or close request to be not handled until previous reply is sent. 2. To not reply to messages received (MSG). In BEEP, any message received (MSG) must be replied (RPY, ERR, ANS..NUL). Not replying causes the remote BEEP peer to "understand" there are pending replies, making impossible to close a BEEP session until these replies are received. In general there are no restriction Brosnan Blazquez [Page 2] BEEP close limit Limiting BEEP no reply attack March 2009 in BEEP to require a reply to every MSG received. It is only required at the close session because all replies (in both directions) must be received so the close process can continue. 3. To not reply to channel or session close request. Due to BEEP definition, any peer may reply at any time to a channel or session close request. That is, a BEEP peer have no time limit imposed to reply (with a negative or afirmative value) to such close request. In the following sections are presented two features and how they are used to solve BEEP no reply attack (BNRA). 4. Features proposed This document proposes the following two features: 1. reply-limit: This feature controls, in seconds, how long a reply can be delayed until a BEEP peer considers a protocol violation so he can close the session. 2. no-reply: This feature controls if a BEEP peer will wait for pending replies. This affects the close session phase, making it more lightweight (from the perspective of requirements to meet) and also improves BEEP protocol by allowing a better fit for one- way notifications (via MSG frame). As a side effect, it also reduces bandwidth consuption by removing those empty RPY usually required. 4.1. Imposing limits to remote BEEP replies: "reply-limit" A BEEP peer may use "reply-limit" feature to limit allowed time under which a reply on a particular channel must take place to avoid a protocol violation. This is specially useful for channel 0, the BEEP session management channel, to ensure BEEP peers are bounded to a time limit to reply to channel start and channel close requests. The idea is to allow system administrators that runs BEEP services to have control over such delay/timeout. To enable "reply-limit" feature a BEEP peer must acknoledge it on session greetings phase as follow: Brosnan Blazquez [Page 3] BEEP close limit Limiting BEEP no reply attack March 2009 L: I: L: RPY 0 0 . 0 145 L: Content-Type: application/beep+xml L: L: L: L: L: END I: RPY 0 0 . 0 78 I: Content-Type: application/beep+xml I: I: I: END Figure 1 A BEEP peer acting in the listener role (L:) receives a connection and sends along with all profiles supported and other features, the "reply-limit" feature with the maximum limit allowed in seconds to reply on channel 0. In this case, the BEEP peer acting as listener sent the following relevant information from previous example: L: The example also shows how it is advised no-reply feature support. This is later used to explain "no-reply" feature. Requesting "reply-limit" feature on greetings have two purposes: 1. To ask remote BEEP peer to acknoledge its support for "reply- limit" feature... 2. ...and to provide the "reply-limit" for channel 0 which is implicitly created during BEEP session setup. Since "reply- limit" is activated on channel start, it is required to provide this initial value in the case channel 0 must be configured. A BEEP peer asking for "reply-limit" support that receives a greetings reply without such feature MAY close the connection (and should log a diagnostic error). A BEEP listener peer asking for "reply-limit" must implicitly activate the timeout counter to close the session if no greetings reply is received within the limit reported. The intention is to also limit half opened BEEP sessions with "reply-limit" activated for Brosnan Blazquez [Page 4] BEEP close limit Limiting BEEP no reply attack March 2009 channel 0. The same applies to tuning operations where a new greetings must be exchanged after transport negotiation (like TLS profile). 4.1.1. Disabling "reply-limit" on channel 0 If the listener does not want to impose a reply limit on channel 0, but needs reply limit support for other profiles it must just acknoledge "reply-limit" feature without any time configuration as follows: L: 4.1.2. Activating "reply-limit" feature for user channels Once both BEEP peers have acknoledge its support for "reply-limit" any peer MAY request a channel start with a reply limit doing as follow: I: MSG 0 1 . 78 130 I: Content-Type: application/beep+xml I: I: I: I: A BEEP peer receiving a channel start request with a "reply-limit" configuration must accept or deny channel creation accepting such limit. In the case the profile can be served but not ensure "reply-limit" asked then the BEEP peer receving the request must deny channel start reporting such error: L: ERR 0 1 . 136 132 L: Content-Type: application/beep+xml L: L: Unable to provide resource requested with "reply-limit" configured L: END 4.1.3. Measures for "reply-limit" exceeded A opened channel with a "reply-limit" configured that has exceeded reply time limit will mean a protocol violation. The BEEP session will be terminated without generating a response and it is recommended that a diagnostic entry be logged. Brosnan Blazquez [Page 5] BEEP close limit Limiting BEEP no reply attack March 2009 The same applies to channel 0, in the case "reply-limit" was activated. If a channel start or channel close request is issued but no reply is received within the limit configured, will mean a protocol violation and the BEEP session must be closed without generating a response. Especial mention to half opened connections where even no greetings reply is received. In such case, the connection must be closed if reply time notified is exceeded. 4.2. Enabling no reply interactions: "no-reply" Problem presented in this section comes from the fact that a set (or the last) MSG issued were not replied causing the channel or session close to wait forever until such reply is received. The problem may be resolved, in some situations, by adding a new BEEP frame type NFN, as proposed by David Kramer [david_nfn]. That would allow placing notifications, like MSG frame, but without requiring a reply. However, this do not solve the problem on escenarios where a request/response pattern is being implemented (where an additional effort is required to correlate query and responses). The feature proposed "no-reply" will allow BEEP peers to notify that they will support creating channel where replies to MSG frame will be not required. This has the following main implications: 1. BEEP peers will still be able to reply to MSG frames. 2. BEEP peers during close channel phase, for a channel with "no- reply" activated, will no require replies to be up to date, that is, replies to outstanding MSG and replies to received MSG frames. The intention behind "no-reply" feature is: 1. To provide a security feature that would protect BEEP servers that must run profiles that perform server-to-client notifications. Because the listener issues a MSG frame to the client, it must be replied to close the session cleanly. This leaves great power to the client side to harm the server by simply not replying. 2. To enhance BEEP interaction by providing a way to perform one-way message notification, because no reply will be required to MSG frame that is sent on a channel with "no-reply" activated. Brosnan Blazquez [Page 6] BEEP close limit Limiting BEEP no reply attack March 2009 4.2.1. How applies "no-reply" feature to channel 0 The "no-reply" feature can't be used for channel 0. "no-reply" feature is only available for application profiles. This feature should also be available for profiles already defined like TLS or SASL, allowing to implement a non-blocking close even in cases where there are pending replies. 4.2.2. Activating "no-reply" feature Once both BEEP peers have announced its support for "no-reply" feature, at the greetings phase (Section 4.1), the feature is activated on channel start as follows: I: MSG 0 1 . 78 130 I: Content-Type: application/beep+xml I: I: I: I: I: END If the remote BEEP peer accepts the channel to be created, "no-reply" behaviour will be assumed for both parties. In the case "no-reply" is not allowed for the profile requested, remote BEEP peer must deny channel creation, replying: L: ERR 0 1 . 136 129 L: Content-Type: application/beep+xml L: L: Unable to provide resource requested with "no-reply" configured L: END 4.3. How "no-reply" and "reply-limit" relate to each other? "no-reply" is a BEEP feature that provides security functions (to allow closing a channel without being blocked by pending replies) and application protocol functions (to allow performing one way message notifications). This means that "no-reply" feature can be used in a trusted environment withtout having security in mind but only creating an application protocol that do not have to reply to each MSG received. In the other hand "reply-limit" have the only intention to restrict the time within exchanges take place, especially over the channel 0, Brosnan Blazquez [Page 7] BEEP close limit Limiting BEEP no reply attack March 2009 so malicious usage can be limited. "reply-limit" makes it possible to take the decision to close a session if the remote BEEP do not reply within the negotiated interval. 4.4. Does "reply-limit" protect against permanent negative close? A kind of attack easy to setup is to always deny all channel (or session) close requests received, making impossible to close a BEEP session. The easy countermeasure is to close the transport in the case a BEEP peer insist in deny closing a session for some tries. However this is not enough because, without "reply-limit" feature, a BEEP peer is allowed to not reply to a close request received. That is, a bad BEEP peer simply have to not reply to a close request to avoid its connection to get closed. By using "reply-limit" feature, a BEEP is sure to receive a reply within period negotiated, allowing to take a decision either because a protocol violation due to time exceeded or because too much negative replies received. 5. References 5.1. Normative References [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. No normative references [david_nfn] "Discussion about async channels for BEEP", 11 2008, . Brosnan Blazquez [Page 8] BEEP close limit Limiting BEEP no reply attack March 2009 Author's Address Francis Brosnan Blazquez Advanced Software Production Line, S.L. C/ Antonio Suarez No10, Edificio Alius A, Despacho 102 Alcala de Henares, Madrid 28802 Madrid Phone: 00 34 91 134 14 22 Email: francis@aspl.es URI: http://www.aspl.es Brosnan Blazquez [Page 9] --=-jFTX1RHkxr17LPWnn4f2-- From beepwg-bounces@beepcore.org Fri Mar 13 05:07:14 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945FB3A6A11 for ; Fri, 13 Mar 2009 05:07:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAvxkpiUuSod for ; Fri, 13 Mar 2009 05:07:08 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 6D1C53A69D4 for ; Fri, 13 Mar 2009 05:07:08 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 4C59D71692B; Fri, 13 Mar 2009 13:07:43 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.101.196]) by hl27.dinaserver.com (Postfix) with ESMTP id B8A3A78FCC6 for ; Fri, 13 Mar 2009 13:07:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 7D1676C00A; Fri, 13 Mar 2009 13:05:49 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyUILSzPbs-E; Fri, 13 Mar 2009 13:05:43 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id 9BB896C009; Fri, 13 Mar 2009 13:05:43 +0100 (CET) From: Francis Brosnan Blazquez To: DEXTER In-Reply-To: <49BA41BC.4070006@gmail.com> References: <1236942381.17324.180.camel@vulcan.aspl.local> <49BA41BC.4070006@gmail.com> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Fri, 13 Mar 2009 13:06:57 +0100 Message-Id: <1236946017.17324.182.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: vortex@lists.aspl.es cc: BEEPwg Subject: [beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 4C59D71692B.4CE31 X-DinaScanner-From: beepwg-bounces@beepcore.org > Hi Francis, Balazs, > I just ran through it quickly, but it sound really great. In the > environment where we use BEEP we had to take care of this "manually" > and > it would be really great if that reply-limit was built in the > protocol. Thanks for your comments! > Balazs > -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From beepwg-bounces@beepcore.org Fri Mar 13 14:31:18 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA6228C0EE for ; Fri, 13 Mar 2009 14:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vclaziOuWrGj for ; Fri, 13 Mar 2009 14:31:17 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id DFB203A6B24 for ; Fri, 13 Mar 2009 14:31:16 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 4C3BF75F4A4; Fri, 13 Mar 2009 22:31:52 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by hl27.dinaserver.com (Postfix) with ESMTP id 4E6B978DE87 for ; Fri, 13 Mar 2009 22:31:37 +0100 (CET) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id BB1E2568DF50; Fri, 13 Mar 2009 14:31:36 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1])A3908280AA; Fri, 13 Mar 2009 14:31:36 -0700 (PDT) X-AuditID: 11807134-ab060bb000000ff0-60-49bad0b8df06 Received: from dkramer.apple.com (dkramer.apple.com [17.224.20.97]) by relay14.apple.com (Apple SCV relay) with ESMTP id 7327A28087; Fri, 13 Mar 2009 14:31:36 -0700 (PDT) Subject: Re: [beepwg] A couple of features to limit BEEP no reply attack Mime-Version: 1.0 (Apple Message framework v1047) Content-Transfer-Encoding: 7bit From: David Kramer Message-Id: <9471C896-E007-4745-8A49-885D51B6B130@apple.com> In-Reply-To: <1236942381.17324.180.camel@vulcan.aspl.local> Date: Fri, 13 Mar 2009 14:31:36 -0700 References: <1236942381.17324.180.camel@vulcan.aspl.local> Content-Type: text/plain; delsp=yes; charset=us-ascii; format=flowed To: Francis Brosnan Blazquez X-Mailer: Apple Mail (2.1047) X-Brightmail-Tracker: AAAAAA== X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-6.599, requerido 6, autolearn=not spam, BAYES_00 -2.60, RCVD_IN_DNSWL_MED -4.00), cc: BEEPwg X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 4C3BF75F4A4.EB08B X-DinaScanner-From: beepwg-bounces@beepcore.org Francis, I read your draft proposal for the reply-limit and no-reply features and have a few questions and comments. First, regarding reply-limit: * The reply-limit feature could be implemented by the library implementing the BEEP protocol. The library could automatically terminate the session whenever it determined that the remote peer was taking too long to reply to requests. Clients using the library could override this timeout value on a per-session and per-channel basis. Can you provide an example showing why it is better to make this a feature of the BEEP protocol instead of just implementing this in the library? * When using reply-limit, if peer A takes longer than the limit to reply, is it considered a protocol violation if peer B doesn't terminate the session? In other words, who's responsibility is it to enforce the reply-limit? Both peers? Or just the receiving peer? Regarding "no-reply": * Because the "no-reply" feature still allows replies, a downside of using "no-reply" instead of NFN messages is that each peer still has to keep track of all of the un-replied-to messages it has sent, in order to verify that each RPY that does arrive has a valid msgno. The peer's memory usage will increase for each message it sends that the remote peer does not reply to. Do you agree that this feature would be unusable in low-memory environments, unless the peer stopped validating the msgno of incoming RPY messages? * The issue you mention about the NFN scheme not supporting correlation between requests and replies was first raised because I suggested that the NFN scheme could be used to implement support for out-of-order replies. As was pointed out to me, and I agree, the application would have to do extra work to correlate these out-of- order replies, which could instead be handled by the msgno value in the frame header if the protocol were changed to allow out of order RPYs. But in the cases where you do not want a reply, this issue does not apply. * The "no-reply" feature seems mis-named. You are not creating a channel in which there are no replies, you are creating a channel in which replies are optional, and the choice is made by the receiver, not the sender. This does not seem like a useful feature to me. I would understand a feature that allowed for a channel on which replies were not allowed at all (eg, it is against the rules to send a RPY when you receive a MSG on the channel) and I would understand a feature that allowed for channel on which the sender specified whether or not a RPY was needed (eg, the sender could send a NFN if it didn't want a RPY, and it could send a MSG if it did want a RPY)... but I don't understand the "no-reply" feature, because it allows the receiver to decide whether or not to respond. Can you provide an example protocol where it is useful to allow the receiving peer the option to decide whether or not it replies? Also, I suggest renaming the feature to "optional-reply". Regarding the over-all goal of limiting BEEP no reply attack: * Anytime a remote peer does not behave the way you want, you have the right to terminate the session. Why is this not sufficient for protecting against the no reply attack? Can't all of this just be implemented by the library? For example, if the client of the library asks to close a channel, and the remote peer refuses, the library could automatically terminate the session -- or it could terminate the session on the third failed attempt -- or whatever policy you want. And if the client of the library sends a message but receives no reply after some timeout, the library could automatically terminate the session. Does any of this have to be part of the protocol? What is the advantage of broadcasting your reply-limit to the other peer? If I tell you my reply-limit is 10, and you take 11 seconds to reply on channel 0, I'll terminate the session. But I could do the same even if I didn't tell you what my reply-limit is, right? What is the difference? * In the case where a peer is is performing the permanent negative close attack on only one channel, I could see the use for a "channel terminate" message that the peer could send over channel 0 to indicate that it would no longer consider valid any messages sent with that channel number. Do you think this would solve the problem effectively? If the remote peer is performing the permanent negative close attach on all channels (or just on channel 0) then terminating the session is already the appropriate response, right? You goal of limiting BEEP no reply attacks is good, but I don't yet see any compelling reasons to make the features you have described part of the protocol. If you can describe some profiles where these features would be useful it might be easier for me to understand the purpose of the features and comment on them more effectively. Thanks, David On Mar 13, 2009, at 4:06 AM, Francis Brosnan Blazquez wrote: > Hi, > > I've been working on a couple of features that will allow limiting how > BEEP implements some reply requirements that may be used to setup an > attack. > > It would be great to known your opinion about this. > > Cheers! > -- > Francis Brosnan Blazquez > Advanced Software Production Line, S.L. > From mjustsendingthisleter@aachen2006.de Fri Mar 13 21:26:48 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6243A6BE9 for ; Fri, 13 Mar 2009 21:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.12 X-Spam-Level: X-Spam-Status: No, score=-45.12 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DE=0.35, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvFybFtrA1Ia for ; Fri, 13 Mar 2009 21:26:48 -0700 (PDT) Received: from sign-4db60e06.pool.einsundeins.de (sign-4db60e06.pool.einsundeins.de [77.182.14.6]) by core3.amsl.com (Postfix) with SMTP id 2F5473A672F for ; Fri, 13 Mar 2009 21:26:46 -0700 (PDT) To: Subject: itunes.com Invoice #23341 From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090314042647.2F5473A672F@core3.amsl.com> Date: Fri, 13 Mar 2009 21:26:46 -0700 (PDT)

Build Maximum MUSCLE, STRENGTH, and POWER!

Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!

Dear beep-archive

Men's Health recommends

	FREE gifts reserved for you: beep-archive@lists.ietf.org
	If you would prefer not to receive future information about special offers from Men's Health, you may Unsubscribe. Customer Service Department, 33 East Minor Street, Emmaus, PA 18098 Copyright, Men's Health

From nixonq@advantagecoaching.com Sat Mar 14 22:52:05 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC413A6912 for ; Sat, 14 Mar 2009 22:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.333 X-Spam-Level: X-Spam-Status: No, score=-10.333 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZB4t7ZGnadB for ; Sat, 14 Mar 2009 22:52:04 -0700 (PDT) Received: from amscowindows.com (unknown [189.7.228.201]) by core3.amsl.com (Postfix) with SMTP id 6FE0F3A67B1 for ; Sat, 14 Mar 2009 22:50:10 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090315055011.6FE0F3A67B1@core3.amsl.com> Date: Sat, 14 Mar 2009 22:50:10 -0700 (PDT)

Dear beep-archive

Men's Health recommends

	FREE gifts reserved for you: beep-archive@lists.ietf.org
	If you would prefer not to receive future information about special offers from Men's Health, you may Unsubscribe. Customer Service Department, 33 East Minor Street, Emmaus, PA 18098 Copyright, Men's Health

From junji.yamano.s@aig.co.jp Sun Mar 15 07:41:53 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64EDF28C0FD for ; Sun, 15 Mar 2009 07:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.429 X-Spam-Level: X-Spam-Status: No, score=-7.429 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNaDvZ+M4CKC for ; Sun, 15 Mar 2009 07:41:52 -0700 (PDT) Received: from agis-group.co.il (200-96-88-216.nhoce701.dsl.brasiltelecom.net.br [200.96.88.216]) by core3.amsl.com (Postfix) with SMTP id 30B683A6403 for ; Sun, 15 Mar 2009 07:41:48 -0700 (PDT) To: Subject: Sales Receipt Amazon From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 090314-0, 14/03/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20090315144150.30B683A6403@core3.amsl.com> Date: Sun, 15 Mar 2009 07:41:48 -0700 (PDT)

Dear beep-archive

Men's Health recommends

	FREE gifts reserved for you: beep-archive@lists.ietf.org
	If you would prefer not to receive future information about special offers from Men's Health, you may Unsubscribe. Customer Service Department, 33 East Minor Street, Emmaus, PA 18098 Copyright, Men's Health

From beepwg-bounces@beepcore.org Sun Mar 15 15:56:51 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0B13A6811 for ; Sun, 15 Mar 2009 15:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.178 X-Spam-Level: *** X-Spam-Status: No, score=3.178 tagged_above=-999 required=5 tests=[BAYES_50=0.001, X_IP=3.177] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyDyT65TYZ3Q for ; Sun, 15 Mar 2009 15:56:50 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 2A0743A68F6 for ; Sun, 15 Mar 2009 15:56:49 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id B9A787579C9; Sun, 15 Mar 2009 23:57:22 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from yx-out-2122.google.com (yx-out-2122.google.com [74.125.44.26]) by hl27.dinaserver.com (Postfix) with ESMTP id 732927579C9 for ; Sun, 15 Mar 2009 23:57:00 +0100 (CET) Received: by yx-out-2122.google.com with SMTP id 33so614063yxl.47 for ; Sun, 15 Mar 2009 15:56:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.6.13 with SMTP id 13mr47119anf.24.1237157819235; Sun, 15 Mar 2009 15:56:59 -0700 (PDT) Date: Sun, 15 Mar 2009 15:56:59 -0700 (PDT) In-Reply-To: <9471C896-E007-4745-8A49-885D51B6B130@apple.com> X-IP: 198.135.207.129 References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> User-Agent: G2/1.0 X-HTTP-Via: 1.1 ACDCISA2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3,gzip(gfe),gzip(gfe) Message-ID: From: Martin Thomson To: beepwg@beepcore.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam (whitelisted), SpamAssassin (not cached, puntaje=0.578, requerido 6, BAYES_00 -2.60, X_IP 3.18), Subject: [beepwg] Re: A couple of features to limit BEEP no reply attack X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: B9A787579C9.64DBD X-DinaScanner-From: beepwg-bounces@beepcore.org I think that David has said almost everything that I was going to. No point me wasting my time reiterating it. One further note on reply-limit that might be related to David's second point: there are no provisions made for round trip time. The serving peer might respond within the specified time, but that time might have elapsed by the time at the client before then, or before the response arrives. Ta, Martin On Mar 14, 8:31=A0am, David Kramer wrote: > Francis, > > I read your draft proposal for the reply-limit and no-reply features =A0 > and have a few questions and comments. > > First, regarding reply-limit: > > * The reply-limit feature could be implemented by the library =A0 > implementing the BEEP protocol. =A0The library could automatically =A0 > terminate the session whenever it determined that the remote peer was =A0 > taking too long to reply to requests. =A0Clients using the library could = =A0 > override this timeout value on a per-session and per-channel basis. =A0 > Can you provide an example showing why it is better to make this a =A0 > feature of the BEEP protocol instead of just implementing this in the =A0 > library? > > * When using reply-limit, if peer A takes longer than the limit to =A0 > reply, is it considered a protocol violation if peer B doesn't =A0 > terminate the session? =A0In other words, who's responsibility is it to = =A0 > enforce the reply-limit? =A0Both peers? =A0Or just the receiving peer? > > Regarding "no-reply": > > * Because the "no-reply" feature still allows replies, a downside of =A0 > using "no-reply" instead of NFN messages is that each peer still has =A0 > to keep track of all of the un-replied-to messages it has sent, in =A0 > order to verify that each RPY that does arrive has a valid msgno. =A0The = =A0 > peer's memory usage will increase for each message it sends that the =A0 > remote peer does not reply to. =A0Do you agree that this feature would = =A0 > be unusable in low-memory environments, unless the peer stopped =A0 > validating the msgno of incoming RPY messages? > > * The issue you mention about the NFN scheme not supporting =A0 > correlation between requests and replies was first raised because I =A0 > suggested that the NFN scheme could be used to implement support for =A0 > out-of-order replies. =A0As was pointed out to me, and I agree, the =A0 > application would have to do extra work to correlate these out-of- > order replies, which could instead be handled by the msgno value in =A0 > the frame header if the protocol were changed to allow out of order =A0 > RPYs. =A0But in the cases where you do not want a reply, this issue does = =A0 > not apply. > > * The "no-reply" feature seems mis-named. =A0You are not creating a =A0 > channel in which there are no replies, you are creating a channel in =A0 > which replies are optional, and the choice is made by the receiver, =A0 > not the sender. =A0This does not seem like a useful feature to me. =A0I = =A0 > would understand a feature that allowed for a channel on which replies = =A0 > were not allowed at all (eg, it is against the rules to send a RPY =A0 > when you receive a MSG on the channel) and I would understand a =A0 > feature that allowed for channel on which the sender specified whether = =A0 > or not a RPY was needed (eg, the sender could send a NFN if it didn't =A0 > want a RPY, and it could send a MSG if it did want a RPY)... but I =A0 > don't understand the "no-reply" feature, because it allows the =A0 > receiver to decide whether or not to respond. =A0Can you provide an =A0 > example protocol where it is useful to allow the receiving peer the =A0 > option to decide whether or not it replies? =A0Also, I suggest renaming = =A0 > the feature to "optional-reply". > > Regarding the over-all goal of limiting BEEP no reply attack: > > * Anytime a remote peer does not behave the way you want, you have the = =A0 > right to terminate the session. =A0Why is this not sufficient for =A0 > protecting against the no reply attack? =A0Can't all of this just be =A0 > implemented by the library? =A0For example, if the client of the library = =A0 > asks to close a channel, and the remote peer refuses, the library =A0 > could automatically terminate the session -- or it could terminate the = =A0 > session on the third failed attempt -- or whatever policy you want. =A0 > And if the client of the library sends a message but receives no reply = =A0 > after some timeout, the library could automatically terminate the =A0 > session. =A0Does any of this have to be part of the protocol? =A0What is = =A0 > the advantage of broadcasting your reply-limit to the other peer? =A0If = =A0 > I tell you my reply-limit is 10, and you take 11 seconds to reply on =A0 > channel 0, I'll terminate the session. =A0But I could do the same even = =A0 > if I didn't tell you what my reply-limit is, right? =A0What is the =A0 > difference? > > * In the case where a peer is is performing the permanent negative =A0 > close attack on only one channel, I could see the use for a "channel =A0 > terminate" message that the peer could send over channel 0 to indicate = =A0 > that it would no longer consider valid any messages sent with that =A0 > channel number. =A0Do you think this would solve the problem =A0 > effectively? =A0If the remote peer is performing the permanent negative = =A0 > close attach on all channels (or just on channel 0) then terminating =A0 > the session is already the appropriate response, right? > > You goal of limiting BEEP no reply attacks is good, but I don't yet =A0 > see any compelling reasons to make the features you have described =A0 > part of the protocol. =A0If you can describe some profiles where these = =A0 > features would be useful it might be easier for me to understand the =A0 > purpose of the features and comment on them more effectively. > > Thanks, > David > > On Mar 13, 2009, at 4:06 AM, Francis Brosnan Blazquez wrote: > > > Hi, > > > I've been working on a couple of features that will allow limiting how > > BEEP implements some reply requirements that may be used to setup an > > attack. > > > It would be great to known your opinion about this. > > > Cheers! > > -- > > Francis Brosnan Blazquez > > Advanced Software Production Line, S.L. > > > > From beepwg-bounces@beepcore.org Mon Mar 16 01:55:01 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB3428C11B for ; Mon, 16 Mar 2009 01:55:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az3PEXS5iqTc for ; Mon, 16 Mar 2009 01:55:00 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 92CAE3A6AAC for ; Mon, 16 Mar 2009 01:55:00 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 759A278870A; Mon, 16 Mar 2009 09:55:35 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.101.196]) by hl27.dinaserver.com (Postfix) with ESMTP id 896D478870A for ; Mon, 16 Mar 2009 09:55:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 12D9D740F8; Mon, 16 Mar 2009 09:52:21 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piCq+7zC+aQd; Mon, 16 Mar 2009 09:52:16 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id 820B974054; Mon, 16 Mar 2009 09:52:16 +0100 (CET) From: Francis Brosnan Blazquez To: "Robert M." =?ISO-8859-1?Q?M=FCnch?= In-Reply-To: References: <1236942381.17324.180.camel@vulcan.aspl.local> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Mon, 16 Mar 2009 09:55:19 +0100 Message-Id: <1237193719.5260.27.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Vortex cc: BEEPwg Subject: [beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 759A278870A.5D430 X-DinaScanner-From: beepwg-bounces@beepcore.org Hi Robert, > Hi Francis, I just read your proposal and I think it's a good addition. > Some comments/remarks: > > 1. reply-limit: I think getting better timeout control not only for > channel 0 but for the other channels as well makes a lot of sense. I > couple of weeks ago I posted a question regarding timeout handling to the > list but got no answer to it. Especially if one want to use BEEP in a P2P > network manner (like implementing CHORD on top of it) it's mandatory to > get timeout information on a connection & channel base. This is because > peers can enter/leave a P2P ring at any time, the network is broken, > you-name-it. The timeout triggers the stabilization round of the P2P ring. Ok. > "A BEEP peer asking for "reply-limit" support that receives a greetings > reply without such feature MAY close the connection (and should log a > diagnostic error)." > > Wouldn't it be better in this case to allow the BEEP peer askining for > "reply-limit" support to further allow to use the send reply-limit on its > side? So, one can "force" timout handling on the initiator side to keep > things up & running. I'm not sure to understand this Robert, I mean, the intention with reply-limit is to protect the BEEP side that start channels and issues MSG frames from being blocked (especially if it is a listener server that initiates exchanges) pretty much like you describe. Can you elaborate on this? > How about a feature to make a counter-proposal on the limit? Example: > Listner sends reply-limit of 5s, the reciever knows that on the current > hardware etc. the maximum time to fullfill a request can be 10s. In this > case a counter proposal of 10s would be sent. The listener is free to > accept or reject the counter-proposal. If it's rejected connection can be > closed or the listern can decide to keep it until the initial reply-delay > is reached. Ok. I'll think about this. Maybe this can be left to be configured by the site administrator. Giving to the client the power to control timeout may be dangerous in situations where the listener receiving the connection issue MSG frames or start channels. > 2. no-reply: Supporting "server-to-client notifications" is a very good > addition too! That's what I use a lot. It allows for a bunch of > push-applications and is IMO one of the strength of BEEP. > > Again I think a fallback to "listern announced that no-reply is required, > client rejects but doesn't close connection, listern is free to decided to > continue assuming no-reply mode" makes sense. I think so. That's why I used MAY rather MUST to leave site administrators and application developers to close or not the connection based on the kind of protocol being developed on top of BEEP. Thanks for your comments Robert! > Just my two cents. -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From mariajose.bochatey@agcba.gov.ar Tue Mar 17 10:54:38 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9946E3A69BF for ; Tue, 17 Mar 2009 10:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.488 X-Spam-Level: X-Spam-Status: No, score=-12.488 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUAljfqA0hjf for ; Tue, 17 Mar 2009 10:54:37 -0700 (PDT) Received: from athedsl-355758.home.otenet.gr (athedsl-348067.home.otenet.gr [85.72.215.65]) by core3.amsl.com (Postfix) with SMTP id 6E4F83A67D1 for ; Tue, 17 Mar 2009 10:54:35 -0700 (PDT) To: Subject: Order Shipped -- Order #99417 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090317175436.6E4F83A67D1@core3.amsl.com> Date: Tue, 17 Mar 2009 10:54:35 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From kullanici@123hikaye.com Wed Mar 18 01:49:53 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B3B3A67FC for ; Wed, 18 Mar 2009 01:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.473 X-Spam-Level: X-Spam-Status: No, score=-43.473 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-gH3hLzY3XU for ; Wed, 18 Mar 2009 01:49:53 -0700 (PDT) Received: from alpina-tourdolomit.com (unknown [122.53.58.48]) by core3.amsl.com (Postfix) with SMTP id EC6F43A69BC for ; Wed, 18 Mar 2009 01:49:49 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090318084950.EC6F43A69BC@core3.amsl.com> Date: Wed, 18 Mar 2009 01:49:49 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From beepwg-bounces@beepcore.org Wed Mar 18 06:10:11 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DFB3A687C for ; Wed, 18 Mar 2009 06:10:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMVjjAHZMwHQ for ; Wed, 18 Mar 2009 06:10:10 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id A1B1C28C16A for ; Wed, 18 Mar 2009 06:10:09 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 07DF27B396E; Wed, 18 Mar 2009 14:10:47 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.183.66]) by hl27.dinaserver.com (Postfix) with ESMTP id 3C6E97B2D10 for ; Wed, 18 Mar 2009 14:10:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 3BB43740F8; Wed, 18 Mar 2009 14:05:26 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5Nd6yT+JnX3; Wed, 18 Mar 2009 14:05:21 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id F240774054; Wed, 18 Mar 2009 14:05:20 +0100 (CET) Subject: Re: [beepwg] A couple of features to limit BEEP no reply attack From: Francis Brosnan Blazquez To: David Kramer In-Reply-To: <9471C896-E007-4745-8A49-885D51B6B130@apple.com> References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 18 Mar 2009 14:10:29 +0100 Message-Id: <1237381829.5260.269.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Vortex cc: BEEPwg X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 07DF27B396E.25733 X-DinaScanner-From: beepwg-bounces@beepcore.org Hi David, > First, regarding reply-limit: > > * The reply-limit feature could be implemented by the library > implementing the BEEP protocol. The library could automatically > terminate the session whenever it determined that the remote peer was > taking too long to reply to requests. Clients using the library could > override this timeout value on a per-session and per-channel basis. > Can you provide an example showing why it is better to make this a > feature of the BEEP protocol instead of just implementing this in the > library? Ok. In general, having a BEEP peer with pending replies is a problem yet not solved. This drives to a situation where users start to doing the only thing that can solve this, assuming session close requirements, that is, to shutdown the session. It is important to note this is a protocol violation. Knowing this, you can think you can implement a per-session or per-channel policy (out of the BEEP context) to take a measure, but, at end, having a BEEP session with only one channel (including 0) with pending replies yields to the same solution, again, you have to shutdown the session (mainly because you'll never fulfill BEEP close requirements in such context). With the time you find people asking "why my app gets blocked on session or channel close?". When you answer to this question people find they have to shutdown the connection to ensure, in every case, they will never be blocked. So, as a general conclusion I find that: 1) All solutions comes to shutdown the session in the case of pending replies. 2) All of them are always activated via timeout. 3) Current solution is a protocol violation. Assuming these factors I find convenient providing a standard API, especially to site administrators, to model the solution that is currently accepted (or at least I think so) rather making all people to go into a creative process (which again, it is a protocol violation). >From the perspective of a general purpose BEEP application server, makes sense providing an API that will provide site administrators with the basis to implement and configure session timeout as currently accepted (based on channel numbers, profiles running on them and their network setup/bandwidth) but within the standard. (Note: I refer to API as the BEEP server side configuration that will be available if reply-limit or a similar feature appears). However, and I think the most important, you shouldn't implement this in the library without being supported by the protocol. I mean, having a BEEP peer that closes connections its a protocol violation. BEEP clearly states you can't do this. However, the feature will allow, under required situation, and supported by the protocol, to close after such timeout, which was previously advised. > * When using reply-limit, if peer A takes longer than the limit to > reply, is it considered a protocol violation if peer B doesn't > terminate the session? In other words, who's responsibility is it to > enforce the reply-limit? Both peers? Or just the receiving peer? I didn't think about this ;-) Assuming "reply-limit" is meanly designed to allow BEEP peer to advice its intention to consider a protocol violation to not reply within a period, I don't find a protocol violation to not proceeding after timeout expiration. I'm not sure what would be the best option for this. Maybe you can provide some insights on how to proceed here. > Regarding "no-reply": > > * Because the "no-reply" feature still allows replies, a downside of > using "no-reply" instead of NFN messages is that each peer still has > to keep track of all of the un-replied-to messages it has sent, in > order to verify that each RPY that does arrive has a valid msgno. The > peer's memory usage will increase for each message it sends that the > remote peer does not reply to. Do you agree that this feature would > be unusable in low-memory environments, unless the peer stopped > validating the msgno of incoming RPY messages? Yes, I agree. "no-reply" only disables channel close requirements. Maybe it is time for a true one-way notification. My intention was never to have one-way notification but a way to protect BEEP listeners against no reply attack. > * The issue you mention about the NFN scheme not supporting > correlation between requests and replies was first raised because I > suggested that the NFN scheme could be used to implement support for > out-of-order replies. As was pointed out to me, and I agree, the > application would have to do extra work to correlate these out-of- > order replies, which could instead be handled by the msgno value in > the frame header if the protocol were changed to allow out of order > RPYs. But in the cases where you do not want a reply, this issue does > not apply. Yes, I agree. > * The "no-reply" feature seems mis-named. You are not creating a > channel in which there are no replies, you are creating a channel in > which replies are optional, and the choice is made by the receiver, > not the sender. This does not seem like a useful feature to me. I > would understand a feature that allowed for a channel on which replies > were not allowed at all (eg, it is against the rules to send a RPY > when you receive a MSG on the channel) and I would understand a > feature that allowed for channel on which the sender specified whether > or not a RPY was needed (eg, the sender could send a NFN if it didn't > want a RPY, and it could send a MSG if it did want a RPY)... but I > don't understand the "no-reply" feature, because it allows the > receiver to decide whether or not to respond. Ok. > Can you provide an > example protocol where it is useful to allow the receiving peer the > option to decide whether or not it replies? As an example we can have all request/response protocols created by people. From my experience with Vortex I find people have little or no interest in having all content flushed in both directions, etc (close requirements). However, they find really useful having a quick way to close the connection, no matter if there are pending replies. In fact, I've announced this draft in the Vortex list and it is having a well reception (especially no-reply feature). >From the perspective of a client requesting for some resource at a listener, it is too hard to wait for all pending replies to outstanding messages. Think about those cases where you want to stop/exit from your client application (no matter pending messages). > Also, I suggest renaming > the feature to "optional-reply". Ok. I see it more appropriate. > Regarding the over-all goal of limiting BEEP no reply attack: > > * Anytime a remote peer does not behave the way you want, you have the > right to terminate the session. I don't think so. BEEP clearly states you can't do this. This is the problem I see. Reducing the issue, you have under the same classification BEEP peers that are just taking long to generate a reply, with BEEP peer not behaving properly. I think you can't apply the same solution for both. > Why is this not sufficient for > protecting against the no reply attack? Can't all of this just be > implemented by the library? For example, if the client of the library > asks to close a channel, and the remote peer refuses, the library > could automatically terminate the session -- or it could terminate the > session on the third failed attempt -- or whatever policy you want. > And if the client of the library sends a message but receives no reply > after some timeout, the library could automatically terminate the > session. Does any of this have to be part of the protocol? I think this is not a technical reason. I find that the solution applied at the end it's the same, that is, shutting down the session. However not providing a solution within the BEEP protocol will leave people with an insane pattern, which is a protocol violation, that is becoming an accepted practice making protocols that requires "patience", like relay servers or central software with agents, to be not practicable (unless the same toolkit is used). > What is > the advantage of broadcasting your reply-limit to the other peer? If > I tell you my reply-limit is 10, and you take 11 seconds to reply on > channel 0, I'll terminate the session. But I could do the same even > if I didn't tell you what my reply-limit is, right? Yes. > What is the > difference? Mainly because you can go closing BEEP session because you find it is more appropriate. This is a protocol violation. Again, one of the BEEP power relay in the fact that peers won't do this. "reply-limit" only seek to enforce BEEP peers, especially on channel 0, to reply to request performed. These replies shouldn't take long assuming they are start and close channel requests. Broadcasting reply-limit is just a notification that you will be implementing such timeout. Without it, remote BEEP peer is allowed to take all the time he wants to process your request, with no limit, and you can't close its session. Doing so, without an advice of any form, is not what BEEP standard says. > * In the case where a peer is is performing the permanent negative > close attack on only one channel, I could see the use for a "channel > terminate" message that the peer could send over channel 0 to indicate > that it would no longer consider valid any messages sent with that > channel number. Do you think this would solve the problem > effectively? If the remote peer is performing the permanent negative > close attach on all channels (or just on channel 0) then terminating > the session is already the appropriate response, right? I think permanent negative attack, especially with public BEEP services used by untrusted peer, have only one solution: to shutdown the session after some tries. At the end, even having such new invalidation message, you will have to also modify what BEEP says about closing a channel, stating that channels "invalidated" are ignored during the close process, which is elaborated form of saying "just close the session". > You goal of limiting BEEP no reply attacks is good, but I don't yet > see any compelling reasons to make the features you have described > part of the protocol. If you can describe some profiles where these > features would be useful it might be easier for me to understand the > purpose of the features and comment on them more effectively. I disagree. I think there are enough reason, at least for "optional-reply". Rather placing some examples, let me summarize with all points: >From my experience with Vortex and hearing people that use it, I perceive "optional-reply" as really useful. The explanation is simply: most of people only want to do request/response protocols/applications and mostly all of them finds annoying current close requirements. In fact, I think most of these people are shutting down connection before closing to avoid any lock issue. It is worth to mention, again, this is an insane pattern, hides bugs (you don't have to face with missing replies, etc) and disables an important part of BEEP, the session close, which is beneficial for the user if properly used. For the case of "reply-limit", I think it is an good attempt to conciliate those profiles that could take advantage of current close requirements as defined by RFC3080 and those protocols that only uses the exchange part of the BEEP protocol. At the end David, I can place some examples but we will both end up saying either "you can close the session via library" or "you can close the session via timeout already notified via reply-limit". "reply-limit" provides a chance to the developer to decide if its protocol cares about replies or not, avoiding the general pattern "in case of doubt, shutdown the session". Not accepting "reply-limit" will imply that the current practice will be applied to all protocols and, as a side effect, will invalidate a complete section from the RFC which describes session close requirements. In the other hand, taking the problem with a different point of view, maybe "reply-limit" is not necessary because nobody cares about close requirements, that is, all people is shutting down the session with no problem at all. Can someone say something about this? Thanks for your comments David. Cheers! > Thanks, > David -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From beepwg-bounces@beepcore.org Wed Mar 18 06:14:08 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1CC3A6B13 for ; Wed, 18 Mar 2009 06:14:08 -0700 (PDT) X-Quarantine-ID: <2nI4rsG+ICM5> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nI4rsG+ICM5 for ; Wed, 18 Mar 2009 06:14:08 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 0A56F3A6AFF for ; Wed, 18 Mar 2009 06:14:08 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 30F947BB198; Wed, 18 Mar 2009 14:14:41 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.183.66]) by hl27.dinaserver.com (Postfix) with ESMTP id 4AA797BAEC1 for ; Wed, 18 Mar 2009 14:14:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 3EA5A740F8; Wed, 18 Mar 2009 14:09:07 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63Z0kEe2IrI9; Wed, 18 Mar 2009 14:09:02 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id 8AFD074054; Wed, 18 Mar 2009 14:09:02 +0100 (CET) Subject: Re: [beepwg] Re: A couple of features to limit BEEP no reply attack From: Francis Brosnan Blazquez To: Martin Thomson In-Reply-To: References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 18 Mar 2009 14:14:11 +0100 Message-Id: <1237382051.5260.273.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Vortex cc: beepwg@beepcore.org X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 30F947BB198.CEEFE X-DinaScanner-From: beepwg-bounces@beepcore.org Hi Martin, > I think that David has said almost everything that I was going to. No > point me wasting my time reiterating it. Ok. > One further note on reply-limit that might be related to David's > second point: there are no provisions made for round trip time. The > serving peer might respond within the specified time, but that time > might have elapsed by the time at the client before then, or before > the response arrives. Though I see your point, I find no easy solution to implement a round-trip discovery extension, which, again, can be blocked in the same way. It is expected that BEEP peers will provide appropriate values for this reply-limit which includes such round-trip delay. Cheers! > Ta, > Martin -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From oudnjmaqgv@alexanderscostumes.com Sat Mar 21 10:54:50 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A6F3A6AF6 for ; Sat, 21 Mar 2009 10:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.06 X-Spam-Level: X-Spam-Status: No, score=-32.06 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmXxv0GEYFFa for ; Sat, 21 Mar 2009 10:54:43 -0700 (PDT) Received: from alicorp.com.pe (unknown [200.69.246.201]) by core3.amsl.com (Postfix) with SMTP id 37CE33A6A06 for ; Sat, 21 Mar 2009 10:54:41 -0700 (PDT) To: beep-archive@lists.ietf.org Subject: Design Your Own Member Card From: "Roger Jones" X-Priority: 1 MIME-Version: 1.0 Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20090321175442.37CE33A6A06@core3.amsl.com> Date: Sat, 21 Mar 2009 10:54:41 -0700 (PDT)

From mreeven@138oakwood.fsnet.co.uk Sun Mar 22 10:04:02 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F9628C257 for ; Sun, 22 Mar 2009 10:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thogJFb6+Bnn for ; Sun, 22 Mar 2009 10:04:01 -0700 (PDT) Received: from 81.203.157.49.dyn.user.ono.com (81.203.157.49.dyn.user.ono.com [81.203.157.49]) by core3.amsl.com (Postfix) with SMTP id 1C46928C190 for ; Sun, 22 Mar 2009 10:03:59 -0700 (PDT) To: Subject: Order Shipped -- Order #74583 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090322170400.1C46928C190@core3.amsl.com> Date: Sun, 22 Mar 2009 10:03:59 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From jnobre@ais-informatique.fr Sun Mar 22 12:06:28 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5E83A6891 for ; Sun, 22 Mar 2009 12:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.449 X-Spam-Level: X-Spam-Status: No, score=-22.449 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7LF6YJSSrNu for ; Sun, 22 Mar 2009 12:06:19 -0700 (PDT) Received: from alalam-tower.com (unknown [189.35.184.43]) by core3.amsl.com (Postfix) with SMTP id 63B4E3A6806 for ; Sun, 22 Mar 2009 12:06:17 -0700 (PDT) To: beep-archive@lists.ietf.org Subject: Save up to 50% From: "Hugh Wheeler" X-Priority: 1 MIME-Version: 1.0 Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20090322190618.63B4E3A6806@core3.amsl.com> Date: Sun, 22 Mar 2009 12:06:17 -0700 (PDT)

18/18/09

CONVINCE HER TO EXPERIMENT MORE

If your wife or girlfriend just lies there during love and you want more action, first ask yourself: Is she loglike outside of the bedroom? Because if she doesn't exercise, stretch, dance—anything—it's going to take some effort to bring out her inner bunny.

Before she can enjoy your body, she has to start enjoying her own. Invite her to go hiking, or buy her a gift certificate for yoga classes. Anything that will get her blood flowing is likely to liven up her sexual M.O. by raising her confidence in her body.

If she's already active yet carnally comatose, try to reconnect with her in a sensual way. Suggest taking a long, soapy shower together or trading full-body rubdowns in bed, and lavish her body with attention. Nothing softens a woman up or turns her on like a little pampering.

Want to mix it up more? Even if she's not into role-playing or video cameras, there are plenty of prudish props that can mimic kink. Grab a spatula and offer to treat her like an omelet. Use a spray bottle to spritz her down.

Countless household items have kinky potential. The trick is to plant the object within reach (or coax her into finding new uses for the kitchen, laundry room, toolshed ...) and make your decision to bring it into play appear totally spontaneous.

xo,
Nicole Beland
The Men's Health Girl Next Door

COUPLES

Handle with Care


	Avoid these relationship mistakes for more

DECODE HER

The Female Coregasm
Yes, it's true: Women can have great ending while working out


	Demystify the coregasm

THE ABS DIET ONLINE
Flat, firm abs made easy
• Workouts designed to fit your schedule, your body, your goals
• Customizable meal plans and no-hassle shopping lists
• Killer tracking tools to chart your progress
• Endless food options (stuff you want to eat)
• Total flexibility: swap, delete or add foods/exercises to your program
Start now!

YOUR PRIVACY RIGHTS | CONTACT US | UNSUBSCRIBE

COPYRIGHT RODALE, INC. 2009
33 East Minor Street, Emmaus, PA 18098, Attn: Customer Service

From katherin@123games.dk Sun Mar 22 13:42:50 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2673D3A6A37 for ; Sun, 22 Mar 2009 13:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.344 X-Spam-Level: X-Spam-Status: No, score=-26.344 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWvr9IToJedm for ; Sun, 22 Mar 2009 13:42:49 -0700 (PDT) Received: from admins.pbkreuzfahrer.de (unknown [88.226.29.154]) by core3.amsl.com (Postfix) with SMTP id DB8823A6908 for ; Sun, 22 Mar 2009 13:42:47 -0700 (PDT) To: Subject: You've received an answer to your question From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090322204247.DB8823A6908@core3.amsl.com> Date: Sun, 22 Mar 2009 13:42:47 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From marm@aldebaran-solar.es Mon Mar 23 04:29:56 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E313A68B2 for ; Mon, 23 Mar 2009 04:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_RU=0.595, HOST_EQ_BROADBND=1.118, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFaZyJohhxLn for ; Mon, 23 Mar 2009 04:29:51 -0700 (PDT) Received: from 95-28-219-197.broadband.corbina.ru (95-28-219-197.broadband.corbina.ru [95.28.219.197]) by core3.amsl.com (Postfix) with SMTP id ABEE43A67F7 for ; Mon, 23 Mar 2009 04:29:49 -0700 (PDT) To: beep-archive@lists.ietf.org Subject: Welcome to our club From: "Truman Leon" X-Priority: 1 MIME-Version: 1.0 Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20090323112950.ABEE43A67F7@core3.amsl.com> Date: Mon, 23 Mar 2009 04:29:49 -0700 (PDT)

18/18/09

CONVINCE HER TO EXPERIMENT MORE

COUPLES

Handle with Care


	Avoid these relationship mistakes for more

DECODE HER

The Female Coregasm
Yes, it's true: Women can have great ending while working out


	Demystify the coregasm

YOUR PRIVACY RIGHTS | CONTACT US | UNSUBSCRIBE

COPYRIGHT RODALE, INC. 2009
33 East Minor Street, Emmaus, PA 18098, Attn: Customer Service

From michael@algonorganics.co.uk Mon Mar 23 09:21:12 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1BF3A68E5 for ; Mon, 23 Mar 2009 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.538 X-Spam-Level: X-Spam-Status: No, score=-5.538 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erYHHfcC0gCX for ; Mon, 23 Mar 2009 09:21:05 -0700 (PDT) Received: from DSL217-132-169-98.bb.netvision.net.il (DSL217-132-169-98.bb.netvision.net.il [217.132.169.98]) by core3.amsl.com (Postfix) with SMTP id 842873A6B6C for ; Mon, 23 Mar 2009 09:21:03 -0700 (PDT) To: Subject: Sales Receipt Amazon From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090323162103.842873A6B6C@core3.amsl.com> Date: Mon, 23 Mar 2009 09:21:03 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From beepwg-bounces@beepcore.org Mon Mar 23 10:58:56 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3163A6BFD for ; Mon, 23 Mar 2009 10:58:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvFia4mkyXy4 for ; Mon, 23 Mar 2009 10:58:55 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 3C3563A6BBF for ; Mon, 23 Mar 2009 10:58:54 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 1C41F7CF207; Mon, 23 Mar 2009 18:59:34 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by hl27.dinaserver.com (Postfix) with ESMTP id 8A3BE7CF47E for ; Mon, 23 Mar 2009 18:59:17 +0100 (CET) X-SEF-Processed: 5_0_0_910__2009_03_23_13_19_17 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 23 Mar 2009 13:19:17 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 12:59:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [beepwg] Re: A couple of features to limit BEEP no reply attack Date: Mon, 23 Mar 2009 12:59:12 -0500 Message-ID: In-Reply-To: <1237382051.5260.273.camel@vulcan.aspl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [beepwg] Re: A couple of features to limit BEEP no reply attack Thread-Index: Acmny4WBF+zMpXAuQhiXESmDvUbRKwECCWpA References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> <1237382051.5260.273.camel@vulcan.aspl.local> From: "Thomson, Martin" To: "Francis Brosnan Blazquez" , "Martin Thomson" X-OriginalArrivalTime: 23 Mar 2009 17:59:12.0623 (UTC) FILETIME=[12AF27F0:01C9ABE1] X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.6, requerido 6, autolearn=not spam, BAYES_00 -2.60, SPF_HELO_PASS -0.00), cc: Vortex cc: beepwg@beepcore.org X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 1C41F7CF207.6014F X-DinaScanner-From: beepwg-bounces@beepcore.org U29ycnkgYWJvdXQgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuLi4NCg0KUlRUIGRpc2NvdmVyeSBp cyBwZXJmb3JtZWQgYnkgZXZlcnkgVENQIHN0YWNrLiAgSXQncyBwYXJ0IG9mIHdvcmtpbmcgb3V0 IHRoZSBuZWNlc3Nhcnkgd2luZG93IHNpemUgdG8gbWF4aW1pemUgdGhyb3VnaHB1dC4gIEkgZG9u J3Qga25vdyBpZiB0aGlzIGluZm9ybWF0aW9uIGlzIG1hZGUgYXZhaWxhYmxlIGJ5IGFueSBUQ1Ag c3RhY2tzLCBidXQgaXQgaXNuJ3QgaW1wb3NzaWJsZSB0byBtZWFzdXJlLiAgRXZlbiBhYm92ZSBU Q1Agd2hlcmUgcmV0cmFuc21pdHMgY291bGQgaW50ZXJmZXJlIGl0cycgcHJvYmFibHkgc3RpbGwg ZG9hYmxlLg0KDQpJJ2Qgc3RpbGwgc2F5IHRoYXQgdGhlIG1haW4gY29uY2VybiBJIGhhdmUgaXMg dGhhdCB5b3VyIGludGVycHJldGF0aW9uIG9mIHdoYXQgY29uc3RpdHV0ZXMgYSAicHJvdG9jb2wg dmlvbGF0aW9uIiBpcyB0b28gbmFycm93IGEgdmlldy4gIE1vcmUgaG9saXN0aWNhbGx5LCBhIGJh ZGx5IGJlaGF2aW5nIHBlZXIgbmVlZHMgdG8gYmUgdHJlYXRlZCBhcyBzdWNoLCByZWdhcmRsZXNz IG9mIHdoZXJlIHRoZSBlcnJvcnMgb2NjdXIuICBOaWNldGllcyBsaWtlIHByb3BlciBjaGFubmVs IGFuZCBzZXNzaW9uIGNsb3N1cmUgYXJlIGx1eHVyaWVzIC0gYSBiYWRseSBiZWhhdmluZyBwZWVy IGRvZXMgbm90IGRlc2VydmUgdG8gYmUgdHJlYXRlZCBpbiBzdWNoIGEgY2l2aWxpc2VkIGZhc2hp b24uDQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGJlZXB3Zy1ib3VuY2VzQGJlZXBjb3JlLm9yZyBbbWFpbHRvOmJlZXB3Zy1ib3VuY2Vz QGJlZXBjb3JlLm9yZ10NCj4gT24gQmVoYWxmIE9mIEZyYW5jaXMgQnJvc25hbiBCbGF6cXVleg0K PiBTZW50OiBXZWRuZXNkYXksIDE4IE1hcmNoIDIwMDkgNjoxNCBBTQ0KPiBUbzogTWFydGluIFRo b21zb24NCj4gQ2M6IFZvcnRleDsgYmVlcHdnQGJlZXBjb3JlLm9yZw0KPiBTdWJqZWN0OiBSZTog W2JlZXB3Z10gUmU6IEEgY291cGxlIG9mIGZlYXR1cmVzIHRvIGxpbWl0IEJFRVAgbm8gcmVwbHkN Cj4gYXR0YWNrDQo+IA0KPiBIaSBNYXJ0aW4sDQo+IA0KPiA+IEkgdGhpbmsgdGhhdCBEYXZpZCBo YXMgc2FpZCBhbG1vc3QgZXZlcnl0aGluZyB0aGF0IEkgd2FzIGdvaW5nIHRvLg0KPiBObw0KPiA+ IHBvaW50IG1lIHdhc3RpbmcgbXkgdGltZSByZWl0ZXJhdGluZyBpdC4NCj4gDQo+IE9rLg0KPiAN Cj4gPiBPbmUgZnVydGhlciBub3RlIG9uIHJlcGx5LWxpbWl0IHRoYXQgbWlnaHQgYmUgcmVsYXRl ZCB0byBEYXZpZCdzDQo+ID4gc2Vjb25kIHBvaW50OiB0aGVyZSBhcmUgbm8gcHJvdmlzaW9ucyBt YWRlIGZvciByb3VuZCB0cmlwIHRpbWUuICBUaGUNCj4gPiBzZXJ2aW5nIHBlZXIgbWlnaHQgcmVz cG9uZCB3aXRoaW4gdGhlIHNwZWNpZmllZCB0aW1lLCBidXQgdGhhdCB0aW1lDQo+ID4gbWlnaHQg aGF2ZSBlbGFwc2VkIGJ5IHRoZSB0aW1lIGF0IHRoZSBjbGllbnQgYmVmb3JlIHRoZW4sIG9yIGJl Zm9yZQ0KPiA+IHRoZSByZXNwb25zZSBhcnJpdmVzLg0KPiANCj4gVGhvdWdoIEkgc2VlIHlvdXIg cG9pbnQsIEkgZmluZCBubyBlYXN5IHNvbHV0aW9uIHRvIGltcGxlbWVudCBhDQo+IHJvdW5kLXRy aXAgZGlzY292ZXJ5IGV4dGVuc2lvbiwgd2hpY2gsIGFnYWluLCBjYW4gYmUgYmxvY2tlZCBpbiB0 aGUNCj4gc2FtZQ0KPiB3YXkuDQo+IA0KPiBJdCBpcyBleHBlY3RlZCB0aGF0IEJFRVAgcGVlcnMg d2lsbCBwcm92aWRlIGFwcHJvcHJpYXRlIHZhbHVlcyBmb3IgdGhpcw0KPiByZXBseS1saW1pdCB3 aGljaCBpbmNsdWRlcyBzdWNoIHJvdW5kLXRyaXAgZGVsYXkuDQo+IA0KPiBDaGVlcnMhDQo+IA0K PiA+IFRhLA0KPiA+IE1hcnRpbg0KPiAtLQ0KPiBGcmFuY2lzIEJyb3NuYW4gQmxhenF1ZXogPGZy YW5jaXNAYXNwbC5lcz4NCj4gQWR2YW5jZWQgU29mdHdhcmUgUHJvZHVjdGlvbiBMaW5lLCBTLkwu DQo+IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVz c2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFp biBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRp b24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From jpsapiai@absisconsulting.com Mon Mar 23 18:58:18 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F358B28C1E2 for ; Mon, 23 Mar 2009 18:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.896 X-Spam-Level: X-Spam-Status: No, score=-8.896 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGsuubsUr8tb for ; Mon, 23 Mar 2009 18:58:11 -0700 (PDT) Received: from ppp-58-10-12-136.revip2.asianet.co.th (ppp-58-10-12-233.revip2.asianet.co.th [58.10.12.233]) by core3.amsl.com (Postfix) with SMTP id A599528C0FF for ; Mon, 23 Mar 2009 18:57:47 -0700 (PDT) To: Subject: itunes.com Invoice #89520 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090324015749.A599528C0FF@core3.amsl.com> Date: Mon, 23 Mar 2009 18:57:47 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From jdh@amaonline.com Mon Mar 23 22:54:55 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34A13A6A5D for ; Mon, 23 Mar 2009 22:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.538 X-Spam-Level: X-Spam-Status: No, score=-12.538 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU7V6rFnESFf for ; Mon, 23 Mar 2009 22:54:48 -0700 (PDT) Received: from aessuccess.org (unknown [187.14.9.113]) by core3.amsl.com (Postfix) with SMTP id AAE673A688E for ; Mon, 23 Mar 2009 22:54:47 -0700 (PDT) To: Subject: Sales Receipt Amazon From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090324055447.AAE673A688E@core3.amsl.com> Date: Mon, 23 Mar 2009 22:54:47 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From maureen.mckay@afhe.ualberta.ca Mon Mar 23 23:07:52 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018833A68FB for ; Mon, 23 Mar 2009 23:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.035 X-Spam-Level: X-Spam-Status: No, score=-28.035 tagged_above=-999 required=5 tests=[AWL=-15.438, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znedN1vwywbm for ; Mon, 23 Mar 2009 23:07:45 -0700 (PDT) Received: from ampactire.com (unknown [122.53.127.209]) by core3.amsl.com (Postfix) with SMTP id D68943A6936 for ; Mon, 23 Mar 2009 23:07:42 -0700 (PDT) To: Subject: Order Shipped -- Order #46309 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090324060743.D68943A6936@core3.amsl.com> Date: Mon, 23 Mar 2009 23:07:42 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

Unsubscribe | Your Privacy Rights

Â¿ 2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098

From beepwg-bounces@beepcore.org Tue Mar 24 10:35:27 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369F83A68C1 for ; Tue, 24 Mar 2009 10:35:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Header field occurs more than once: "Cc" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1fLRS0GmWNj for ; Tue, 24 Mar 2009 10:35:26 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 09D853A6B55 for ; Tue, 24 Mar 2009 10:35:25 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 00E2A7CD6D6; Tue, 24 Mar 2009 18:36:08 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.183.66]) by hl27.dinaserver.com (Postfix) with ESMTP id E84007CBD20 for ; Tue, 24 Mar 2009 18:35:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id CD7FD740F8; Tue, 24 Mar 2009 18:32:04 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVHD5G6PoXhN; Tue, 24 Mar 2009 18:32:00 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id EF22C74052; Tue, 24 Mar 2009 18:31:59 +0100 (CET) Subject: RE: [beepwg] Re: A couple of features to limit BEEP no reply attack From: Francis Brosnan Blazquez To: "Thomson, Martin" In-Reply-To: References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> <1237382051.5260.273.camel@vulcan.aspl.local> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Tue, 24 Mar 2009 18:35:32 +0100 Message-Id: <1237916132.27593.169.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Martin Thomson cc: Vortex cc: beepwg@beepcore.org X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 00E2A7CD6D6.7CC77 X-DinaScanner-From: beepwg-bounces@beepcore.org Hi Martin, > Sorry about the delay in responding... ;-) No problem.. > RTT discovery is performed by every TCP stack. It's part of working > out the necessary window size to maximize throughput. I don't know if > this information is made available by any TCP stacks, but it isn't > impossible to measure. Even above TCP where retransmits could > interfere its' probably still doable. Fine. I could place such mention so developers can consider it. However, as you are guessing, such APIs are missing especially on windows (pretty much like TCP maximum negotiated segment size). > I'd still say that the main concern I have is that your interpretation > of what constitutes a "protocol violation" is too narrow a view. More > holistically, a badly behaving peer needs to be treated as such, > regardless of where the errors occur. Niceties like proper channel > and session closure are luxuries - a badly behaving peer does not > deserve to be treated in such a civilised fashion. Ok. Just to point reply-limit is to protect a peer from BNRA especially over channel 0 rather giving especial care to badly behaving peers. After this initial poll I think there are few interest in reply-limit feature. I still think this is a remaining issue to solve and, with some degree, this "silence" confirms close session is not being used at this moment due to problems it carries, especially in an untrusted/public environment. No problem, next issue... ..what about "optional-reply"? What's your opinion about it? Cheers! > Cheers, > Martin -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From m.mazaki@alcm.co.jp Tue Mar 24 19:35:58 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D339428C11F for ; Tue, 24 Mar 2009 19:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.986 X-Spam-Level: X-Spam-Status: No, score=-14.986 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n7C4xMmLnQg for ; Tue, 24 Mar 2009 19:35:48 -0700 (PDT) Received: from UNTRUST.TANIYAMASIAM-FW.TANIYAMASIAM.CO.TH (UNTRUST.TANIYAMASIAM-FW.TANIYAMASIAM.CO.TH [116.68.154.250]) by core3.amsl.com (Postfix) with SMTP id 5A00B3A6B2F for ; Tue, 24 Mar 2009 19:35:45 -0700 (PDT) To: Subject: itunes.com Invoice #26348 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090325023546.5A00B3A6B2F@core3.amsl.com> Date: Tue, 24 Mar 2009 19:35:45 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

From josiepatel@abbeyvideo.co.uk Tue Mar 24 23:39:06 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF383A6863 for ; Tue, 24 Mar 2009 23:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.086 X-Spam-Level: X-Spam-Status: No, score=-19.086 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Cq0TFr9RQmQ for ; Tue, 24 Mar 2009 23:39:05 -0700 (PDT) Received: from 146.pool80-103-160.dynamic.orange.es (146.pool80-103-160.dynamic.orange.es [80.103.160.146]) by core3.amsl.com (Postfix) with SMTP id 9BAE43A6CEA for ; Tue, 24 Mar 2009 23:38:04 -0700 (PDT) To: Subject: Email Handling Opinion Needed From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090325063806.9BAE43A6CEA@core3.amsl.com> Date: Tue, 24 Mar 2009 23:38:04 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

From mcpeek@alum.mit.edu Wed Mar 25 01:02:36 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793823A6C4E for ; Wed, 25 Mar 2009 01:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.589 X-Spam-Level: X-Spam-Status: No, score=-27.589 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EttQnGBTFe+k for ; Wed, 25 Mar 2009 01:02:35 -0700 (PDT) Received: from ampam.com (unknown [122.173.194.16]) by core3.amsl.com (Postfix) with SMTP id 0AFFA3A67FB for ; Wed, 25 Mar 2009 01:02:33 -0700 (PDT) To: Subject: itunes.com Invoice #69226 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090325080234.0AFFA3A67FB@core3.amsl.com> Date: Wed, 25 Mar 2009 01:02:33 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

From beepwg-bounces@beepcore.org Wed Mar 25 02:07:25 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9053A6D1C for ; Wed, 25 Mar 2009 02:07:25 -0700 (PDT) X-Quarantine-ID: <35ClAd4tCjLb> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35ClAd4tCjLb for ; Wed, 25 Mar 2009 02:07:24 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 71FD03A6CF8 for ; Wed, 25 Mar 2009 02:07:24 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 82FE27BE88D; Wed, 25 Mar 2009 10:08:11 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from smtp-ext.ateme.net (smtp-ext.ateme.net [217.167.236.59]) by hl27.dinaserver.com (Postfix) with ESMTP id 60A497B1DC5 for ; Wed, 25 Mar 2009 09:49:49 +0100 (CET) Received: from smtp-in.ateme.net (lserver.ateme.net [172.16.0.1]) by smtp-ext.ateme.net (Postfix) with ESMTP id 0B72C10009; Wed, 25 Mar 2009 09:49:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by smtp-in.ateme.net (Postfix) with ESMTP id E64A33401B; Wed, 25 Mar 2009 09:49:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at lserver.ateme.net Received: from smtp-in.ateme.net ([127.0.0.1]) by localhost (lserver.ateme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeG1aXgNFUF7; Wed, 25 Mar 2009 09:49:46 +0100 (CET) Received: from [172.16.17.215] (pc-470.ateme.net [172.16.17.215]) by smtp-in.ateme.net (Postfix) with ESMTP id B9F693400E; Wed, 25 Mar 2009 09:49:46 +0100 (CET) Message-ID: <49C9F02A.60806@ateme.com> Date: Wed, 25 Mar 2009 09:49:46 +0100 From: Benoit Amiaux User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Francis Brosnan Blazquez References: <1236942381.17324.180.camel@vulcan.aspl.local> In-Reply-To: <1236942381.17324.180.camel@vulcan.aspl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.599, requerido 6, autolearn=not spam, BAYES_00 -2.60), X-Mailman-Approved-At: Wed, 25 Mar 2009 10:08:09 +0100 cc: Vortex cc: BEEPwg Subject: [beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list Reply-To: b.amiaux@ateme.com List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 82FE27BE88D.02BB3 X-DinaScanner-From: beepwg-bounces@beepcore.org Hello, Francis Brosnan Blazquez a écrit : > Hi, > I've been working on a couple of features that will allow limiting how > BEEP implements some reply requirements that may be used to setup an > attack. > It would be great to known your opinion about this. Just a few newbie comments, as an user of the vortex library. - I'm one of the people forced to use connection termination instead of proper connection closure, due to misbehaving peers. It's very easy to trigger just pause one peer process and wait for the other side to wait indefinitely. I think it's doable to implement this on top of the library without changing the BEEP protocol itself, by enforcing, if the user wants it, a timeout on expected replies. It would allow at least, to try to close the connection properly first, instead of always assuming the worst and terminate it. - About the 'no-reply' option, I'm not sure about whether it's a good idea not knowing whether the peer will reply or not. I like the semantics of an 'NFN' message much more. It would save bandwidth and not disrupt the in-order message mechanism per channel. Bye! Benoit Amiaux From beepwg-bounces@beepcore.org Wed Mar 25 03:30:02 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AB43A6938 for ; Wed, 25 Mar 2009 03:30:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr3EMPtWKyK7 for ; Wed, 25 Mar 2009 03:30:01 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 8B3EC3A67FB for ; Wed, 25 Mar 2009 03:30:01 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id A99807D87C8; Wed, 25 Mar 2009 11:30:43 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.101.196]) by hl27.dinaserver.com (Postfix) with ESMTP id 02E0779476B for ; Wed, 25 Mar 2009 11:30:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 62B596C00A; Wed, 25 Mar 2009 11:26:44 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaxPOzWYBqMB; Wed, 25 Mar 2009 11:26:40 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id 6BDE56C009; Wed, 25 Mar 2009 11:26:40 +0100 (CET) Subject: Re: [beepwg] Re: A couple of features to limit BEEP no reply attack From: Francis Brosnan Blazquez To: Martin Thomson In-Reply-To: <3949923e0903241300n6a290829ub9c33aa1954106ce@mail.gmail.com> References: <1236942381.17324.180.camel@vulcan.aspl.local> <9471C896-E007-4745-8A49-885D51B6B130@apple.com> <1237382051.5260.273.camel@vulcan.aspl.local> <1237916132.27593.169.camel@vulcan.aspl.local> <3949923e0903241300n6a290829ub9c33aa1954106ce@mail.gmail.com> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 25 Mar 2009 11:30:22 +0100 Message-Id: <1237977022.20276.51.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Vortex cc: BEEPwg X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: A99807D87C8.58599 X-DinaScanner-From: beepwg-bounces@beepcore.org Hi Martin, > Optional reply might be better solved by creating a new message type, > as David suggested. That way there is no need to have conditional > logic to handle the message. Though a NFY message (one-way notification) would be really interesting, it will not solve the general request/response pattern without requiring the application layer to place some MIME message-id to correlate such interaction. I have no problem with this though this suppose an approach change where it is better accepted using MIME as part of the solution. After giving a try to the problem and perceiving what people say, if this is the preferred direction (having a new one-way notification frame type), which is fine for me, I think proper consequences must be taken on async channels. They won't be required with this new situation. Cheers! -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From beepwg-bounces@beepcore.org Wed Mar 25 03:50:15 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4843A6938 for ; Wed, 25 Mar 2009 03:50:15 -0700 (PDT) X-Quarantine-ID: <37Yuy74q9y1q> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37Yuy74q9y1q for ; Wed, 25 Mar 2009 03:50:14 -0700 (PDT) Received: from hl27.dinaserver.com (hl27.dinaserver.com [82.98.144.26]) by core3.amsl.com (Postfix) with ESMTP id 31B3E3A6894 for ; Wed, 25 Mar 2009 03:50:13 -0700 (PDT) Received: from hl27.dinaserver.com (localhost [127.0.0.1]) by hl27.dinaserver.com (Postfix) with ESMTP id 311C27B7581; Wed, 25 Mar 2009 11:50:54 +0100 (CET) X-Original-To: beepwg@beepcore.org Delivered-To: beepwg-lista@hl27.dinaserver.com Received: from dolphin.aspl.es (unknown [212.170.101.196]) by hl27.dinaserver.com (Postfix) with ESMTP id 8ADA579A23A for ; Wed, 25 Mar 2009 11:50:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by dolphin.aspl.es (Postfix) with ESMTP id 08C886C00A; Wed, 25 Mar 2009 11:46:56 +0100 (CET) X-Virus-Scanned: amavisd-new at dolphin.aspl.es Received: from dolphin.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kukc+a2qshse; Wed, 25 Mar 2009 11:46:52 +0100 (CET) Received: from [192.168.0.132] (barracuda [10.0.0.4]) by dolphin.aspl.es (Postfix) with ESMTP id D2F116C009; Wed, 25 Mar 2009 11:46:51 +0100 (CET) Subject: Re: [beepwg] Re: [Vortex] A couple of features to limit BEEP no reply attack From: Francis Brosnan Blazquez To: b.amiaux@ateme.com In-Reply-To: <49C9F02A.60806@ateme.com> References: <1236942381.17324.180.camel@vulcan.aspl.local> <49C9F02A.60806@ateme.com> Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Wed, 25 Mar 2009 11:50:33 +0100 Message-Id: <1237978233.20276.55.camel@vulcan.aspl.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-DinaScanner: Libre de Virus, Este E-Mail no ha sido analizado. X-DinaScanner-SpamCheck: no es spam, SpamAssassin (not cached, puntaje=-2.499, requerido 6, BAYES_00 -2.60, RDNS_NONE 0.10), cc: Vortex cc: BEEPwg X-BeenThere: beepwg@beepcore.org X-Mailman-Version: 2.1 Precedence: list List-Id: List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , Sender: beepwg-bounces@beepcore.org Errors-To: beepwg-bounces@beepcore.org X-DinaScanner-Information: DinaScanner. Filtro anti-Spam y anti-Virus X-MailScanner-ID: 311C27B7581.E860E X-DinaScanner-From: beepwg-bounces@beepcore.org Hi Benoit, > Just a few newbie comments, as an user of the vortex library. > > - I'm one of the people forced to use connection termination instead > of > proper connection closure, due to misbehaving peers. It's very easy > to > trigger just pause one peer process and wait for the other side to > wait > indefinitely. I think it's doable to implement this on top of the > library without changing the BEEP protocol itself, by enforcing, if > the > user wants it, a timeout on expected replies. It would allow at > least, > to try to close the connection properly first, instead of always > assuming the worst and terminate it. > > - About the 'no-reply' option, I'm not sure about whether it's a good > idea not knowing whether the peer will reply or not. I like the > semantics of an 'NFN' message much more. It would save bandwidth and > not > disrupt the in-order message mechanism per channel. Thanks for your comments Benoit. It seems there are consensus with these two points. Cheers! > Bye! > Benoit Amiaux -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. From nedra_jerry@adp.com Wed Mar 25 09:31:02 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6B83A683A for ; Wed, 25 Mar 2009 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.228 X-Spam-Level: X-Spam-Status: No, score=-30.228 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trvfywVyArpo for ; Wed, 25 Mar 2009 09:31:01 -0700 (PDT) Received: from 89.105.253.180.dn.farlep.net (89.105.253.180.dn.farlep.net [89.105.253.180]) by core3.amsl.com (Postfix) with SMTP id 93F233A6D44 for ; Wed, 25 Mar 2009 09:30:54 -0700 (PDT) To: Subject: itunes.com Invoice #95311 From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090325163057.93F233A6D44@core3.amsl.com> Date: Wed, 25 Mar 2009 09:30:54 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

From mail@advancedmineral.com Wed Mar 25 10:44:16 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D509428C1E3 for ; Wed, 25 Mar 2009 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.154 X-Spam-Level: X-Spam-Status: No, score=-13.154 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV7z92VeHihY for ; Wed, 25 Mar 2009 10:44:13 -0700 (PDT) Received: from alexlee.com (unknown [88.229.254.88]) by core3.amsl.com (Postfix) with SMTP id DF5853A6A9A for ; Wed, 25 Mar 2009 10:44:04 -0700 (PDT) To: Subject: Re: answer 0 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090325174406.DF5853A6A9A@core3.amsl.com> Date: Wed, 25 Mar 2009 10:44:04 -0700 (PDT)

18/18/09

CONVINCE HER TO EXPERIMENT MORE

The Men's Health Girl Next Door

COUPLES

Handle with Care


	Avoid these relationship mistakes for more

DECODE HER

The Female Coregasm
Yes, it's true: Women can have great ending while working out


	Demystify the coregasm

YOUR PRIVACY RIGHTS | CONTACT US | UNSUBSCRIBE

COPYRIGHT RODALE, INC. 2009
33 East Minor Street, Emmaus, PA 18098, Attn: Customer Service

From luciano@accept.com.br Thu Mar 26 00:55:29 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C5E3A68C1 for ; Thu, 26 Mar 2009 00:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.423 X-Spam-Level: X-Spam-Status: No, score=-7.423 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KpMxRHSTkni for ; Thu, 26 Mar 2009 00:55:29 -0700 (PDT) Received: from 121-72-201-184.dsl.telstraclear.net (121-72-201-184.dsl.telstraclear.net [121.72.201.184]) by core3.amsl.com (Postfix) with SMTP id 145283A659B for ; Thu, 26 Mar 2009 00:55:27 -0700 (PDT) To: Subject: Sales Order walmart.com From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090326075528.145283A659B@core3.amsl.com> Date: Thu, 26 Mar 2009 00:55:27 -0700 (PDT)

To your health,

David Zinczenko
Editor-in-Chief

From mvhpvb@allencanning.com Thu Mar 26 05:55:29 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECC73A68B5 for ; Thu, 26 Mar 2009 05:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8z7pMJA69Si for ; Thu, 26 Mar 2009 05:55:25 -0700 (PDT) Received: from 189-3-51-54.poolip.SDR.embratel.net.br (189-3-51-54.poolip.SDR.embratel.net.br [189.3.51.54]) by core3.amsl.com (Postfix) with SMTP id E03023A67A8 for ; Thu, 26 Mar 2009 05:55:20 -0700 (PDT) To: beep-archive@lists.ietf.org Subject: Message number #07302 From: "Estelle Goode" X-Priority: 1 MIME-Version: 1.0 Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20090326125521.E03023A67A8@core3.amsl.com> Date: Thu, 26 Mar 2009 05:55:20 -0700 (PDT)

COUPLES


	Avoid these relationship mistakes for more

DECODE HER


	Demystify the coregasm

YOUR PRIVACY RIGHTS | CONTACT US | UNSUBSCRIBE

COPYRIGHT RODALE, INC. 2009
33 East Minor Street, Emmaus, PA 18098, Attn: Customer Service

From mail@amati.com Thu Mar 26 19:43:25 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E8C3A6876 for ; Thu, 26 Mar 2009 19:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.209 X-Spam-Level: X-Spam-Status: No, score=-5.209 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbh0AtrC2TQU for ; Thu, 26 Mar 2009 19:43:24 -0700 (PDT) Received: from 189-29-43-174-ac.cpe.vivax.com.br (189-29-43-174-ac.cpe.vivax.com.br [189.29.43.174]) by core3.amsl.com (Postfix) with SMTP id 626403A67D9 for ; Thu, 26 Mar 2009 19:43:21 -0700 (PDT) To: Subject: Urgent!Timberlake distraught with grief From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090327024322.626403A67D9@core3.amsl.com> Date: Thu, 26 Mar 2009 19:43:21 -0700 (PDT)

From krista@3megs.com Thu Mar 26 22:11:32 2009 Return-Path: X-Original-To: ietfarch-beep-archive@core3.amsl.com Delivered-To: ietfarch-beep-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306B13A6C21 for ; Thu, 26 Mar 2009 22:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.476 X-Spam-Level: X-Spam-Status: No, score=-11.476 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9rTC6wJZJF1 for