From owner-ietf-msgtrk@imc.org Mon Feb 14 08:44:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08987 for ; Mon, 14 Feb 2000 08:44:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA04365 for ietf-msgtrk-bks; Mon, 14 Feb 2000 05:23:11 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04361 for ; Mon, 14 Feb 2000 05:23:09 -0800 (PST) Received: from messagingdirect.com (2-086-edm.dial.worldgate.ca [207.167.2.86]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id GAA23274; Mon, 14 Feb 2000 06:26:21 -0700 Message-ID: <38A80161.DD5B25BA@messagingdirect.com> Date: Mon, 14 Feb 2000 13:21:37 +0000 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lyndon Nerenberg CC: Roland Brand , Message Tracking Working Group Subject: Re: New proposal for the interactive message tracking protocol References: <200001072337.e07Nb0p19023@zappa.esys.ca> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lyndon Nerenberg wrote: > > >> 2. The tracking activity is kept away from the e-mail > >> system, so that an SMTP server cannot be saturated with > >> tracking requests by malicious users. > > But since tracking the message is intimately tied to SMTP AUTH, > I don't see how this could be done (easily) outside of SMTP while > staying inside the framework of SMTP AUTH. That is right. Any protocol that will be used/invented for message tracking must have authentication. Seems like a requirement. > >> > 3. It requires only slight changes in SMTP, namely to > >> generate the logs. > > Alexey> In most cases MTA already generate logs. > > However you cannot assume the MTA generates logs anyplace accessable > to you. I could very easily ship all the logging info to a seperate > write-only log server that the tracking software has no access to. This is a good point, but it doesn't really prove anything. For example, the protocol used for processing tracking requests may run on the same computer where syslog data is stored. > And for popular MTAs that log through syslog(3) (e.g. sendmail), > you cannot trust the log data unless you've secured your entire > syslog environment. There was "secure syslog" BOF in Washington IETF. So sooner ot later the problem will be solved. Alexey From owner-ietf-msgtrk@imc.org Mon Feb 14 18:50:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26597 for ; Mon, 14 Feb 2000 18:50:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25062 for ietf-msgtrk-bks; Mon, 14 Feb 2000 15:34:25 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25058; Mon, 14 Feb 2000 15:34:23 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA00271; Mon, 14 Feb 2000 18:37:05 -0500 (EST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: owner-ietf-msgtrk@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore