Re: RFC 5321bis / 2821ter
Alessandro Vesely <vesely@tana.it> Sat, 31 January 2009 18:08 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VI8VLa052211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 11:08:31 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VI8VdB052210; Sat, 31 Jan 2009 11:08:31 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VI8JmH052194 for <ietf-smtp@imc.org>; Sat, 31 Jan 2009 11:08:30 -0700 (MST) (envelope-from vesely@tana.it)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 31 Jan 2009 19:08:18 +0100 id 00000000005DC031.0000000049849392.000012B3
Message-ID: <49849391.6000805@tana.it>
Date: Sat, 31 Jan 2009 19:08:17 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: John C Klensin <john+smtp@jck.com>
CC: ietf-smtp@imc.org
Subject: Re: RFC 5321bis / 2821ter
References: <4979D903.1060705@pscs.co.uk> <E5EF288BD222F5BA20C735BD@PST.JCK.COM> <497980AA.2060706@es2eng.com> <C4ZHRHThnSMjwwDOZ03z0w.md5@lochnagar.oryx.com> <4979B5F2.9010102@pscs.co.uk> <WBwvOp9JIdw2SWc1HYscRg.md5@lochnagar.oryx.com> <4979D903.1060705@pscs.co.uk> <5.2.1.1.0.20090123140212.03ed3fb0@plus.pop.mail.yahoo.com> <51104ACCD26E8167A1B3981E@PST.JCK.COM> <497D8756.5030306@pscs.co.uk> <alpine.LSU.2.00.0901261913140.4795@hermes-2.csi.cam.ac.uk> <497ED51D.9040407@pscs.co.uk> <497EE0EA.6080704@tana.it> <497EEB01.8060300@pscs.co.uk> <497F41FB.7060101@tana.it> <497F4765.6070109@pscs.co.uk> <497F7058.90109@santronics.com> <498025E0.7080802@pscs.co.uk> <49809046.101@santronics.com> <49816FD7.1040609@pscs.co.uk> <4981CB21.7080801@tana.it> <329705CBE49F16B7218F4E32@PST.JCK.COM> <498328A4.5010408@tana.it> <F83B070CD2862483C2400938@PST.JCK.COM>
In-Reply-To: <F83B070CD2862483C2400938@PST.JCK.COM>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
John C Klensin wrote: > --On Friday, January 30, 2009 17:19 +0100 Alessandro Vesely > <vesely@tana.it> wrote: >> Not being an anonymous operator involves choosing an ISP that >> does reverse DNS delegations, and registering a domain >> directly rather than through a whois-privacy-enhanced >> registrar. > > Thank you for finally clarifying what you (and probably others) > meant by "non-anonymous operator" and "verifiable domain name". > My personal opinion and answer to your question is that, from a > protocol standpoint, it is undesirable to try to require a > higher standard for the EHLO argument that resolvability of the > domain name -- resolvability to _something_. The status of the > domain registration, whether it is "privacy enhanced" or not, > etc., are reasonable matters for local policy, but not for the > SMTP protocol. "Resolvability to anything" obviously has an obscure meaning. Voluntarily disclosing one's identification, through proper [r]DNS registrations, is useful for conveying good intentions. For example, it makes it easier to register with Hotmail/Live. (By giving up its own anonymity, an ESP can shield its users', to some extent.) I agree this pertains to local policies. The principle that only subscribers are enabled to send, which works for mailing lists, has no counterpart in SMTP. On an ethical configurator, I'd opt for accepting mail only from domains that usually listen on port 25, rather than (or in addition to) non-anonymity. Would this principle be reasonable for VHLO? Would it lock out zombies? > If someone can notice that you are supporting > anonymous senders (typically an operational or political > determination, not a protocol one) and make you disclose their > identities with penalties including being shut down if you do > not, then there is no operational anonymity at least vis-a-vis > whomever can compel you in that way. I looked for an anonymous remailer, but couldn't find one. (OK, I didn't search very hard.) On some sites, I found declarations that they discontinued operations because of abuse, not governmental shut down. Does abuse hurt small and medium ESPs more than large ones? I tend to think that giant providers have more bargaining power, also w.r.t. one another. Current developments of FBL and ARF apparently confirm that small ESPs may be going to experience some disadvantages when competing with such established giants. The most flagrant case of email tracing I know of is that of Shi Tao (http://en.wikipedia.org/wiki/Shi_Tao) who is serving a 10 years sentence for sending one message, after Yahoo "practically led the police to his door" -in the words of Tom Lantos. Browsing through various associations' opinions, it is easy to find concerns about non democratic governments and transnational corporations getting into agreements with them. I don't want to imply that small postmasters are more valorous, although some may. However, it is certainly more difficult for an institution to control each small operator than to get in touch with a few big ones. IMHO, consigning email to transnational corporations would ultimately attain even less support for those situations "in which strong anonymity and privacy are really important" -in your words.
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: RFC 5321bis / 2821ter David MacQuigg
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Hector Santos
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Hector Santos
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter Hector Santos
- Re: RFC 5321bis / 2821ter Mark Andrews
- Re: RFC 5321bis / 2821ter SM
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: Submission identifiers John Leslie
- Re: RFC 5321bis / 2821ter Hector Santos
- Re: RFC 5321bis / 2821ter Alex van den Bogaerdt
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Tony Finch
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Tony Finch
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: Submission identifiers Paul Smith
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: Submission identifiers John C Klensin
- Re: Submission identifiers Steve Atkins
- Re: Submission identifiers David MacQuigg
- Re: RFC 5321bis / 2821ter Tony Finch
- Re: RFC 5321bis / 2821ter Jeff Macdonald
- Re: RFC 5321bis / 2821ter Jeff Macdonald
- Re: RFC 5321bis / 2821ter SM
- Re: Submission identifiers Alessandro Vesely
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: Submission identifiers John Leslie
- Re: RFC 5321bis / 2821ter Steve Atkins
- Re: RFC 5321bis / 2821ter David MacQuigg
- Re: Submission identifiers John C Klensin
- Re: Submission identifiers Alessandro Vesely
- Re: Submission identifiers Arnt Gulbrandsen
- Re: Submission identifiers SM
- Re: Submission identifiers David MacQuigg
- Re: Submission identifiers John C Klensin
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: Submission identifiers Alessandro Vesely
- Re: RFC 5321bis / 2821ter Alex van den Bogaerdt
- Re: RFC 5321bis / 2821ter David MacQuigg
- Re: RFC 5321bis / 2821ter John C Klensin
- Submission identifiers (was: Re: RFC 5321bis / 28… John C Klensin
- Re: RFC 5321bis / 2821ter David MacQuigg
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter John C Klensin
- Re: RFC 5321bis / 2821ter SM
- Re: RFC 5321bis / 2821ter Arnt Gulbrandsen
- Re: RFC 5321bis / 2821ter Matti Aarnio
- Re: RFC 5321bis / 2821ter Arnt Gulbrandsen
- Re: RFC 5321bis / 2821ter Matti Aarnio
- Re: RFC 5321bis / 2821ter Alessandro Vesely
- Re: RFC 5321bis / 2821ter Paul Smith
- Re: RFC 5321bis / 2821ter Arnt Gulbrandsen
- Re: RFC 5321bis / 2821ter Arnt Gulbrandsen
- Re: RFC 5321bis / 2821ter Willie Gillespie
- RFC 5321bis / 2821ter John C Klensin