From nobody Tue Jun 3 10:26:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC6C1A0249; Tue, 3 Jun 2014 10:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inPgktdXyKAD; Tue, 3 Jun 2014 10:26:13 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE0A1A023D; Tue, 3 Jun 2014 10:26:12 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so7182036wgh.5 for ; Tue, 03 Jun 2014 10:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qzFfnbC1Gjf0Ki1j0JLLNk/U0M3K7f3DC2DBhfNnR3E=; b=a5suV3onlaQCxrD8XK6o7CshSsoAjswLx8Ux4nn6AUxSDn3jVuEcbHSWKF+cdhZWwK TYlcD/vnjfH9w+omMHTc+KoqrIWiAZaq+ZtSiYQ+E2Sl92pgjkicN0JcpHDeQPuLLpBu 3LOfD2nci09yMQxxCk5BIsQlP3GW2N0zugJqV8pmGYHTgb5nyOm5yzn6z5q7D4JpdOmf G6zefuJum+dxnrB7Vfs8XwC/0YzL9EZD2ZNkBZKkDdhlke2M6f3Co52p0gppYT6E3Zq+ iXf7AtFrvA4R74vtvkG6tDwHJrJURfvgFYbOzX7UOvEVV7DJVakysJAbj7+IxYrsrKHK eISA== MIME-Version: 1.0 X-Received: by 10.180.76.6 with SMTP id g6mr34442341wiw.34.1401816365093; Tue, 03 Jun 2014 10:26:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Tue, 3 Jun 2014 10:26:04 -0700 (PDT) In-Reply-To: <537AD4AD.9030604@bogus.com> References: <1128.1400530188@dash.isi.edu> <537AD4AD.9030604@bogus.com> Date: Tue, 3 Jun 2014 13:26:04 -0400 X-Google-Sender-Auth: rukxFBQFYn8iv3jWlYO1Xr0qvAw Message-ID: From: Phillip Hallam-Baker To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/IbLveR_gSbW4LnzWS0GKqX6-xwc Cc: "dnsop@ietf.org" , perpass , John Heidemann Subject: Re: [perpass] [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 17:26:14 -0000 On Tue, May 20, 2014 at 12:06 AM, joel jaeggli wrote: > On 5/19/14, 1:09 PM, John Heidemann wrote: >> >> Folks, >> >> I believe consensus was that dnsop needs a problem statement about DNS >> privacy before we explore possible solutions. > > If I were to speculate on the basis of the dicussion here and in the > DNSE bof the solution space involves signficant if maybe not dramatic > architecture changes. Absolutely not. I can't see any possibility of a change to the communicating parties or the DNS record formats. My proposal is 17 pages and that is with some pretty extensive examples from the code: http://tools.ietf.org/html/draft-hallambaker-privatedns-00 > I would be happy to support exploration of the problem here and > documents of an according nature, but I imagine us chartering it as a > standalone activity. It is definitely not operations so it has to be a separate activity. Looking at the alternatives on offer I see three approaches: 1) Build on an existing framework e.g. DTLS. 2) Build on a new framework, e.g. SXS-Connect +UYFM that is very similar to DTLS 3) Design a new crypto protocol, e.g. DNS Curve. Now I did start on this three years ago so I have gone through the search space. The reason I chose option 2 is that I didn't find working on top of DTLS saved any time but it introduced a lot of problems. One of the biggest mistakes in TLS and DTLS is that they are built around the assumption that there is a public key handshake at the start of each connection and efficient restart is an afterthought. We have managed to add in Kerberos ticket like options to TLS over the years but they are extensions rather than the core. That said, my current proposal is intended as a starting point, not a definitive edition. SXS-Connect is built on TLS which I believe is the right approach for the client-resolver connection which I see as a one time device initialization step. If we decide that label minimization is not sufficient for the resolver-authoritative step then it would be logical to anchor the trust chain for that exchange in DNSSEC authenticated keys. From nobody Fri Jun 6 17:38:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DE01A020A; Fri, 6 Jun 2014 17:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtmhiUDDo2gD; Fri, 6 Jun 2014 17:38:20 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D642F1A01FF; Fri, 6 Jun 2014 17:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2650; q=dns/txt; s=iport; t=1402101493; x=1403311093; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=601PgnrV1qecACm4Kl4jkyx1krx+FWWoWcCOkF6PzKw=; b=TNCerm9xvL6QahcwPWyKjT+Pe5IW4RnuwQs9s6Abdha/pP8kGPtnyFOh BQHpSfRhwtqwew4QyuLoUOBigIXWbxKFwHb433QFM5KfC/fQprIk3Klrb GgF2wHdIm86pl+I3z/bYs0lruu43b+yeSbes1aebIn+b6Cdb9mV5TdExf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHNeklOtJV2R/2dsb2JhbABZgw1SvSaGa1EBgQUWdYQDAQEBAwEBAQE3NAsFCwsSBiMLJyIOBhMbiB8IDc1AF44kEjMHgyuBFgSKMY9sgUKFNIxOgXyBYB0 X-IronPort-AV: E=Sophos;i="4.98,992,1392163200"; d="scan'208";a="50920338" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 07 Jun 2014 00:38:12 +0000 Received: from [10.21.72.236] ([10.21.72.236]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s570cCLp030788; Sat, 7 Jun 2014 00:38:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dan Wing In-Reply-To: Date: Fri, 6 Jun 2014 17:38:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E5AC03C-E2DE-44F2-9CF5-87FE4A9F3B40@cisco.com> References: <1128.1400530188@dash.isi.edu> <537AD4AD.9030604@bogus.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/ylYV6e5iy5Wn2WMTpGWDJmfTJPM Cc: joel jaeggli , "dnsop@ietf.org" , perpass , John Heidemann Subject: Re: [perpass] [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:38:22 -0000 On Jun 3, 2014, at 10:26 AM, Phillip Hallam-Baker = wrote: > On Tue, May 20, 2014 at 12:06 AM, joel jaeggli = wrote: >> On 5/19/14, 1:09 PM, John Heidemann wrote: >>>=20 >>> Folks, >>>=20 >>> I believe consensus was that dnsop needs a problem statement about = DNS >>> privacy before we explore possible solutions. >>=20 >> If I were to speculate on the basis of the dicussion here and in the >> DNSE bof the solution space involves signficant if maybe not dramatic >> architecture changes. >=20 > Absolutely not. >=20 > I can't see any possibility of a change to the communicating parties > or the DNS record formats. >=20 > My proposal is 17 pages and that is with some pretty extensive > examples from the code: >=20 > http://tools.ietf.org/html/draft-hallambaker-privatedns-00 >=20 >=20 >> I would be happy to support exploration of the problem here and >> documents of an according nature, but I imagine us chartering it as a >> standalone activity. >=20 > It is definitely not operations so it has to be a separate activity. >=20 >=20 > Looking at the alternatives on offer I see three approaches: >=20 > 1) Build on an existing framework e.g. DTLS. > 2) Build on a new framework, e.g. SXS-Connect +UYFM that is very = similar to DTLS > 3) Design a new crypto protocol, e.g. DNS Curve. >=20 > Now I did start on this three years ago so I have gone through the > search space. The reason I chose option 2 is that I didn't find > working on top of DTLS saved any time but it introduced a lot of > problems. >=20 > One of the biggest mistakes in TLS and DTLS is that they are built > around the assumption that there is a public key handshake at the > start of each connection and efficient restart is an afterthought. We > have managed to add in Kerberos ticket like options to TLS over the > years but they are extensions rather than the core. If we required those extensions to be implemented, what's the problem? -d >=20 >=20 > That said, my current proposal is intended as a starting point, not a > definitive edition. SXS-Connect is built on TLS which I believe is the > right approach for the client-resolver connection which I see as a one > time device initialization step. If we decide that label minimization > is not sufficient for the resolver-authoritative step then it would be > logical to anchor the trust chain for that exchange in DNSSEC > authenticated keys. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Sun Jun 8 05:28:34 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2A1A03B9; Sun, 8 Jun 2014 05:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuDeau_SnKTf; Sun, 8 Jun 2014 05:28:30 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E766C1A03AE; Sun, 8 Jun 2014 05:28:29 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so1947867wgg.34 for ; Sun, 08 Jun 2014 05:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Wcv71iU+FzOfQ4YIw0LOl4evjfAWDfXNINE8a7GtKgw=; b=mXlcSVkAHFAxXnlbm9Y6sBzrKszotGVP1GKE5djinbeP4IO25D1x5VCIyLblB2qLl5 pkh6xvam4UJPK3QT1vGFp8NKj26XrQlMaZfXvUZ4zm5Ih3qDG5a9hsLGgiqwH3LFYHPq vVU8IXCeNDaKZ4hKl/SztYun0SqtdIYbeggzvbJqJr5CekKUPj3nodbGnsHwd49t5CJa pyQBmsZIaCiozJdOsEHY/ogWdsABWumvOSyVqnTh1QO48brfJ+7WkGzEFKBlfC0SYYfX Nc36OLbpS+z8gOysiJPZ2y8VYIJLYZ2UpM12yl+dUno2mEIRECxaI0vEZrSKqsN2y7UL PSnw== MIME-Version: 1.0 X-Received: by 10.180.13.139 with SMTP id h11mr20171981wic.34.1402230501329; Sun, 08 Jun 2014 05:28:21 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Sun, 8 Jun 2014 05:28:21 -0700 (PDT) In-Reply-To: <5E5AC03C-E2DE-44F2-9CF5-87FE4A9F3B40@cisco.com> References: <1128.1400530188@dash.isi.edu> <537AD4AD.9030604@bogus.com> <5E5AC03C-E2DE-44F2-9CF5-87FE4A9F3B40@cisco.com> Date: Sun, 8 Jun 2014 08:28:21 -0400 X-Google-Sender-Auth: SHD4YingEnXlg2kHAlGPTP5bIxw Message-ID: From: Phillip Hallam-Baker To: Dan Wing Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/WPAz6qhQBHiGvhMbo2SCHmJVKKo Cc: joel jaeggli , "dnsop@ietf.org" , perpass , John Heidemann Subject: Re: [perpass] [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 12:28:32 -0000 On Fri, Jun 6, 2014 at 8:38 PM, Dan Wing wrote: > > On Jun 3, 2014, at 10:26 AM, Phillip Hallam-Baker wrote: >> One of the biggest mistakes in TLS and DTLS is that they are built >> around the assumption that there is a public key handshake at the >> start of each connection and efficient restart is an afterthought. We >> have managed to add in Kerberos ticket like options to TLS over the >> years but they are extensions rather than the core. > > If we required those extensions to be implemented, what's the problem? > > -d Well first off only IETF folk think that we are in charge of the Internet. The first law of the Internet is "you are so not in charge (for all values of you)" We have tried requiring many things like IPV6 and DNSSEC and it didn't work. And even when it works, it is sloooooooooow. But the second problem is that the ticket approach in TLS is only there as an extension that provides a small performance gain. Which isn't very interesting or valuable. The value of the ticket approach isn't efficiency, its simplicity. Build on the ticket approach from the ground up and build it into everything and I can cut out 80% of the TLS spec AND 90% of IPSEC and support the same functionality. It is possible to buy a turntable for vinyl records with a USB plug on the end to connect to a computer. That provides digital output but the result is nothing like CD which is all digital end to end. Adding tickets to TLS is like sticking a USB plug on an analog device: it provides impedance matching but nothing more. From nobody Mon Jun 9 04:00:56 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FD31A007B for ; Mon, 9 Jun 2014 04:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVfAd69Xu-O1 for ; Mon, 9 Jun 2014 04:00:50 -0700 (PDT) Received: from smtp30.ep.europa.eu (smtp30.ep.europa.eu [136.173.162.208]) by ietfa.amsl.com (Postfix) with ESMTP id 199931A0027 for ; Mon, 9 Jun 2014 04:00:48 -0700 (PDT) Received: from UCEXBWP015.ep.parl.union.eu ([10.127.249.49]) by smtp30.ep.europa.eu (8.14.5/8.14.5) with ESMTP id s59B0gUG017522 for ; Mon, 9 Jun 2014 13:00:42 +0200 Received: from UCEXBWP009.ep.parl.union.eu ([169.254.7.221]) by UCEXBWP015.ep.parl.union.eu ([169.254.2.150]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 13:00:41 +0200 From: JOSEFSSON Erik To: "perpass@ietf.org" Thread-Topic: RFC compliance and the European Parliament Thread-Index: AQHPg9AKMbR5BfMda0GqrCJzC9NHGA== Date: Mon, 9 Jun 2014 11:00:41 +0000 Message-ID: <4B654B63C9A4614EA1F088B2490E8F3A069CEDAE@UCEXBWP009.ep.parl.union.eu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.249.6] Content-Type: multipart/alternative; boundary="_000_4B654B63C9A4614EA1F088B2490E8F3A069CEDAEUCEXBWP009eppar_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/SmGxdgbEt2gFr4My_z2a2G_QgLY Subject: [perpass] RFC compliance and the European Parliament X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 11:00:53 -0000 --_000_4B654B63C9A4614EA1F088B2490E8F3A069CEDAEUCEXBWP009eppar_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I need help from the standards community with regards to RFC-compliance in = the European Parliament. I reach out here because I believe you expect your work on improving the in= ternet will be implemented, maybe in particular by public bodies we hold to= a higher standard wrt transparency than others[0]. In an Access to Documents request the EP just stated that "conformity with = RFC-5321 section 3.9 is by nature outside EP=92s responsibilities" [1]. Do you agree? Are there RFCs which correct implementation would, by nature,= fall within the responsibilities of the EP? I hope this is of sufficient general interest to warrant a question on this= list. Please find a link to our documentation of the particular issue with RFC-53= 21 section 3.9 below[2] Best regards. //Erik [0] http://www.europarl.europa.eu/sides/getDoc.do?pubRef=3D-//EP//TEXT+RULE= S-EP+20140310+RULE-103+DOC+XML+V0//EN&language=3DEN [1] http://www.asktheeu.org/en/request/interoperability_with_the_eps_ma [2] http://pad.epfsug.eu/p/IAG-percent-hack Problem statement: * The mail server of the European Parliament does not allow incoming me= ssages that come from another server, but have a @europarl.europa.eu addres= s in the From: header * The result was that: * email from non-EP addresses would be delivered without a problem, eve= n to people subscribed with an EP address * email from EP addresses would be delivered without a problem to peopl= e subscribed with a non-EP address, but not to people subscribed with an EP= address Solution: * The address rewriting functionality [1] in Exim is used to replace a = From: address of the form username@europarl.europa.eu with the form usernam= e%europarl.europa.eu@epfsug.eu * This is done with a single configuration file: /etc/exim4/conf.d/rewr= ite/90_europarl, whose content is a single line regular expression: * ^([^@]+)@europarl\.europa\.eu $1%europarl.europa.eu@epfsug.eu fF * Additionally, it is necessary to tell Sympa to accept messages from a= ddresses containing the % sign (it normally doesn't) * This is done by modifying the regular expression in line 55 of the fi= le /usr/share/sympa/lib/tools.pm, like this: * from this: my %regexp =3D ('email' =3D> '([\w\-\_\.\/\+\=3D\'\&]+|\".= *\")\@[\w\-]+(\.[\w\-]+)+', * to this: my %regexp =3D ('email' =3D> '([\w\-\_\.\/\+\=3D\'\&\%]+|\= ".*\")\@[\w\-]+(\.[\w\-]+)+', References: [1] http://www.exim.org/exim-html-current/doc/html/spec_html/ch-address= _rewriting.html --_000_4B654B63C9A4614EA1F088B2490E8F3A069CEDAEUCEXBWP009eppar_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I need help from the standards community= with regards to RFC-compliance in the European Parliament.

I reach out here because I believe you expect your work on improving the in= ternet will be implemented, maybe in particular by public bodies we hold to= a higher standard wrt transparency than others[0].

In an Access to Documents request the EP just stated that "conformi= ty with RFC-5321 section 3.9 is by nature outside EP=92s responsibilities&q= uot; [1].

Do you agree? Are there RFCs which correct implementation would, by nature,= fall within the responsibilities of the EP?

I hope this is of sufficient general interest to warrant a question on this= list.

Please find a link to our documentation of the particular issue with RFC-53= 21 section 3.9 below[2]

Best regards.

//Erik

[0] http://www.europarl.europa.eu/sides/getDoc.do?pubRef=3D-//EP//TEXT+RULE= S-EP+20140310+RULE-103+DOC+XML+V0//EN&language=3DEN=
[1] http://www.asktheeu.org/en/request/interoperability_with_the_eps_ma
[2] h= ttp://pad.epfsug.eu/p/IAG-percent-hack


Problem statement:
  • The mail se= rver of the European Parliament does not allow incoming messages that come = from another server, but have a @europarl.europa.eu address in the From: he= ader
  • The result = was that:
  • email from = non-EP addresses would be delivered without a problem, eve= n to people subscribed with an EP address
  • email from = EP addresses would be delivered without a problem to people subscribed with= a non-EP address, but= not to people subscribed with an EP address

Solution:
  • The address= rewriting functionality [1] in Exim is used to replace a From: address of = the form use= rname@europarl.europa.eu with the form use= rname%europarl.europa.eu@epfsug.eu
  • This is don= e with a single configuration file: /etc/exim4/conf.d/rewrite/90_europarl, = whose content is a single line regular expression:
  • ^([^@]+= )@europarl\.europa\.eu $1%europarl.europa.eu@epfsug.eu fF
  • Additionall= y, it is necessary to tell Sympa to accept messages from addresses containi= ng the % sign (it normally doesn't)
  • This is don= e by modifying the regular expression in line 55 of the file /usr/share/sym= pa/lib/tools.pm, like this:
  • from this: = my %regexp =3D ('email' =3D> '([\w\-\_\.\/\+\=3D\'\&]+|\&quo= t;.*\")\@[\w\-]+(\.[\w\-]+)+',
  • to this:&nb= sp;  my %regexp =3D ('email' =3D> '([\w\-\_\.\/\+\=3D\'\&\%= ]+|\".*\")\@[\w\-]+(\.[\w\-]+)+',

References:

--_000_4B654B63C9A4614EA1F088B2490E8F3A069CEDAEUCEXBWP009eppar_--