From discuss-bounces@apps.ietf.org Wed Jun 01 00:41:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdL2W-00048e-A6; Wed, 01 Jun 2005 00:41:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdL2U-00048Y-5T for discuss@megatron.ietf.org; Wed, 01 Jun 2005 00:41:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26740 for ; Wed, 1 Jun 2005 00:41:06 -0400 (EDT) Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdLMD-0002Uw-Dt for discuss@apps.ietf.org; Wed, 01 Jun 2005 01:01:34 -0400 Received: from localhost (klutz [127.0.0.1]) by klutz.cs.utk.edu (Postfix) with ESMTP id CB76A400AD; Wed, 1 Jun 2005 00:41:06 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09912-13; Wed, 1 Jun 2005 00:41:05 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by klutz.cs.utk.edu (Postfix) with ESMTP id 9CF8A40088; Wed, 1 Jun 2005 00:41:04 -0400 (EDT) In-Reply-To: <790C8CAAE968DAD3B0AAD5DE@localhost> References: <01LOSDOYK6BY004Z7L@mauve.mrochek.com> <4298B46C.5080207@ehsco.com> <790C8CAAE968DAD3B0AAD5DE@localhost> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Keith Moore Subject: Re: Finding a working SMTP relayer Date: Wed, 1 Jun 2005 00:40:42 -0400 To: John C Klensin X-Mailer: Apple Mail (2.730) X-Virus-Scanned: by amavisd-new at cs.utk.edu by ClamAV and McAfee X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org, Jacob Palme , Ned Freed , "Eric A. Hall" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org > So the next question is "is there any serious interest in working > on a 'how to find the SMTP relay/submission server appropriate to > the local topological environment'? I'm pretty sure that I wouldn't want to see an SMTP-specific solution developed. As for something more generic, I find myself torn. On one hand, I doubt that it is wise to endorse an architecture that expects apps in general, or SMTP clients in particular, to do different things depending on their location in the network topology. I am of course aware that various kinds of proxies/caches exist and that they are actually useful in corner cases, and that explicit proxies might be better than interception/ implicit/"transparent" proxies. I am also aware that there is increasing pressure (from various sources) for applications to choose "the right" source address, source interface, and destination address (from among one or more of each) in order to operate in the face of routing limitations, filtering, sudden renumbering, limited-scope addresses, etc. But this also seems like a way to add a lot of complexity to applications, and a lot of additional failure modes, for a marginal or dubious gain. If nothing else there is a conflict between the application user's interest and the local network operator's interest. The application user wants to be able to select a submission (or other) server that will serve his interests for authentication, robustness, content conversion, timeliness, data transparency, privacy, etc. The operator of the network to which the user's computer is connected may not serve the sender's interests as well. As long as the operator is only providing pure IP service then there's a limit to how much it can affect the sender's email traffic. But once the operator starts providing other services then the separation of functionality is gone. This intersects with security considerations. I believe we need to be moving toward a layered security architecture, where we don't expect either the end systems or the network to be responsible for security, but instead the end systems, firewalls, border routers, intrusion detectors, etc. all cooperate to implement the intersection of the network's security policy and the user's security policy. This is because in a world where applications are expected to deal with apparently arbitrary constraints on reachability/routing between one point and another in the network, they need to be explicitly told when it is okay to send traffic between two points and when they need to try to overcome limitations in the network (or its addressing, whatever). At any rate, in the near term it seems saner to recommend that networks NOT filter outgoing traffic for the submission service, and to recommend that submission servers require STARTTLS and authentication, than to build a way for a local network to redirect SMTP submissions through a proxy. In the long term a more generic application policy specification might emerge if it's found to be useful. An SMTP-specific mechanism strikes me as suboptimal in both the near- and long-term scenarios. From discuss-bounces@apps.ietf.org Wed Jun 01 01:07:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdLSO-0008C9-Io; Wed, 01 Jun 2005 01:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdLSN-0008C4-TM for discuss@megatron.ietf.org; Wed, 01 Jun 2005 01:07:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28288 for ; Wed, 1 Jun 2005 01:07:54 -0400 (EDT) Received: from goose.ehsco.com ([207.65.203.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdLm8-0003hs-0x for discuss@apps.ietf.org; Wed, 01 Jun 2005 01:28:21 -0400 Received: from [10.29.41.119] (cable5-stm-13.gmpexpress.net [63.147.55.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id BCB453E589; Wed, 1 Jun 2005 00:07:52 -0500 (CDT) Message-ID: <429D42A1.6080008@ehsco.com> Date: Wed, 01 Jun 2005 01:07:45 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ned Freed Subject: Re: Finding a working SMTP relayer References: <01LOSDOYK6BY004Z7L@mauve.mrochek.com> <4298B46C.5080207@ehsco.com> <790C8CAAE968DAD3B0AAD5DE@localhost> <01LOX72COPQE00004T@mauve.mrochek.com> In-Reply-To: <01LOX72COPQE00004T@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org, Jacob Palme X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org On 6/1/2005 12:00 AM, Ned Freed wrote: > The API situation would definitely have to change for serious DHCP > provisioning of applications to be viable. I do see some small signs of > hope, however. For example, in Mac OS X the location manager seems to > be a place where DHCP options and location-specific network application > settings come together. HKLM\System\Current ControlSet\Services\DHCP\Parameters\Options is where the options are stored (and flagged for fetching) in Win2k and higher. That's not really the problem--the problem is that no apps make use of this data (to my knowledge). The only app-level DHCP support I know of was some directory-locator stuff, and that was usually issued through its own DHCP queries (this was until the DHCP socket was permanently bound, which stopped that practice pretty well). As it stands right now, if you want app-level DHCP support, you basically need an agent that will go off and update the application configuration itself. That's mostly on UNIX although there used to be some windows software that did this too (don't remember its name and its dead anyway). >> So the next question is "is there any serious interest in working on >> a 'how to find the SMTP relay/submission server appropriate to the >> local topological environment'? This probably generalizes. E.g., >> if one believes in HTTP caching proxies, finding the right local one >> raises some of the same issues. > > Very good point. These sorts of things definitely belong in the same > category, some of them more so than submit server addresses. Offhand > I'd say the place to start would be an option offering a list of > services and corresponding servers/ports. Further elaboration would be > needed, of course. http://www.ehsco.com/misc/I-Ds/draft-hall-email-srv-01.txt is the latest version of the SRV draft, which I reference here to point out that it has some significant client-side sorting and parsing routines that ought to be considered for reuse in something like DHCP. Another point here is that DHCP isn't necessarily the right choice, and that something like SLP may be more useful simply because it isn't as restrictive to topological considerations. I mean, DHCP isn't just limited to ~where you are on the current topology, but its limited to a subset of topology ~types too. No dialup support, and no access from remote anyway, so you're doubly screwed, and something like SLP could deal with that by being separated from the topology itself and being somewhat independent of topology-related stuff anyway. I've always said that I think it's useful to pursue other kinds of approaches in parallel to the SRV configuration stuff, and I still believe that. Mostly I think this because the market seems to have most clearly said that it wants all of the different configuration services (DHCP, PPP, SRV, ...), and trying to pick just one is short-sighted. My reason for doing SRV first is that its the most needed, IMO, given that it is keyed to user config which seems to be the 80% case. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From discuss-bounces@apps.ietf.org Wed Jun 01 10:25:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdU9v-0004rY-T7; Wed, 01 Jun 2005 10:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdU9u-0004qJ-6O for discuss@megatron.ietf.org; Wed, 01 Jun 2005 10:25:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21207 for ; Wed, 1 Jun 2005 10:25:23 -0400 (EDT) Received: from mxout-04.mxes.net ([205.237.194.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUTj-0006N3-6m for discuss@apps.ietf.org; Wed, 01 Jun 2005 10:45:56 -0400 Received: from [192.168.51.111] (port-213-160-13-186.static.qsc.de [213.160.13.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id B5F30A32DB; Wed, 1 Jun 2005 10:25:22 -0400 (EDT) In-Reply-To: References: <01LOSDOYK6BY004Z7L@mauve.mrochek.com> <4298B46C.5080207@ehsco.com> <790C8CAAE968DAD3B0AAD5DE@localhost> <01LOX72COPQE00004T@mauve.mrochek.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <14d38d4c4480f3668495edcfb644355c@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I; hHtiZ43-RK8s{or'?iELJ; !_Mt2|\hW'VcAn*UR#@; 4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Finding a working SMTP relayer Date: Wed, 1 Jun 2005 16:25:20 +0200 To: Tim Bray X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org +1 - I use SSL'd IMAP and SMTP, and have never had problems yet. Note that this may not be the case with TLS, because some providers will block port 25. AFAIK there isn't a standard port for SMTP-over-SSL; should there be / is there one? BTW, such a service can be found at: http://www.tuffmail.com/ (not affiliated; just a very happy customer) On Jun 1, 2005, at 6:18 AM, Tim Bray wrote: > One of the nice things about working for a big company (Sun in my > case) is that they operate this big honking SMTP server that's > password+SSL-protected and listens on a bunch of different ports. If > I were an indie again, I'd cheerfully pay a couple bucks a month for > such a service; put a choke on it allowing no more than a couple > hundred emails a day and that would stop the spammers. > > I used to do the ssh trick too but this is less work and I've never > been locked out of it once in the last year and a bit, and I'm a > serious gipsy. > > So, is there really a problem? -Tim > > > -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Wed Jun 01 11:02:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUjo-00027L-KR; Wed, 01 Jun 2005 11:02:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUjn-000274-E6 for discuss@megatron.ietf.org; Wed, 01 Jun 2005 11:02:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24269 for ; Wed, 1 Jun 2005 11:02:28 -0400 (EDT) Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdV3a-0008Kd-4x for discuss@apps.ietf.org; Wed, 01 Jun 2005 11:23:01 -0400 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 6E14C8BE5; Wed, 1 Jun 2005 17:02:19 +0200 (CEST) Subject: Re: Finding a working SMTP relayer From: Jeroen Massar To: Mark Nottingham In-Reply-To: <14d38d4c4480f3668495edcfb644355c@mnot.net> References: <01LOSDOYK6BY004Z7L@mauve.mrochek.com> <4298B46C.5080207@ehsco.com> <790C8CAAE968DAD3B0AAD5DE@localhost> <01LOX72COPQE00004T@mauve.mrochek.com> <14d38d4c4480f3668495edcfb644355c@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ppRY2B12neBmyPsqNLF5" Organization: Unfix Date: Wed, 01 Jun 2005 17:02:15 +0200 Message-Id: <1117638135.25653.21.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org --=-ppRY2B12neBmyPsqNLF5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-06-01 at 16:25 +0200, Mark Nottingham wrote: > +1 - I use SSL'd IMAP and SMTP, and have never had problems yet. >=20 > Note that this may not be the case with TLS, because some providers=20 > will block port 25. AFAIK there isn't a standard port for=20 > SMTP-over-SSL; should there be / is there one? There is: $ grep smtp /etc/services=20 smtp 25/tcp mail ssmtp 465/tcp smtps # SMTP over SSL Not that the latter is an 'official' port according to IANA, but everything that does SMTP-SSL uses it. But as you are only _submitting_ mail, use the Message Submission standard (RFC2476) which goes over 587 and defaults to requiring authentication and SSL. Greets, Jeroen --=-ppRY2B12neBmyPsqNLF5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCnc33KaooUjM+fCMRAgvYAJ4ld4l3yKKLUH7AZ5ET2qwjcj4kzgCglnrk BSpoPpgLVQi/TamQjgOgVzU= =PPTb -----END PGP SIGNATURE----- --=-ppRY2B12neBmyPsqNLF5-- From discuss-bounces@apps.ietf.org Wed Jun 01 11:10:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUrK-0000I4-8K; Wed, 01 Jun 2005 11:10:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUrJ-0000Gv-O2 for discuss@megatron.ietf.org; Wed, 01 Jun 2005 11:10:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25108 for ; Wed, 1 Jun 2005 11:10:15 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdVB8-0000IO-R1 for discuss@apps.ietf.org; Wed, 01 Jun 2005 11:30:48 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j51FA7ql017843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2005 08:10:08 -0700 Received: from [192.168.1.103] (c-67-170-101-104.hsd1.wa.comcast.net [67.170.101.104]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j51FA5Yx018159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jun 2005 08:10:07 -0700 Date: Wed, 1 Jun 2005 08:10:00 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Mark Nottingham Subject: Re: Finding a working SMTP relayer In-Reply-To: <14d38d4c4480f3668495edcfb644355c@mnot.net> Message-ID: References: <01LOSDOYK6BY004Z7L@mauve.mrochek.com> <4298B46C.5080207@ehsco.com> <790C8CAAE968DAD3B0AAD5DE@localhost> <01LOX72COPQE00004T@mauve.mrochek.com> <14d38d4c4480f3668495edcfb644355c@mnot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org On Wed, 1 Jun 2005, Mark Nottingham wrote: > +1 - I use SSL'd IMAP and SMTP, and have never had problems yet. And along the lines of mass deployability, we are about to require SMTP authentication (with TLS or Kerberos protection) for all submission to our main submission server, for use by all our 200,000 users (though in fairness many of them do submissions to dept-level servers or use central timeshare boxes hence don't worry about config). We've heard of other institutions doing similarly. So we are making the bet that this is usable by all kinds of users. Discoverability would be a big help, though, so I'd really like to see this draft move forward. On the other side of the question, it seems to me increasingly the case that ISPs don't provide SMTP/submission service by default to all those clients that they happen to provide IP connectivity service to; probably for the same reasons that open SMTP relaying is a thing of the past. The use of tunnels and authenticated SMTP, and web-based email access, lets them make this choice. So, bouncing the rubble on this point, I don't think a standard for discovery of topology-local submission service is particularly interesting. > Note that this may not be the case with TLS, because some providers will > block port 25. AFAIK there isn't a standard port for SMTP-over-SSL; > should there be / is there one? No, there shouldn't. Separate-port SSL is simply a bad idea, especially bad for SMTP where public availability of services is important for providing universal email connectivity (for better and worse, of course). We are stuck with it for HTTP, but for all services for which STARTTLS is defined it's much the better approach. The reason in a nutshell is that in-band negotiation is better than port-probing. - RL "Bob" From discuss-bounces@apps.ietf.org Wed Jun 01 11:30:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVAV-0001ph-Nl; Wed, 01 Jun 2005 11:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdVAQ-0001mX-Vk for discuss@megatron.ietf.org; Wed, 01 Jun 2005 11:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26583 for ; Wed, 1 Jun 2005 11:29:59 -0400 (EDT) Received: from exprod6og5.obsmtp.com ([64.18.1.125] helo=psmtp.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdVUF-0001NG-DV for discuss@apps.ietf.org; Wed, 01 Jun 2005 11:50:33 -0400 Received: from source ([192.150.11.134]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Wed, 01 Jun 2005 08:29:58 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id j51FNcBM028682 for ; Wed, 1 Jun 2005 08:23:39 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id j51FTvn2000702 for ; Wed, 1 Jun 2005 08:29:57 -0700 (PDT) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IHE00M0MWDXHK@mailsj-v1.corp.adobe.com> for discuss@apps.ietf.org; Wed, 01 Jun 2005 08:29:57 -0700 (PDT) Received: from MasinterT40 ([130.248.179.84]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IHE00J5RWDW4C@mailsj-v1.corp.adobe.com> for discuss@apps.ietf.org; Wed, 01 Jun 2005 08:29:57 -0700 (PDT) Date: Wed, 01 Jun 2005 08:29:56 -0700 From: Larry Masinter Subject: RE: Finding a working SMTP relayer In-reply-to: <01LOX72COPQE00004T@mauve.mrochek.com> To: discuss@apps.ietf.org Message-id: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcVmXvj5W68mykzEQAO9WyGI+BJf6AAXjfcQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org I will remind you that for "finding HTTP proxy" configuration, it was (is?) not unusual for people to deploy complex, dynamic JavaScript functions that would, for every URL, look at the URL and decide which proxy to use based on the URL, the local connection spot, etc. I don't know how widely this kind of nonsense is required or deployed these days (some of the cases were just because of bad network planning), but I wonder what the high end of the requirements might be. For finding an "appropriate" SMTP relay, might it not depend on the source email address? I mainly use two different email accounts (personal and business), and my choice of SMTP relay depends both on the "From" address as well as my current network location. (I don't want to use my ISP's SMTP server for internal business mail). I'm not sure a simple SLP or DHCP service would do. Larry From discuss-bounces@apps.ietf.org Wed Jun 01 13:59:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXUp-00082V-A1; Wed, 01 Jun 2005 13:59:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdXUm-000813-IP for discuss@megatron.ietf.org; Wed, 01 Jun 2005 13:59:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10306 for ; Wed, 1 Jun 2005 13:59:09 -0400 (EDT) Received: from goose.ehsco.com ([207.65.203.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdXod-0000sY-IP for discuss@apps.ietf.org; Wed, 01 Jun 2005 14:19:44 -0400 Received: from [10.29.41.119] (cable5-stm-13.gmpexpress.net [63.147.55.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 19A8E3E3A2; Wed, 1 Jun 2005 12:59:05 -0500 (CDT) Message-ID: <429DF764.8080105@ehsco.com> Date: Wed, 01 Jun 2005 13:59:00 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Masinter Subject: Re: Finding a working SMTP relayer References: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> In-Reply-To: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org On 6/1/2005 11:29 AM, Larry Masinter wrote: > For finding an "appropriate" SMTP relay, might it not > depend on the source email address? I mainly use two > different email accounts (personal and business), and my > choice of SMTP relay depends both on the "From" address > as well as my current network location. (I don't want > to use my ISP's SMTP server for internal business mail). > > I'm not sure a simple SLP or DHCP service would do. Discovery by email address is the right answer in 80% of the cases, but that other 20% is pretty important. Some of the places where discovery by addr falls down can be pretty painful too. Let's say that you are telco.net with millions of user@telco.net addresses, all across the planet. It's pretty difficult to map that single domain to ~closest/best submission server in a way that is meaningful for dial-up users around the planet, and I can get away with saying that because I've tried to develop a formula for it. In the best case it will fall down only some of the time... Most orgs (the 80%) have a handful of mail servers and users (~90% of orgs are small businesses with less than 100 employees) but that other 20% case is really frightening. They need some other option. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From discuss-bounces@apps.ietf.org Wed Jun 01 14:36:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY50-0007bf-BB; Wed, 01 Jun 2005 14:36:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY4z-0007aM-NT for discuss@megatron.ietf.org; Wed, 01 Jun 2005 14:36:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13418 for ; Wed, 1 Jun 2005 14:36:34 -0400 (EDT) Received: from goose.ehsco.com ([207.65.203.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYOr-0002nH-28 for discuss@apps.ietf.org; Wed, 01 Jun 2005 14:57:10 -0400 Received: from [10.29.41.119] (cable5-stm-13.gmpexpress.net [63.147.55.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 8E3253E3B2 for ; Wed, 1 Jun 2005 13:36:32 -0500 (CDT) Message-ID: <429E0024.6090700@ehsco.com> Date: Wed, 01 Jun 2005 14:36:20 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Re: Finding a working SMTP relayer References: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> <429DF764.8080105@ehsco.com> In-Reply-To: <429DF764.8080105@ehsco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org On 6/1/2005 1:59 PM, Eric A. Hall wrote: > Let's say that you are telco.net with millions of user@telco.net > addresses, all across the planet. It's pretty difficult to map that single > domain to ~closest/best submission server in a way that is meaningful I should adde here that it's difficult to do this with submission servers but nearly impossible with retrieval servers. Figuring out that random user who authenticated on a dial-up pool should be directed towards a specific pop/imap server on the other side of the planet is not at all straightforward. Overcoming the need for static configuration of POP/IMAP servers should be the real goal--submission is a breeze by comparison. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From discuss-bounces@apps.ietf.org Wed Jun 01 14:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYLW-0001rr-5g; Wed, 01 Jun 2005 14:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYLV-0001rm-7Q for discuss@megatron.ietf.org; Wed, 01 Jun 2005 14:53:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15216 for ; Wed, 1 Jun 2005 14:53:37 -0400 (EDT) Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYfM-0003sn-NJ for discuss@apps.ietf.org; Wed, 01 Jun 2005 15:14:13 -0400 Received: from localhost (klutz [127.0.0.1]) by klutz.cs.utk.edu (Postfix) with ESMTP id 6E4A94008B; Wed, 1 Jun 2005 14:53:39 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26625-09; Wed, 1 Jun 2005 14:53:38 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by klutz.cs.utk.edu (Postfix) with ESMTP id 0454940023; Wed, 1 Jun 2005 14:53:38 -0400 (EDT) Date: Wed, 1 Jun 2005 14:53:37 -0400 From: Keith Moore To: "Eric A. Hall" Subject: Re: Finding a working SMTP relayer Message-Id: <20050601145337.18857498.moore@cs.utk.edu> In-Reply-To: <429DF764.8080105@ehsco.com> References: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> <429DF764.8080105@ehsco.com> X-Mailer: Sylpheed version 1.9.9 (GTK+ 2.6.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cs.utk.edu by ClamAV and McAfee X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: LMM@acm.org, moore@cs.utk.edu, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org > Let's say that you are telco.net with millions of user@telco.net > addresses, all across the planet. It's pretty difficult to map that single > domain to ~closest/best submission server in a way that is meaningful for > dial-up users around the planet, and I can get away with saying that > because I've tried to develop a formula for it. Divide the problem into two parts: 1. identifying submission servers that will accept mail for someone who has permission to use that sender address 2. identifying a sufficiently close subset of the servers obtained in #1 #1 is reasonable to solve with SRV records #2 can be solved with a SONAR-like service that accepts a list of server addresses along with some criteria for "close" (e.g. round trip latency, bandwidth, packet loss) and returns a list of reachable servers with proximity metrics One nice thing about splitting the two parts of the problem is that both parts then become reusable for other apps, though the other apps may have different selection criteria or use the information in different ways. From discuss-bounces@apps.ietf.org Wed Jun 01 14:59:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYRJ-0004L0-Iu; Wed, 01 Jun 2005 14:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYRH-0004Kv-QB for discuss@megatron.ietf.org; Wed, 01 Jun 2005 14:59:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15578 for ; Wed, 1 Jun 2005 14:59:36 -0400 (EDT) Received: from goose.ehsco.com ([207.65.203.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYl9-0004Bc-C1 for discuss@apps.ietf.org; Wed, 01 Jun 2005 15:20:12 -0400 Received: from [10.29.41.119] (cable5-stm-13.gmpexpress.net [63.147.55.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 621BA3E60B; Wed, 1 Jun 2005 13:59:36 -0500 (CDT) Message-ID: <429E0588.8090809@ehsco.com> Date: Wed, 01 Jun 2005 14:59:20 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Subject: Re: Finding a working SMTP relayer References: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> <429DF764.8080105@ehsco.com> <20050601145337.18857498.moore@cs.utk.edu> In-Reply-To: <20050601145337.18857498.moore@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org, LMM@acm.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org On 6/1/2005 2:53 PM, Keith Moore wrote: >>Let's say that you are telco.net with millions of user@telco.net >>addresses, all across the planet. It's pretty difficult to map that single >>domain to ~closest/best submission server in a way that is meaningful for >>dial-up users around the planet, and I can get away with saying that >>because I've tried to develop a formula for it. > > Divide the problem into two parts: > > 1. identifying submission servers that will accept mail for someone who > has permission to use that sender address > 2. identifying a sufficiently close subset of the servers obtained in #1 > > #1 is reasonable to solve with SRV records > #2 can be solved with a SONAR-like service that accepts a list of > server addresses along with some criteria for "close" (e.g. round > trip latency, bandwidth, packet loss) and returns a list of reachable > servers with proximity metrics That's pretty much what the currently formula says [see section 4.2 of http://www.ehsco.com/misc/I-Ds/draft-hall-email-srv-01.txt] That's also what the retrieval algorithm mostly does [see section 4.1] but it's a lot more fragile because retrieval mail-stores aren't nearly as location independent as transient submission servers. That's what I was actually referencing in the above comment. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From discuss-bounces@apps.ietf.org Wed Jun 01 15:22:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYnM-0007cT-1O; Wed, 01 Jun 2005 15:22:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdYnL-0007cO-JW for discuss@megatron.ietf.org; Wed, 01 Jun 2005 15:22:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18492 for ; Wed, 1 Jun 2005 15:22:23 -0400 (EDT) Received: from mxout-04.mxes.net ([205.237.194.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdZ7C-0005NA-7c for discuss@apps.ietf.org; Wed, 01 Jun 2005 15:43:00 -0400 Received: from [192.168.51.111] (port-213-160-13-186.static.qsc.de [213.160.13.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CBEF9A32AB; Wed, 1 Jun 2005 15:22:23 -0400 (EDT) In-Reply-To: <1117638135.25653.21.camel@firenze.zurich.ibm.com> References: <01LOSDOYK6BY004Z7L@mauve.mrochek.com> <4298B46C.5080207@ehsco.com> <790C8CAAE968DAD3B0AAD5DE@localhost> <01LOX72COPQE00004T@mauve.mrochek.com> <14d38d4c4480f3668495edcfb644355c@mnot.net> <1117638135.25653.21.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I; hHtiZ43-RK8s{or'?iELJ; !_Mt2|\hW'VcAn*UR#@; 4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Finding a working SMTP relayer Date: Wed, 1 Jun 2005 21:22:22 +0200 To: Jeroen Massar X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org On Jun 1, 2005, at 5:02 PM, Jeroen Massar wrote: > $ grep smtp /etc/services > smtp 25/tcp mail > ssmtp 465/tcp smtps # SMTP over SSL Interesting; I get mnot-laptop:~> grep " 465/tcp" /etc/services urd 465/tcp # URL Rendesvous Directory for SSM on Mac OS 10.3, and that's also what's in http://www.iana.org/assignments/port-numbers. > But as you are only _submitting_ mail, use the Message Submission > standard (RFC2476) which goes over 587 and defaults to requiring > authentication and SSL. Ah, thanks for that reference! /etc/services and IANA only list "Submission", which isn't terribly descriptive. I don't see where it defaults to SSL, but it does allow for it. I think this is the way to go. I understand and agree with the arguments about not using a port to negotiate a secure transport, but I don't think that's what's happening here; ISPs are blocking port 25 because people are abusing MTAs. By having a separate port for MSAs, ISPs have local control over their network, while still allowing appropriate functionality on a separate port. The fact that it's SSL'ed (etc.) is orthogonal. Using your own MSA rather than a local one when you are roaming is far preferable; you have an ongoing relationship with it, so you know its policies on message size, exploding lists, etc. In contrast, you don't know any policies on a local, unknown server until you run up against them. They also don't know you, so they're less likely to deliver what they consider to be questionable mail on your behalf. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Wed Jun 01 15:47:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZBu-0001fQ-Ug; Wed, 01 Jun 2005 15:47:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZBu-0001fK-Bp for discuss@megatron.ietf.org; Wed, 01 Jun 2005 15:47:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21406 for ; Wed, 1 Jun 2005 15:47:47 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdZVl-0006zX-8Z for discuss@apps.ietf.org; Wed, 01 Jun 2005 16:08:23 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1DdZBl-000Cbx-7A; Wed, 01 Jun 2005 15:47:41 -0400 Date: Wed, 01 Jun 2005 15:47:41 -0400 From: John C Klensin To: Larry Masinter , discuss@apps.ietf.org Subject: RE: Finding a working SMTP relayer Message-ID: <8E06EBE7AA65F17EAF7CA517@scan.jck.com> In-Reply-To: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> References: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org --On Wednesday, 01 June, 2005 08:29 -0700 Larry Masinter wrote: > For finding an "appropriate" SMTP relay, might it not > depend on the source email address? I mainly use two > different email accounts (personal and business), and my > choice of SMTP relay depends both on the "From" address > as well as my current network location. (I don't want > to use my ISP's SMTP server for internal business mail). > > I'm not sure a simple SLP or DHCP service would do. Larry, There are lots of edge cases and cute heuristics that can be used to figure out when they apply and what values they would have, but there are, IMO, only three basic cases: (1) The user knows enough to statically configure the client to simply make the right choice. This is the case for all of the tunnels and other mechanisms for getting back to a "home" server as well as our classic (pre-open-relay-restrictions) environment. The tunnels may or may not need special configuration, but the mail client does not. (2) The choice of server is based on the user's semantic or mail-abstraction environment. Whether that is the domain name or the source email address or something else, some solution along the lines of Eric's (and my) SRV draft addresses these cases as far as the network is concerned. Where the domain name that goes into the DNS query is a local matter. (3) The choice of server is based on the user's current location in the network, i.e., on the network environment rather than that of the mail abstraction. With all respect to Keith's concerns about encouraging middleboxes, many of us have found ourselves seeking the SMTP relay that is network-nearest for 20-odd years, not because of control issues but because of simple performance over sometimes-dubious links. There are still parts of the world where that is important. Something DHCP-ish may offer some hope there, as, for some situations, a list of servers and a way to determine which one is most available at a given time. john From discuss-bounces@apps.ietf.org Wed Jun 01 16:33:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZuX-0004XR-Nl; Wed, 01 Jun 2005 16:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZuV-0004P3-Jl for discuss@megatron.ietf.org; Wed, 01 Jun 2005 16:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06776 for ; Wed, 1 Jun 2005 16:33:53 -0400 (EDT) Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdaEO-0004xv-SW for discuss@apps.ietf.org; Wed, 01 Jun 2005 16:54:29 -0400 Received: from localhost (klutz [127.0.0.1]) by klutz.cs.utk.edu (Postfix) with ESMTP id A263E40076; Wed, 1 Jun 2005 16:33:54 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03607-10; Wed, 1 Jun 2005 16:33:53 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by klutz.cs.utk.edu (Postfix) with ESMTP id 0E29640023; Wed, 1 Jun 2005 16:33:53 -0400 (EDT) Date: Wed, 1 Jun 2005 16:33:52 -0400 From: Keith Moore To: John C Klensin Subject: Re: Finding a working SMTP relayer Message-Id: <20050601163352.1f3fa610.moore@cs.utk.edu> In-Reply-To: <8E06EBE7AA65F17EAF7CA517@scan.jck.com> References: <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> <8E06EBE7AA65F17EAF7CA517@scan.jck.com> X-Mailer: Sylpheed version 1.9.9 (GTK+ 2.6.7; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cs.utk.edu by ClamAV and McAfee X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: LMM@acm.org, moore@cs.utk.edu, discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org > There are lots of edge cases and cute heuristics that can be > used to figure out when they apply and what values they would > have, but there are, IMO, only three basic cases: > > (1) The user knows enough to statically configure the client to > simply make the right choice. This is the case for all of the > tunnels and other mechanisms for getting back to a "home" server > as well as our classic (pre-open-relay-restrictions) > environment. The tunnels may or may not need special > configuration, but the mail client does not. > > (2) The choice of server is based on the user's semantic or > mail-abstraction environment. Whether that is the domain name > or the source email address or something else, some solution > along the lines of Eric's (and my) SRV draft addresses these > cases as far as the network is concerned. Where the domain > name that goes into the DNS query is a local matter. > > (3) The choice of server is based on the user's current location > in the network, i.e., on the network environment rather than > that of the mail abstraction. With all respect to Keith's > concerns about encouraging middleboxes, many of us have found > ourselves seeking the SMTP relay that is network-nearest for > 20-odd years, not because of control issues but because of > simple performance over sometimes-dubious links. There are > still parts of the world where that is important. I'm presuming that you were "in the loop" on such decisions, and had reason to believe you could trust the SMTP relay on those occasions where you chose to use it. That's a bit different from a situation where user agents blindly trust whatever the DHCP server says to use. > Something > DHCP-ish may offer some hope there, as, for some situations, a > list of servers and a way to determine which one is most > available at a given time. of these only (3) can be suitable as a default that can be chosen without the user's explicit consent. it is also necessary to support (1) for testing, for use with legacy servers, or to support the case where a recipient has his mail forwarded from one address to another but still wishes to use the first address as a return address. case (2) is complex, as the network will often provide the "wrong" information for that particular user and his address. so it needs to be explicitly enabled by the user and not used as a default. the choice of whether to use the DHCP-supplied server (or the server recommended by the local network via whatver means) might even depend on which network the user is connected to at the moment. (e.g. use the DHCP server's recommendation if I'm at work, my explicit settings if I'm at home, otherwise use the DNS). this problem isn't unique to SMTP, of course, and it might help to explain why DHCP isn't used more often to configure apps. Keith From discuss-bounces@apps.ietf.org Wed Jun 01 20:39:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DddkH-0003g2-Lr; Wed, 01 Jun 2005 20:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DddkG-0003fx-Mo for discuss@megatron.ietf.org; Wed, 01 Jun 2005 20:39:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24351 for ; Wed, 1 Jun 2005 20:39:32 -0400 (EDT) Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dde4B-0000dp-2b for discuss@apps.ietf.org; Wed, 01 Jun 2005 21:00:12 -0400 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LOY5GV5H2800004T@mauve.mrochek.com> for discuss@apps.ietf.org; Wed, 01 Jun 2005 17:39:26 -0700 (PDT) To: Larry Masinter Message-id: <01LOYEBPFTGY00004T@mauve.mrochek.com> Date: Wed, 01 Jun 2005 17:26:23 -0700 (PDT) From: Ned Freed Subject: RE: Finding a working SMTP relayer In-reply-to: "Your message dated Wed, 01 Jun 2005 08:29:56 -0700" <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01LOX72COPQE00004T@mauve.mrochek.com> <0IHE00J5SWDW4C@mailsj-v1.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org > I will remind you that for "finding HTTP proxy" configuration, > it was (is?) not unusual for people to deploy complex, > dynamic JavaScript functions that would, for every URL, > look at the URL and decide which proxy to use based on the > URL, the local connection spot, etc. Indeed. This has reached absurd heights here at Sun. There are all sorts of different .pac files floating around that purport to optimize different things in regards to proxies. There's even a gizmo run by someone that measures response times for various proxies and dynamically generates .pac files reflecting these measurements. I've never found any of this to actually work all that well as compared to a simple "always use proxy foo, manually switch is down" setting. What I've found is that these things improve things on average but also increase the number of bad response outliers significantly. It doesn't help that broswer support for this stuff is weak and buggy. > I don't know how widely this kind of nonsense is required > or deployed these days (some of the cases were just > because of bad network planning), but I wonder what the > high end of the requirements might be. There may be an actual requirement lurking under all this, but it is hard to separate away from the "engineers at play". Ned From discuss-bounces@apps.ietf.org Wed Jun 08 14:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg56l-0004c2-JJ; Wed, 08 Jun 2005 14:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg56i-0004bs-Qn for discuss@megatron.ietf.org; Wed, 08 Jun 2005 14:16:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22859 for ; Wed, 8 Jun 2005 14:16:51 -0400 (EDT) Received: from 213-158-213-84.eranet.pl ([213.158.213.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg5Rz-0002hu-2F for discuss@apps.ietf.org; Wed, 08 Jun 2005 14:38:53 -0400 Received: from [213.158.213.90] (localhost [127.0.0.1]) by 213-158-213-84.eranet.pl (Postfix) with ESMTP id C20E0A36C3; Wed, 8 Jun 2005 20:16:14 +0200 (CEST) Mime-Version: 1.0 Message-Id: Date: Wed, 8 Jun 2005 20:15:21 +0200 To: discuss@apps.ietf.org, IETF general mailing list From: Jacob Palme Subject: The IETF Golden Rules Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org I have written an Internet Draft on the IETF Golden Rules which may be very controversial. Abstract: This memo presents the following rules, which to some extend can be regarded as the golden rules of IETF, even though there are exceptions when these rules should not be adhered to. - Be liberal in what you accept, and conservative in what you send - Do not munge forwarded data - Modify as late as possible - Cause no harm - Leave nothing undefined - Keep it simple, stupid - No voting, rough consensus - Plain ASCII text is enough I have started a mailing list to discuss this draft, so that people not interested don't have to participate. To subscribe to the mailing list, go to http://lists.dsv.su.se/cgi-bin/mailman/listinfo/ietf-golden/ Do not comment on the draft in ietf@ietf.org or discuss@apps.ietf.org, use the new mailing list. -- Professor Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/jpalme/ From discuss-bounces@apps.ietf.org Fri Jun 10 08:47:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgiud-0004aG-1I; Fri, 10 Jun 2005 08:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQJU-0004ws-J3 for discuss@megatron.ietf.org; Thu, 09 Jun 2005 12:55:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20897 for ; Thu, 9 Jun 2005 12:55:25 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQez-0006wg-Jb for discuss@apps.ietf.org; Thu, 09 Jun 2005 13:17:41 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j59GsKL14262; Thu, 9 Jun 2005 09:54:20 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA16645; Thu, 9 Jun 2005 09:54:20 -0700 (PDT) Date: Thu, 9 Jun 2005 09:54:20 -0700 (PDT) Message-Id: <200506091654.JAA16645@gra.isi.edu> To: discuss@apps.ietf.org, ietf@ietf.org, jpalme@dsv.su.se Subject: Re: The IETF Golden Rules X-Sun-Charset: US-ASCII X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Fri, 10 Jun 2005 08:47:01 -0400 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@apps.ietf.org Errors-To: discuss-bounces@apps.ietf.org Nice list. How about adding: - Be very suspicious of centralized solutions that encourage monopolies and may introduce single points of failure. Bob Braden