From owner-ietf-smtp Sun Jan 12 17:23:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA02595 for ietf-smtp-bks; Sun, 12 Jan 1997 17:23:33 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smtp@imc.imc.org using -f Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA02586 for ; Sun, 12 Jan 1997 17:23:27 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jan 1997 17:23:20 -0800 To: ietf-smtp@imc.org From: "Paul E. Hoffman" Subject: The new "ietf-smtp" mailing list Sender: owner-ietf-smtp@imc.org Precedence: bulk Greetings. This is the first message on the ietf-smtp mailing list, which has moved from CREN to IMC. The participants of the list are the same. There is a Web site for the list at which has an archive of both the old list and the new one. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Mon Jan 13 16:21:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id QAA15975 for ietf-smtp-bks; Mon, 13 Jan 1997 16:21:38 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smtp@imc.imc.org using -f Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id QAA15971 for ; Mon, 13 Jan 1997 16:21:34 -0800 (PST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Mon, 13 Jan 1997 19:14:38 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Mon, 13 Jan 1997 19:14:37 -0500 Message-Id: <3.0.32.19970113191942.00f39a90@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 13 Jan 1997 19:19:43 -0500 To: ietf-smtp@imc.org From: "Jack De Winter" Subject: general question about failed DNS request when looking up MXs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk Okay, here's a general question for the group at large: You are doing an MX request to resolve an address that you need to send to. You get back a Server Error (RCODE=2) or an illegal return code (RCODE=6..15). What is the best thing to do to try and resolve this? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-smtp Mon Jan 13 17:22:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA16489 for ietf-smtp-bks; Mon, 13 Jan 1997 17:22:27 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smtp@imc.imc.org using -f Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA16484 for ; Mon, 13 Jan 1997 17:22:24 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-6 #8694) id <01IE62J9I2SGA8DRXP@INNOSOFT.COM> for ietf-smtp@imc.org; Mon, 13 Jan 1997 17:22:06 PST Date: Mon, 13 Jan 1997 16:47:27 -0800 (PST) From: Ned Freed Subject: Re: general question about failed DNS request when looking up MXs In-reply-to: "Your message dated Mon, 13 Jan 1997 19:19:43 -0500" <3.0.32.19970113191942.00f39a90@lacroix> To: Jack De Winter Cc: ietf-smtp@imc.org Message-id: <01IE67O1A1PSA8DRXP@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smtp@imc.org Precedence: bulk > Okay, here's a general question for the group at large: > You are doing an MX request to resolve an address that > you need to send to. You get back a Server Error (RCODE=2) > or an illegal return code (RCODE=6..15). What is the best > thing to do to try and resolve this? You have to abort the delivery attempt and try again later (temporary error). No other course of action is acceptable, really -- there is nothing that says that trying the host directly (even assuming you can get its A record when you can't get its MX record list) will produce correct results. Even if you're willing to enter a special mode where you treat any errors you get under these circumstances as temporary, it won't work in general. There are cases where the host in user@host being an MX pointing to several other systems ends up resolving to an entirely different mailbox than user@host where host is treated as simply an A record. There are also cases where direct delivery ignoring MX leads to loops. (Yes, such setups are problematic given the fact that not everything on the Internet is consistent in its support of MX, but such setups exist nevertheless and have to be dealt with.) The bottom line is that RFC974 says that when an the DNS returns a non-empty MX list the client is supposed to try all the hosts on that list and then stop, and setups have been built and are actively being used that take advantage of every nuance of this described behavior. So if you cannot get the MX list you don't know what you should or should not do, so your only course of action is to not do anything. Ned From owner-ietf-smtp Fri Feb 21 19:26:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA04679 for ietf-smtp-bks; Fri, 21 Feb 1997 19:26:37 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA04662; Fri, 21 Feb 1997 19:25:12 -0800 (PST) Received: from [205.214.160.130] (d20.netgate.net [205.214.160.52]) by ng.netgate.net (8.8.5/8.6.9) with ESMTP id TAA26971; Fri, 21 Feb 1997 19:30:56 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 2 (High) Date: Fri, 21 Feb 1997 19:26:15 -0800 To: imc-mailconnect@imc.org From: Dave Crocker Subject: MailConnect 2 interoperability event Cc: (drums, ietf-smtp@imc.org, ietf-822@imc.org, imap@cac.washington.edu) Sender: owner-ietf-smtp@imc.org Precedence: bulk =46olks, The Internet Mail Consortium is now trying to finalize details for MailConnect 2, an engineering interoperability event for Internet mail software developers. This past summer's MailConnect 1 tested IMAP4 and MIME. MailConnect 2 is intended for ESMTP and more IMAP4 testing. In previous queries, the end of March appeared to be the best choice for bringing developers together. I would like to get some quick feedback about preferred dates, from folks who are likely to attend. LOGISTICS The event will be in the same venue as before, the San Jose, CA Hilton. They now have a T1 connection to the net. We'll be providing snacks and drinks and, will provide lunch this time. We are investigating reduced room rates at the Hilton. Let me know if you would be likely to stay there: Yes ____ No ____ DATE Please indicate ALL of the following that are feasible for you: March 18/19 - T/W ____ 19/20 - W/Th ____ 21/22 - Th/F ____ March 25/26 - T/W ____ 27/28 - W/Th ____ 28/29 - Th/F ____ April 1/2 - T/W ____ 2/3 - W/Th ____ (no 3/4, to avoid the Friday before IETF) If a later date is very strongly preferred, please let me know. If a later date is very strongly NOT preferred, also let me know. COSTS Early Registration: $1500 for IMC members; $2000 for non-members Late Registration: $2000 for IMC members; $2500 for non-members d/ -------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segre Place dcrocker@imc.org Santa Cruz, CA 95060 USA info@imc.org , http://www.imc.org From owner-ietf-smtp Wed Mar 5 11:10:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25854 for ietf-smtp-bks; Wed, 5 Mar 1997 11:10:18 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA25813; Wed, 5 Mar 1997 11:08:11 -0800 (PST) Received: from [205.214.160.83] (d45.netgate.net [205.214.160.79]) by ng.netgate.net (8.8.5/8.6.9) with ESMTP id LAA08457; Wed, 5 Mar 1997 11:15:38 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 2 (High) Date: Wed, 5 Mar 1997 11:08:33 -0800 To: imc-mailconnect@imc.org From: Dave Crocker Subject: MailConnect 2 / 26-27 March 97: Email Interoperability testing Cc: (drums, ietf-smtp@imc.org, ietf-822@imc.org, imap@cac.washington.edu) Sender: owner-ietf-smtp@imc.org Precedence: bulk The Internet Mail Consortium is sponsoring a second interoperability testing event for Internet Mail. MailConnect 2 will be held: Wednesday - Thursday, 26-27 March 1997 with setup: available the day before at: San Jose, California Hilton testing: IMAP4 and ESMTP The details of the testing will be determined by the attendees, based on discussion on the imc-mailconnect mailing list, beforehand. This is the second time we will be testing IMAP4 and the first for SMTP extensions. The event is for engineering testing, rather than for press and marketing demonstrations. These events improve actual interoperability among independent implementations, typically producing enormous imrpovements within the very short time of the meeting. =46or further details, please see: To subscribe to the event discusssion list, send a message to imc-mailconnect-request@imc.org with the single word subscribe in the body of the message. d/ -------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segre Place dcrocker@imc.org Santa Cruz, CA 95060 USA info@imc.org , http://www.imc.org From owner-ietf-smtp Sun May 11 16:30:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA17691 for ietf-smtp-bks; Sun, 11 May 1997 16:30:32 -0700 (PDT) Received: from machias.nemaine.com ([205.139.6.148]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA17687 for ; Sun, 11 May 1997 16:30:29 -0700 (PDT) Received: from [147.40.34.248] by machias.nemaine.com (SMTPD32-3.04) id A6D063400B4; Sun, 11 May 1997 19:31:28 -0400 Message-Id: <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> X-Homepage: X-Sender: aegreene@pop.mindspring.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 12 May 1997 01:35:07 +0200 To: ietf-smtp@imc.org From: "Anthony E. Greene" Subject: Cancel Message for Internt Mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk Does anyone know of a discussion on a retraction function for mail analogous to an NNTP cancel message? I have looked through the IMC and IETF sites without success. I saw the draft SMTP extension that allows supersession and expiration, but that's not quite what I'm looking for. I'd like to see a way for the sender to cancel a message before it is read by the recipient. If there isn't such a proposal on the table is this the place to discuss it? -- Anthony E. Greene vCard and PGP Key: PGP KeyID: pub 1083 0x78CD4329 PGP FAQ: From owner-ietf-smtp Mon May 12 08:43:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA26832 for ietf-smtp-bks; Mon, 12 May 1997 08:43:58 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA26828 for ; Mon, 12 May 1997 08:43:55 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA11820; Mon, 12 May 1997 11:44:24 -0400 Message-Id: <199705121544.LAA11820@black-ice.cc.vt.edu> To: "Anthony E. Greene" Cc: ietf-smtp@imc.org Subject: Re: Cancel Message for Internt Mail In-Reply-To: Your message of "Mon, 12 May 1997 01:35:07 +0200." <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1582152804P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 12 May 1997 11:44:21 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk --==_Exmh_-1582152804P Content-Type: text/plain; charset=us-ascii On Mon, 12 May 1997 01:35:07 +0200, you said: > Does anyone know of a discussion on a retraction function for mail > analogous to an NNTP cancel message? I have looked through the IMC and IETF > sites without success. I saw the draft SMTP extension that allows > supersession and expiration, but that's not quite what I'm looking for. I'd > like to see a way for the sender to cancel a message before it is read by > the recipient. > > If there isn't such a proposal on the table is this the place to discuss it? Yes, this would be the place to discuss it. No, there's no such proposal as far as I am aware. There are a number of severe problems you need to deal with in any such proposal: 1) What level of "guarantee" will the service provide? If the service *says* it was cancelled, how cancelled is it *really*? (Remember that Oliver North got strung up because of system backups that contained e-mail memos he thought were deleted). Is the file *really* erased to (say) mil-spec standards (overwritten multiple times with random patterns, and so on), or is it just logically erased, and still scavengable off the disk, or is it still in a file, and just marked as "purged"? 2) What if the recipient gets his "You have new mail" bleep right away, and goes and reads his mail? You then have to deal with (a) the mail was already read - NOW what do you do? and even worse (b) the recipient is in the process of reading it when cancelling is attempted... 3) Many people (myself included) do a lot of programmatic processing of mail (filtering, filing based on origin/subject, etc) when the mail is received. There's *NO* way that you will be able to get at a message to cancel it in this case. Even if the message itself were removable, there may be other state information that will get changed. For instance, my 'procmail' filter keeps statistical information on the number of messages received of different types - if I receive a message in "Category 3A" that's subsequently cancelled, how does that change the 'received count' for 3A? 4) Security implications - what level of authentication is needed to cancel a mailgram? Note that this is a serious issue for the folks who are doing EDI over e-mail - they most certainly do *NOT* want people to be able to cancel an EDI-submitted order that easily, outside the EDI scheme. 5) Implications for e-mail based automatons (Listservs, file servers, and the like) - what happens if you send in a 'cancel' for a subscription request? Especially if the Listserv processed it already? (This is *not* a moot point - I've seen our Listserv receive a subscribe, process it, and get the "you have been subscribed" message out all within 2 seconds). I could probably think of more issues if I hadn't just arrived at the office and not ingested my usual requirement of caffeine yet. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1582152804P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM3c60tQBOOoptg9JAQFx3QP/by9LcGtoUD/HrNVo8M/QuuCIb20r01S/ V4XY9ptB9F/r4HwlHb45v0W21CgyEB8Sv+80k5SbuOM5hECHy8Ow17VEtfku7BzD Hd3r1pwmctgCCQOkz6BnH8YjWJBJeIGpU69labWrJuKuaIVcmKw+Kxy1WQ4U+cKy iVOaLTwCww8= =Lmz3 -----END PGP MESSAGE----- --==_Exmh_-1582152804P-- From owner-ietf-smtp Tue May 13 13:38:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA18703 for ietf-smtp-bks; Tue, 13 May 1997 13:38:30 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.50.61]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA18698 for ; Tue, 13 May 1997 13:38:25 -0700 (PDT) Received: from [129.46.54.123] (ra4000-p3.qualcomm.com [129.46.54.83]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id NAA08022; Tue, 13 May 1997 13:37:57 -0700 (PDT) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <199705121544.LAA11820@black-ice.cc.vt.edu> References: Your message of "Mon, 12 May 1997 01:35:07 +0200." <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> Mime-Version: 1.0 X-Mailer: Eudora [Macintosh version 3.1] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Tue, 13 May 1997 13:09:59 -0700 To: "Anthony E. Greene" From: "John W. Noerenberg" Subject: Re: Cancel Message for Internt Mail Cc: Valdis.Kletnieks@vt.edu, ietf-smtp@imc.org Content-Type: multipart/signed; boundary="PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782"; micalg=pgp-md5; protocol="application/pgp-signature";PGPFormat="PGPMIME-signed" Sender: owner-ietf-smtp@imc.org Precedence: bulk --PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11:44 AM -0400 5/12/1997, Valdis.Kletnieks@vt.edu wrote: >*** >*** PGP Signature Status: good >*** Signer: >*** Signed: 5/12/1997 at 8:44 AM >*** Verified: 5/13/1997 at 12:57 PM >*** > >On Mon, 12 May 1997 01:35:07 +0200, you said: >> Does anyone know of a discussion on a retraction function for mail >> analogous to an NNTP cancel message? I have looked through the IMC and IE= TF >> sites without success. I saw the draft SMTP extension that allows >> supersession and expiration, but that's not quite what I'm looking for. I= 'd >> like to see a way for the sender to cancel a message before it is read by >> the recipient. >> >> If there isn't such a proposal on the table is this the place to discuss = it? > >Yes, this would be the place to discuss it. > >No, there's no such proposal as far as I am aware. > >There are a number of severe problems you need to deal with in any such >proposal: Tony, if you have some ideas that can address Valdis' concerns, I'd be very interested in hearing more. I have to be honest and say that I think it is highly unlikely you can guarantee the cancel in the distrbuted environment of the Internet. And that is what will be required. I even think you would be hard pressed to prove that the nntp CANCEL is 100% effective. By that I mean that no one at any site had read a message that was also cancelled. john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- "We need not to be left alone. We need to be really bothered once in a while." -- Ray Bradbury, Farhenheit 451, 1953 -------------------------------------------------------------------- --PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 5.0 beta MessageID: /E3f3vaLESUjnQkjwRKo3l+kGEL6pWq+ iQCVAwUBM3jRSX0RF3HCK4zZAQEdeQQAgG2aTohj/a/bkgWj1lCvkkIZ+xD1kQWB Mw9XJTMACib/MtxTiWRadfkhJQk3a6nPTYdnC3X+X0uzQ4qCH3fLyPLLeQDONxqb axg9UFF0HC6pLaw7Pq2iTVgXgiTUhw14s89CbSJr3ho55sbgFHx/CzO+g9Fnl85j i4bnm1gVIrU= =fcBy -----END PGP SIGNATURE----- --PGPmailPluginForEudora-5.0beta-3-1835517304-1348591782-- From owner-ietf-smtp Tue May 13 14:08:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA19084 for ietf-smtp-bks; Tue, 13 May 1997 14:08:16 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA19080 for ; Tue, 13 May 1997 14:08:13 -0700 (PDT) Received: from [129.46.137.140] (randy-mac.qualcomm.com [129.46.137.140]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA16865; Tue, 13 May 1997 14:07:56 -0700 (PDT) Message-Id: In-Reply-To: References: <199705121544.LAA11820@black-ice.cc.vt.edu> Your message of "Mon, 12 May 1997 01:35:07 +0200." <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 14:05:33 -0700 To: "John W. Noerenberg" From: Randall Gellens Subject: Re: Cancel Message for Internt Mail Cc: "Anthony E. Greene" , Valdis.Kletnieks@vt.edu, ietf-smtp@imc.org Sender: owner-ietf-smtp@imc.org Precedence: bulk At 1:09 PM -0700 5/13/97, John W. Noerenberg wrote: > Tony, if you have some ideas that can address Valdis' concerns, I'd be very > interested in hearing more. I have to be honest and say that I think it is > highly unlikely you can guarantee the cancel in the distrbuted environment > of the Internet. And that is what will be required. > > I even think you would be hard pressed to prove that the nntp CANCEL is > 100% effective. By that I mean that no one at any site had read a message > that was also cancelled. My understanding of NNTP CANCEL is that it is far from guaranteed; but then that also goes for NNTP in general. CANCEL messages get lost, messages get cancelled after they are read, so what? Also, NNTP specifically says that sites should not do much authentication on the CANCEL message; certainly forging one is quite easy. If there were to be an SMTP CANCEL (maybe RESCIND?) I think it would have to be modelled on receipts -- strictly advisory, no guarantees to the sender that anything will happen, up to the receiver how to deal with one. From owner-ietf-smtp Tue May 13 17:58:57 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA21814 for ietf-smtp-bks; Tue, 13 May 1997 17:58:57 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA21806 for ; Tue, 13 May 1997 17:58:54 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 1997 17:59:40 -0700 To: ietf-smtp@imc.org From: "Paul E. Hoffman" Subject: New SMTP response codes Sender: owner-ietf-smtp@imc.org Precedence: bulk And now for something completely different. I needed a new SMTP response code for an SMTP extension I'm writing. However, I could not find any central registry of them. This seems to be a bit of a problem, because I don't want to choose the same one that some other extension writer has chosen. (I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs on the IMC site for "560", the number I chose, and got nothing relevant.) This isn't a pressing need, but it could be embarassing if we end up with two standards-track SMTP extensions that use the same new error code for very different things. Sounds like a job for IANA, but we need to define what IANA should do. My straw-man proposal is: - Start with a list of all response codes from 821 and all standards-track RFCs (I can compile this) - Generally treat this like the TCP port number reservation scheme (first come, first served) - Require that a registrant provide: Name Email address Name of Internet Draft the code is used in Date of first use Because the response code space is limited, it might eventually fill up and someone will have to go through and cull out the response codes that were reserved but for which there is no valid Internet Draft or RFC. However, that will hopefully not happen for a decade or two, given that SMTP extensions should not be promulgated willy-nilly. Thoughts? --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Tue May 13 18:11:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA21937 for ietf-smtp-bks; Tue, 13 May 1997 18:11:50 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA21931; Tue, 13 May 1997 18:11:46 -0700 (PDT) Received: by callandor.cybercash.com; id VAA12084; Tue, 13 May 1997 21:01:40 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma012076; Tue, 13 May 97 21:01:24 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA05319; Tue, 13 May 97 21:07:00 EDT Date: Tue, 13 May 1997 21:06:59 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: "Paul E. Hoffman" Cc: ietf-smtp@imc.org Subject: Re: New SMTP response codes In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk Paul, (1) I suggest you grep drafts also. I belive there are proposed SMTP response codes in draft-eastlake-internet-payment-*.txt. (2) Intelligent allocation based on a balancing of the factor from a limited pool is exactly what IANA is best for. The main problems that have arisen are when large amounts of money seem to be involved, which I think unlikely for SMTP response codes. Donald On Tue, 13 May 1997, Paul E. Hoffman wrote: > Date: Tue, 13 May 1997 17:59:40 -0700 > From: Paul E. Hoffman > To: ietf-smtp@imc.org > Subject: New SMTP response codes > > And now for something completely different. I needed a new SMTP response > code for an SMTP extension I'm writing. However, I could not find any > central registry of them. This seems to be a bit of a problem, because I > don't want to choose the same one that some other extension writer has > chosen. > > (I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs > on the IMC site for "560", the number I chose, and got nothing relevant.) > > This isn't a pressing need, but it could be embarassing if we end up with > two standards-track SMTP extensions that use the same new error code for > very different things. Sounds like a job for IANA, but we need to define > what IANA should do. > > My straw-man proposal is: > > - Start with a list of all response codes from 821 and all standards-track > RFCs (I can compile this) > > - Generally treat this like the TCP port number reservation scheme (first > come, first served) > > - Require that a registrant provide: > Name > Email address > Name of Internet Draft the code is used in > Date of first use > > Because the response code space is limited, it might eventually fill up and > someone will have to go through and cull out the response codes that were > reserved but for which there is no valid Internet Draft or RFC. However, > that will hopefully not happen for a decade or two, given that SMTP > extensions should not be promulgated willy-nilly. > > Thoughts? > > --Paul E. Hoffman, Director > --Internet Mail Consortium > > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ietf-smtp Wed May 14 03:43:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA27443 for ietf-smtp-bks; Wed, 14 May 1997 03:43:38 -0700 (PDT) Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id DAA27438; Wed, 14 May 1997 03:43:35 -0700 (PDT) Received: from tp7.reston.mci.net ("port 1373"@[166.55.54.236]) by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EA635KU1007QH@a4.jck.com>; Wed, 14 May 1997 06:44:12 -0400 (EDT) Date: Wed, 14 May 1997 06:44:05 -0400 (EDT) From: John C Klensin Subject: Re: New SMTP response codes To: "Paul E. Hoffman" Cc: ietf-smtp@imc.org Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.1 Build (14) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-smtp@imc.org Precedence: bulk On Tue, 13 May 1997 17:59:40 -0700 "Paul E. Hoffman" wrote: > And now for something completely different. I needed a new SMTP response > code for an SMTP extension I'm writing. However, I could not find any > central registry of them. This seems to be a bit of a problem, because I > don't want to choose the same one that some other extension writer has > chosen. >... Paul, Unfotunately, we have a number of implementations that believe that the only valid codes are those that are in 821 -- every time a new one has been added, there has been trouble. Conversely, one or two implementations have promiscuously implemented all sorts of codes without documenting them. This was a reason why the "be prepared to use first digit only" rule went into RFC 1123 (perhaps the main reason). Consequently, much as a code registry would be a good idea --and IANA is probably the right place-- you might as well, in practice, just make something up and assume that only the first digit will be relevant. There is a case to be made for trying the following strategy: * Make up one more set of codes, e.g., 299, 399, 499, 599 And give them the definition "extended code of status/severity (2, 3, 4, 5), see extended reply code" and a phrase syntax of "n.n.n text". * Make absolutely sure that the definitions and extension mechanisms of RFC 1893 are adequate. --john From owner-ietf-smtp Wed May 14 06:51:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA00128 for ietf-smtp-bks; Wed, 14 May 1997 06:51:35 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA00102; Wed, 14 May 1997 06:49:57 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa23807; 14 May 97 9:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ietf-muse@imc.org, ietf-smtp@imc.org, spam-list@psc.edu Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-eastlake-muse-02.txt Date: Wed, 14 May 1997 09:40:09 -0400 Message-ID: <9705140940.aa23807@ietf.org> Sender: owner-ietf-smtp@imc.org Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mail Ubiquitous Security Extensions (MUSE) Author(s) : D. Eastlake Filename : draft-eastlake-muse-02.txt Pages : 22 Date : 05/12/1997 Secure electronic mail can provide authentication of the source of mail and confidentiality for its contents. These features are becoming increasingly important as the Internet grows exponentially and email is increasingly used for critical, sensitive, and confidential communications. In addition, authentication can make mail filtering more effective and ubiquitous encryption indirectly makes all mail more secure be defeating traffic analysis based on distinctions between encrypted and non-encrypted mail and defeating bulk searching through insecure mail. However, use of secure mail is not widespread due to the problems of key distribution and lack of migration to secure mail enabled user agents. This draft proposes partial solutions to these two problems by using coarser grained identity to permit some authentication and confidentiality without user agent change, and secure DNS for key distribution. These changes also support limited host and domain level mail security policies. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eastlake-muse-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-eastlake-muse-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-eastlake-muse-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970512161801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eastlake-muse-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-eastlake-muse-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970512161801.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smtp Wed May 14 07:54:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA00940 for ietf-smtp-bks; Wed, 14 May 1997 07:54:14 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA00934; Wed, 14 May 1997 07:54:11 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IIUO3VNM2O99HHRS@INNOSOFT.COM>; Wed, 14 May 1997 07:53:48 PDT Date: Wed, 14 May 1997 07:40:26 -0700 (PDT) From: Ned Freed Subject: Re: New SMTP response codes In-reply-to: "Your message dated Tue, 13 May 1997 17:59:40 -0700" To: "Paul E. Hoffman" Cc: ietf-smtp@imc.org Message-id: <01IIUP38LLDK99HHRS@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smtp@imc.org Precedence: bulk > And now for something completely different. I needed a new SMTP response > code for an SMTP extension I'm writing. However, I could not find any > central registry of them. This seems to be a bit of a problem, because I > don't want to choose the same one that some other extension writer has > chosen. As John has already pointed out, you really don't need to formally register new codes in this space. However, John didn't point out that there's another codespace for response codes, the one defined in RFC1893. You should make sure that a code exists in this space that works for you, and if it doesn't we need to get the process going to define whatever additional codes you need. Any effort at formalizing registration mechanisms needs to be associated with this new code space, not the old SMTP code space. Note that RFC2034 specifies the standard way for returning these codes in SMTP. > (I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs > on the IMC site for "560", the number I chose, and got nothing relevant.) This, unfortunately, will not fly. You have to pick a code with a second digit of 5 or less. Anything else may be rejected as syntactically illegal by deployed servers. And such rejection is entirely in conformance with current specifications, making this a true nonstarter in any case. You can use the third digit of the code to give you whatever additional precision you want. > This isn't a pressing need, but it could be embarassing if we end up with > two standards-track SMTP extensions that use the same new error code for > very different things. Sounds like a job for IANA, but we need to define > what IANA should do. This really isn't that big a deal. There's lots of overlap in present usage; one of the main reasons for defining a new code space was to address this problem. Ned From owner-ietf-smtp Wed May 14 09:46:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA02611 for ietf-smtp-bks; Wed, 14 May 1997 09:46:22 -0700 (PDT) Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA02604; Wed, 14 May 1997 09:46:15 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Wed, 14 May 1997 09:46:40 -0700 Message-ID: From: "Jeff Stephenson (Exchange)" To: "'John C Klensin'" , "Paul E. Hoffman" Cc: ietf-smtp@imc.org Subject: RE: New SMTP response codes Date: Wed, 14 May 1997 09:46:39 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-smtp@imc.org Precedence: bulk I like this idea. I've been thinking that it would be useful to have some response code that says "Here's the basic status of the response - check the extended errors if you care about more." It might even be useful to define 2x9, 3x9, 4x9, and 5x9 responses which give the more informative category of response but then refer to the extended codes. This would provide more detailed information to software which looks at the second digit, as '9' is not a legitimate category under the SMTP theory of reply codes. John - would this be appropriate to include in your 821bis draft, or is it out of scope? If it can't go into 821bis, what would be the best way to proceed? -- jeff > -----Original Message----- > From: John C Klensin [SMTP:klensin@mci.net] > Sent: Wednesday, May 14, 1997 3:44 AM > To: Paul E. Hoffman > Cc: ietf-smtp@imc.org > Subject: Re: New SMTP response codes > > There is a case to be made for trying the following > strategy: > > * Make up one more set of codes, e.g., > 299, 399, 499, 599 > And give them the definition "extended code of > status/severity (2, 3, 4, 5), see extended reply > code" and a phrase syntax of "n.n.n text". > * Make absolutely sure that the definitions and extension > mechanisms of RFC 1893 are adequate. > > --john > From owner-ietf-smtp Thu May 15 19:04:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA12868 for ietf-smtp-bks; Thu, 15 May 1997 19:04:43 -0700 (PDT) Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA12863; Thu, 15 May 1997 19:04:40 -0700 (PDT) Received: from tp7.Jck.com ("port 2204"@[206.99.215.42]) by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0EA94GXCN00MG1@a4.jck.com>; Thu, 15 May 1997 22:05:21 -0400 (EDT) Date: Thu, 15 May 1997 22:05:20 -0400 (EDT) From: John C Klensin Subject: Re: RE: New SMTP response codes To: "Jeff Stephenson (Exchange)" Cc: "Paul E. Hoffman" , ietf-smtp@imc.org Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.1 Build (14) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-smtp@imc.org Precedence: bulk On Wed, 14 May 1997 09:46:39 -0700 "Jeff Stephenson (Exchange)" wrote: > John - would this be appropriate to include in your 821bis draft, or is > it out of scope? If it can't go into 821bis, what would be the best way > to proceed? I fear that it is out of scope, but would happily accept direction from Chris/Harald/Keith to the contrary. The biggest problem is that we can't make a normative reference to the extended code idea from 821bis without creating a queuing situation. john From owner-ietf-smtp Sat May 17 16:52:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA12054 for ietf-smtp-bks; Sat, 17 May 1997 16:52:14 -0700 (PDT) Received: from machias.nemaine.com ([205.139.6.148]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA12050 for ; Sat, 17 May 1997 16:52:11 -0700 (PDT) Received: from [147.40.34.248] by machias.nemaine.com (SMTPD32-3.04) id A4FD45017C; Sat, 17 May 1997 19:53:33 -0400 Message-Id: <3.0.1.32.19970515155630.006a0bdc@pop.mindspring.com> X-Homepage: X-Sender: aegreene@pop.mindspring.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 15 May 1997 15:56:30 +0200 To: ietf-smtp@imc.org From: "Anthony E. Greene" Subject: Re: Cancel Message for Internt Mail In-Reply-To: <199705121544.LAA11820@black-ice.cc.vt.edu> References: <3.0.1.32.19970512013507.006a7028@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk At 11:44 AM 5/12/97 -0400, Valdis.Kletnieks@vt.edu wrote: >There are a number of severe problems you need to deal with in any such >proposal: > >1) What level of "guarantee" will the service provide? The cancelling agent (server or client) would delete the message from it's message store and return a delivery status notification message to the sender. If the message could not be found or had been read the DSN would indicate these conditions. If the agent that found and deleted the message was unable to determine the whether or not the message had been read the DSN would indicate this also. Of course backups may remain and it's possible that they would be delivered if a failure occured between reception of the original and reception of the cancellation. I think this possiblity could simply be stated in the draft and accepted as is. This is one of the things that can happen when backup data is used. There would be no requirement for sanitation of the message store (overwriting, etc). Only a similar function as would happen if the recipient read and deleted the message. >2) What if the recipient gets his "You have new mail" bleep right >away, and goes and reads his mail?... The mail client would not attempt deletion on a message that is open or has been read. A failure DSN would be returned to the sender indicating the message could not be deleted and may have been read. This is not supposed to be a perfect mechanism, just a feature that could be used to recover from an accident (hopefully) before it's too late. >3) Many people (myself included) do a lot of programmatic processing >of mail (filtering, filing based on origin/subject, etc) when the mail >is received. There's *NO* way that you will be able to get at a >message to cancel it in this case. Even if the message itself were >removable, there may be other state information that will get >changed. For instance, my 'procmail' filter keeps statistical >information on the number of messages received of different types - if >I receive a message in "Category 3A" that's subsequently cancelled, >how does that change the 'received count' for 3A? If the message has been processed and is not removable then a failure DSN would be returned to the sender. Otherwise the client could search through it's folders to find the original message by message-id. This may be a lengthy process but it should not happen very often. Your second point is harder. A graceful failure may be the best that can be achieved without a lot of filter rewriting. >4) Security implications... The sender would have to be the same and the message id would have to be specified. This is the biggest weak point I saw when thinking about this. The only solutions I could come up with involve public key and directory infrastructures that we don't have yet. Servers which process business critical transactions could have cancel messages disabled. The real solution is a security infrastructure. This whole idea may not be practical yet. >5) Implications for e-mail based automatons... The sender would get a failure DSN. It may be possible to configure machines that serve only as listservers to send a help message when a cancel message is sent to a list address, in addition to the failure DSN. -- Anthony E. Greene vCard and PGP Key: PGP KeyID: pub 1083 0x78CD4329 PGP FAQ: From owner-ietf-smtp Sat May 17 19:51:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA12821 for ietf-smtp-bks; Sat, 17 May 1997 19:51:03 -0700 (PDT) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA12816; Sat, 17 May 1997 19:51:00 -0700 (PDT) Received: from [205.214.160.48] (d17.netgate.net [205.214.160.49]) by ng.netgate.net (8.8.5/8.8.5) with ESMTP id UAA04739; Sat, 17 May 1997 20:02:31 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 May 1997 19:25:11 -0700 To: ietf-smtp@imc.org From: Dave Crocker Subject: Reconnect/Retransmission Cc: "Paul E. Hoffman" Sender: owner-ietf-smtp@imc.org Precedence: bulk Discussion with Paul H. about the response codes led to a question about "when things change", the directive from RFC 821 indicating when a sending MTA should "try again". It occurs to me that we give no guidance for reconnection to unavailable hosts or retries for currently inaccessible mailboxes. Do we not have enough accumulated wisdom on this to provide at least a modicum of guidance in 821bis? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-smtp Tue May 20 19:13:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA21309 for ietf-smtp-bks; Tue, 20 May 1997 19:13:11 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA21304; Tue, 20 May 1997 19:13:07 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id WAA04267; Tue, 20 May 1997 22:14:02 -0400 (EDT) Message-Id: <199705210214.WAA04267@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Paul E. Hoffman" cc: ietf-smtp@imc.org, moore@cs.utk.edu Subject: Re: New SMTP response codes In-reply-to: Your message of "Tue, 13 May 1997 17:59:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 May 1997 22:13:58 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk just catching up on my mail after a week's vacation... random thoughts on defining new SMTP response codes: 1. IANA should maintain the list of response codes. 2. The new SMTP document being written by DRUMS should specify the registration procedure. (offhand, I'd suggest that the code has to be defined in a standards-track or experimental RFC with IESG approval) 3. New SMTP codes should probably be defined only when necessary for the the server to notify the client of a state transition....not just for new kinds of errors. RFC 1893 codes, along with the ENHANCEDSTATUSCODES option, should be used to communicate new kinds of errors where no new state changes are introduced. 4. There's no problem with defining new SMTP codes if those codes will only be generated by servers that claim to support a particular ESMTP option, and only when a client explicitly invokes that option. Otherwise, there needs to be a really good reason for defining a new code...like a state change. Keith From owner-ietf-smtp Thu Jul 10 16:25:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03718 for ietf-smtp-bks; Thu, 10 Jul 1997 16:25:47 -0700 (PDT) Received: from calvin.twntpe.cdc.com (ip129179-17-10.a.cdc.com [129.179.17.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA03714 for ; Thu, 10 Jul 1997 16:25:42 -0700 (PDT) Received: from calvin.twntpe.cdc.com by calvin.twntpe.cdc.com; Fri, 11 Jul 1997 07:27:52 +0800 Date: Fri, 11 Jul 1997 07:27:52 +0800 (GMT) From: Edward M Greshko To: ietf-smtp@imc.org Subject: Need the quote and the author Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk Hi, Of course this is not quite related to SMTP...... There is a quote by someone from a time long ago which goes along the lines of being conservative in what you generate and liberal in what you receive. In other words, make sure that you follow the specs to the letter in what you generate, however try to deal with anything reasonable that you can anticipate being thrown your way. I need to know the exact quote and the author. If it is documented someplace that would be "nice" too. Ed From owner-ietf-smtp Thu Jul 10 18:58:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA05115 for ietf-smtp-bks; Thu, 10 Jul 1997 18:58:52 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA05111 for ; Thu, 10 Jul 1997 18:58:49 -0700 (PDT) Received: by callandor.cybercash.com; id VAA21241; Thu, 10 Jul 1997 21:48:19 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma021239; Fri, 11 Jul 97 01:48:18 GMT Received: by cybercash.com (4.1/SMI-4.1) id AA16254; Thu, 10 Jul 97 21:55:42 EDT Date: Thu, 10 Jul 1997 21:55:41 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Edward M Greshko Cc: ietf-smtp@imc.org Subject: Re: Need the quote and the author In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk Don't know where it started but it is included in RFC 1958, Architectural Principles of the Internet, in section 3.9. Donald On Fri, 11 Jul 1997, Edward M Greshko wrote: > Date: Fri, 11 Jul 1997 07:27:52 +0800 (GMT) > From: Edward M Greshko > To: ietf-smtp@imc.org > Subject: Need the quote and the author > > Hi, > > Of course this is not quite related to SMTP...... > > There is a quote by someone from a time long ago which goes along the > lines of being conservative in what you generate and liberal in what you > receive. In other words, make sure that you follow the specs to the > letter in what you generate, however try to deal with anything reasonable > that you can anticipate being thrown your way. > > I need to know the exact quote and the author. If it is documented > someplace that would be "nice" too. > > Ed > > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ietf-smtp Fri Jul 11 02:56:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA09838 for ietf-smtp-bks; Fri, 11 Jul 1997 02:56:20 -0700 (PDT) Received: from quay.pipex.net (quay.mail.pipex.net [158.43.128.34]) by mail.proper.com (8.8.5/8.7.3) with SMTP id CAA09833 for ; Fri, 11 Jul 1997 02:56:16 -0700 (PDT) Received: (qmail 18268 invoked from network); 11 Jul 1997 09:58:58 -0000 Received: from pool.uunet.pipex.com (158.43.134.17) by quay.uunet.pipex.com with QMTP; 11 Jul 1997 09:58:58 -0000 To: Edward M Greshko CC: ietf-smtp@imc.org Subject: Re: Need the quote and the author In-Reply-To: Date: Fri, 11 Jul 1997 10:58:57 +0100 From: Tim Goodwin Message-ID: Sender: owner-ietf-smtp@imc.org Precedence: bulk > There is a quote by someone from a time long ago which goes along the > lines of being conservative in what you generate and liberal in what you > receive. It's from Host Requirements, STD 3, RFC 1123. > In other words, make sure that you follow the specs to the > letter in what you generate, however try to deal with anything reasonable > that you can anticipate being thrown your way. No, that's *not* what it means. The Robustness Principle does not justify ad hoc extensions to the specification (for example, sendmail accepting `RCPT TO:tim@uunet.pipex.com'). Study section 1.2.2 of 1123 carefully. Tim. From owner-ietf-smtp Sun Jul 13 06:18:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA04130 for ietf-smtp-bks; Sun, 13 Jul 1997 06:18:45 -0700 (PDT) Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA04126 for ; Sun, 13 Jul 1997 06:18:40 -0700 (PDT) Received: from tp7.Jck.com ("port 1924"@[206.99.215.42]) by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0ED9EFV0G002AH@a4.jck.com> for ietf-smtp@imc.org; Sun, 13 Jul 1997 09:21:31 -0400 (EDT) Date: Sun, 13 Jul 1997 09:21:23 -0400 (EDT) From: John C Klensin Subject: Re: Need the quote and the author In-reply-to: To: Edward M Greshko Cc: ietf-smtp@imc.org Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.2 Build (22a) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-smtp@imc.org Precedence: bulk On Fri, 11 Jul 1997 07:27:52 +0800 (GMT) Edward M Greshko wrote: > Of course this is not quite related to SMTP...... good. see below. > There is a quote by someone from a time long ago which goes along the > lines of being conservative in what you generate and liberal in what you > receive. In other words, make sure that you follow the specs to the > letter in what you generate, however try to deal with anything reasonable > that you can anticipate being thrown your way. > > I need to know the exact quote and the author. If it is documented > someplace that would be "nice" too. As Tim Goodwin pointed out, the first written form of the comment (that I know of) is in RFC 1123. The quote itself is due to Jon Postel, a _lot_ earlier -- it has been floating around since the early 80s or earlier. As Tim suggests, you need to be quite careful about the quotation and its applicability. It was intended, more or less, as a "smoothing principle: Traditionally, we don't do precise specifications for Internet protocols, especially at the applications level. Instead, we have tried to make things easier to write and understand with less-than-precise syntax rules, a certain amount of handwaving about semantics, general assumptions about goodwill, etc. That is typically ok, if there is some rule about how to handle all of the ambiguities. The robustness principle was, more or less, intended to cover those cases, i.e., if it was possible to read a particular provision in different ways, the sender was expected to read it in the narrowest way feasible while the receiver was expected to give it the most relaxed and broad reading that was feasible. I.e., senders are required to read and follow the specs closely; receivers are to anticipate senders who don't. Virtually every time one looks at a terrible implementation of an Internet protocol that seems to work anyway, the underlying cause is proper behavior using the robustness principle. The problem is that it has been used to justify incredible nonsense, including software authors who have taken the position that receivers are obligated to accept any foolishness that is thrown at them (and therefore the sender is permitted to send such foolishness). That was never the intent, and some of us have argued in a number of specific cases for dropping the robustness principle in favor of a "if bad stuff comes in, bounce it" model, just on the grounds of cleaning up/ preserving the infrastructure. john From owner-ietf-smtp Wed Jul 16 19:44:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA03632 for ietf-smtp-bks; Wed, 16 Jul 1997 19:44:38 -0700 (PDT) Received: from calvin.twntpe.cdc.com (ip129179-17-10.a.cdc.com [129.179.17.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA03628 for ; Wed, 16 Jul 1997 19:44:33 -0700 (PDT) Received: from calvin.twntpe.cdc.com by calvin.twntpe.cdc.com; Thu, 17 Jul 1997 10:47:06 +0800 Date: Thu, 17 Jul 1997 10:47:06 +0800 (GMT) From: Edward M Greshko To: John C Klensin cc: ietf-smtp@imc.org Subject: Re: Need the quote and the author In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk On Sun, 13 Jul 1997, John C Klensin wrote: > As Tim Goodwin pointed out, the first written form of the > comment (that I know of) is in RFC 1123. The quote itself > is due to Jon Postel, a _lot_ earlier -- it has been > floating around since the early 80s or earlier. Thanks. I did find Jon's original musing on the subject. > As Tim suggests, you need to be quite careful about the > quotation and its applicability. It was intended, more or > less, as a "smoothing principle: Traditionally, we don't > do precise specifications for Internet protocols, > especially at the applications level. Instead, we have > tried to make things easier to write and understand with > less-than-precise syntax rules, a certain amount of > handwaving about semantics, general assumptions about > goodwill, etc. That is typically ok, if there is some > rule about how to handle all of the ambiguities. The > robustness principle was, more or less, intended to cover > those cases, i.e., if it was possible to read a particular > provision in different ways, the sender was expected to > read it in the narrowest way feasible while the receiver > was expected to give it the most relaxed and broad reading > that was feasible. I.e., senders are required to read and > follow the specs closely; receivers are to anticipate > senders who don't. Virtually every time one looks at a > terrible implementation of an Internet protocol that seems > to work anyway, the underlying cause is proper behavior > using the robustness principle. > > The problem is that it has been used to justify incredible > nonsense, including software authors who have taken the > position that receivers are obligated to accept any > foolishness that is thrown at them (and therefore the > sender is permitted to send such foolishness). That was > never the intent, and some of us have argued in a number of > specific cases for dropping the robustness principle in > favor of a "if bad stuff comes in, bounce it" model, just > on the grounds of cleaning up/ preserving the > infrastructure. Your points, and Tim's, are very well taken as I can certainly see how a general statment like that can be taken to the *extreme*. -- Edward M. Greshko Technical Manager, Electronic Commerce Control Data Asia/Pacific Region Voice: +886-2-715-2222 x287 6/F, 131 Nanking East Road, Section 3 FAX : +886-2-712-9197 Taipei, Taiwan R.O.C From owner-ietf-smtp Mon Sep 8 00:12:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA23151 for ietf-smtp-bks; Mon, 8 Sep 1997 00:12:28 -0700 (PDT) Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA23142 for ; Mon, 8 Sep 1997 00:12:21 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP id JAA04348; Mon, 8 Sep 1997 09:13:20 +0200 (MET DST) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 7 Sep 1997 17:18:29 +0200 To: Edward M Greshko , ietf-smtp@imc.org From: Jacob Palme Subject: Re: Need the quote and the author Sender: owner-ietf-smtp@imc.org Precedence: bulk At 07.27 +0800 97-07-11, Edward M Greshko wrote: > Hi, > > Of course this is not quite related to SMTP...... > > There is a quote by someone from a time long ago which goes along the > lines of being conservative in what you generate and liberal in what you > receive. In other words, make sure that you follow the specs to the > letter in what you generate, however try to deal with anything reasonable > that you can anticipate being thrown your way. > > I need to know the exact quote and the author. If it is documented > someplace that would be "nice" too. > > Ed ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Mon Sep 8 05:34:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA27495 for ietf-smtp-bks; Mon, 8 Sep 1997 05:34:09 -0700 (PDT) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA27491 for ; Mon, 8 Sep 1997 05:34:06 -0700 (PDT) Received: by callandor.cybercash.com; id IAA11821; Mon, 8 Sep 1997 08:21:17 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma011794; Mon, 8 Sep 97 08:21:05 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA13777; Mon, 8 Sep 97 08:28:06 EDT Date: Mon, 8 Sep 1997 08:28:05 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Jacob Palme Cc: Edward M Greshko , ietf-smtp@imc.org Subject: Re: Need the quote and the author In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk I think this may be an echo of an old message. In any case, while it's not the first occurance of this, it's documented in RFC 1958, Architectural Principles of the Internet. Donald On Sun, 7 Sep 1997, Jacob Palme wrote: > Date: Sun, 7 Sep 1997 17:18:29 +0200 > From: Jacob Palme > To: Edward M Greshko , ietf-smtp@imc.org > Subject: Re: Need the quote and the author > > At 07.27 +0800 97-07-11, Edward M Greshko wrote: > > Hi, > > > > Of course this is not quite related to SMTP...... > > > > There is a quote by someone from a time long ago which goes along the > > lines of being conservative in what you generate and liberal in what you > > receive. In other words, make sure that you follow the specs to the > > letter in what you generate, however try to deal with anything reasonable > > that you can anticipate being thrown your way. > > > > I need to know the exact quote and the author. If it is documented > > someplace that would be "nice" too. > > > > Ed > ------------------------------------------------------------------------ > Jacob Palme (Stockholm University and KTH) > for more info see URL: http://www.dsv.su.se/~jpalme ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html WARNING, on 1 Oct 1997, +1-508 may change to +1-978. From owner-ietf-smtp Tue Oct 14 08:00:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA11506 for ietf-smtp-bks; Tue, 14 Oct 1997 08:00:26 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA11499 for ; Tue, 14 Oct 1997 08:00:16 -0700 (PDT) Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 14 Oct 1997 11:00:05 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 14 Oct 1997 11:00:04 -0400 Message-Id: <3.0.1.32.19971014110607.00b3e390@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 14 Oct 1997 11:06:07 -0400 To: ietf-smtp@imc.org From: "Jack De Winter" Subject: would like some verification on 8BITMIME and RFC1652 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk hey all. was just trying to debug a problem with our site connecting to MSN.COM. Following RFC1652, the RFC on 8BITMIME use in ESMTP, when we have a 7 bit message, we place "BODY=7BIT" as the last parameter in the FROM LINE, such as: MAIL FROM: SIZE=1169 BODY=7BIT Now, whenever we send mail to MSN.COM in that manner, it is refused as an illegal command, even though it says it supports ESMTP's 8BITMIME. Furthermore, if the lines: MAIL FROM: SIZE=1169 BODY=8BITMIME or MAIL FROM: SIZE=1169 are used, the command is accepted with no problems. Now, my understanding of RFC 1652 is that if you do support 8BITMIME, you should be sending "BODY=7BIT". Could people verify this and let me know if msn.com should be able to accept the "BODY=7BIT" tag or if is okay that it does not? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/) From owner-ietf-smtp Tue Oct 14 08:42:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA12450 for ietf-smtp-bks; Tue, 14 Oct 1997 08:42:05 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA12446 for ; Tue, 14 Oct 1997 08:42:00 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IOSH221QAO9JD4JC@INNOSOFT.COM> for ietf-smtp@imc.org; Tue, 14 Oct 1997 08:44:22 PDT Date: Tue, 14 Oct 1997 08:37:51 -0700 (PDT) From: Ned Freed Subject: Re: would like some verification on 8BITMIME and RFC1652 In-reply-to: "Your message dated Tue, 14 Oct 1997 11:06:07 -0400" <3.0.1.32.19971014110607.00b3e390@lacroix.wildbear.on.ca> To: Jack De Winter Cc: ietf-smtp@imc.org Message-id: <01IOSHFS5JNK9JD4JC@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smtp@imc.org Precedence: bulk > hey all. was just trying to debug a problem with our site > connecting to MSN.COM. Following RFC1652, the RFC on 8BITMIME > use in ESMTP, when we have a 7 bit message, we place > "BODY=7BIT" as the last parameter in the FROM LINE, such as: > MAIL FROM: SIZE=1169 BODY=7BIT > Now, whenever we send mail to MSN.COM in that manner, it is > refused as an illegal command, even though it says it supports > ESMTP's 8BITMIME. Furthermore, if the lines: > MAIL FROM: SIZE=1169 BODY=8BITMIME > or > MAIL FROM: SIZE=1169 > are used, the command is accepted with no problems. > Now, my understanding of RFC 1652 is that if you do support 8BITMIME, > you should be sending "BODY=7BIT". I don't see anything like this in RFC1652. What I do see is an optional MAIL FROM parameter called BODY, which can be used to indicate whether or not a message is in 7bit form or 8bitMIME form. Nowhere do I see a recommendation that the BODY=7bit version, which is the default, should be used when sending a 7bit message. You can do it if you want to, but you're not required to. > Could people verify this and let me know if msn.com should be able > to accept the "BODY=7BIT" tag or if is okay that it does not? Different question, for which the answer is yes, they should be able to handle your sending body=7bit. That they do not is a bug, plain and simple. Unfortunately it is small beer compared to the inability to handle quoting sequences in NOTARY MAIL FROM parameters, a bug present in some widely deployed versions of MS Exchange. Ned From owner-ietf-smtp Fri Mar 13 14:45:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA17685 for ietf-smtp-bks; Fri, 13 Mar 1998 14:45:04 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA17676; Fri, 13 Mar 1998 14:44:54 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA11000; Fri, 13 Mar 1998 14:43:31 -0800 (PST) Received: from wkrp ([205.217.228.35]) by dredd.mcom.com (Netscape Messaging Server 3.5) with SMTP id AAA2606; Fri, 13 Mar 1998 14:43:30 -0800 Message-ID: <3509B67B.6BFF@netscape.com> Date: Fri, 13 Mar 1998 14:43:07 -0800 From: Hans Lachman Reply-To: ietf-smtp@imc.org X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ietf-smtp@imc.org, ldap@umich.edu CC: Jeff.Hodges@stanford.edu, bbense@networking.stanford.edu, Bob.Morgan@stanford.edu, mark@lucent.com, phoffman@imc.org Subject: Mail Routing and LDAP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Various people have implemented various approaches for LDAP-based Routing of SMTP Messages. At least three are commonly known: 1. UMich's approach (implemented in the "mail500" mailer) 2. Netscape's approach (implemented in the Netscape MTA) 3. Stanford's approach (implemented in Sendmail 8.8.X) There are internet drafts available describing the latter two approaches.. draft-lachman-ldap-mail-routing-01.txt (http://www.imc.org/draft-lachman-ldap-mail-routing) draft-ietf-asid-email-routing-su-00.txt (http://www.imc.org/draft-ietf-asid-email-routing-su) (expired, but an update is planned) We propose to discuss the merits of the various approaches and determine whether there is interest in standardizing an approach to LDAP-based Routing of SMTP Messages. The discussion will be held on... ietf-smtp@imc.org Information about subscribing, a list archive, and current discussion topics is available at... http://www.imc.org/ietf-smtp/ All people interested in this topic are invited to join in the discussion. Regards, Jeff Hodges & Hans Lachman From owner-ietf-smtp Fri Mar 13 17:43:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA18741 for ietf-smtp-bks; Fri, 13 Mar 1998 17:43:34 -0800 (PST) Received: from mail2.uts.ohio-state.edu (root@mail2.uts.ohio-state.edu [128.146.214.31]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA18737 for ; Fri, 13 Mar 1998 17:43:33 -0800 (PST) Received: from osu.edu (workerb1.us.ohio-state.edu [128.146.91.178]) by mail2.uts.ohio-state.edu (8.8.8/8.8.8) with ESMTP id UAA10258 for ; Fri, 13 Mar 1998 20:42:26 -0500 (EST) Message-ID: <3509E098.803F409E@osu.edu> Date: Fri, 13 Mar 1998 20:42:48 -0500 From: Darryl C Price Organization: The Ohio State University X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 i86pc) MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: Mail Routing and LDAP References: <3509B67B.6BFF@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Hans, Please add Innosoft International's PMDF MTA to this list. It is a product that I for one recommend highly. .... And no, I don't work for them. Darryl Price University Technology Services The Ohio State University Hans Lachman wrote: > Various people have implemented various approaches for LDAP-based > Routing of SMTP Messages. At least three are commonly known: > > 1. UMich's approach (implemented in the "mail500" mailer) > 2. Netscape's approach (implemented in the Netscape MTA) > 3. Stanford's approach (implemented in Sendmail 8.8.X) > > There are internet drafts available describing the latter two > approaches.. > > draft-lachman-ldap-mail-routing-01.txt > (http://www.imc.org/draft-lachman-ldap-mail-routing) > > draft-ietf-asid-email-routing-su-00.txt > (http://www.imc.org/draft-ietf-asid-email-routing-su) > (expired, but an update is planned) > > We propose to discuss the merits of the various approaches and > determine whether there is interest in standardizing an approach to > LDAP-based Routing of SMTP Messages. The discussion will be held on... > > ietf-smtp@imc.org > > Information about subscribing, a list archive, and current discussion > topics is available at... > > http://www.imc.org/ietf-smtp/ > > All people interested in this topic are invited to join in the > discussion. > > Regards, > > Jeff Hodges & Hans Lachman From owner-ietf-smtp Sat Mar 14 01:41:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id BAA10132 for ietf-smtp-bks; Sat, 14 Mar 1998 01:41:33 -0800 (PST) Received: from whiskey.poste.com ([24.112.113.88]) by mail.proper.com (8.8.8/8.7.3) with SMTP id BAA10126 for ; Sat, 14 Mar 1998 01:41:31 -0800 (PST) Received: from sl by whiskey.poste.com with local (Exim 1.736 #2) id 0yDnSW-00009o-00; Sat, 14 Mar 1998 01:42:28 -0800 Message-ID: <19980314014228.63678@poste.com> Date: Sat, 14 Mar 1998 01:42:28 -0800 From: Stuart Lynne To: ietf-smtp@imc.org Subject: Re: Mail Routing and LDAP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Stuart Lynne, Poste on Sat, Mar 14, 1998 at 01:25:50AM -0800 Sender: owner-ietf-smtp@imc.org Precedence: bulk > > Various people have implemented various approaches for LDAP-based > Routing of SMTP Messages. At least three are commonly known: > > 1. UMich's approach (implemented in the "mail500" mailer) > 2. Netscape's approach (implemented in the Netscape MTA) > 3. Stanford's approach (implemented in Sendmail 8.8.X) There will be a generic ldap: lookup mechanism in the next major release of exim (currently available for testing). It allows ldap to be used for any data lookup by specifying a standard LDAP URL. There are two different search modes available. One for use when you expect a single entry to be returned and multiple entries are an error (although it permits multiple values from a single entry). And a second that allows for multiple entries (each with multiple values). Exim supports various lookup mechanism's, flat file, dbm, db, NIS, NIS+ and now LDAP. For the most part any lookup type can be used wherever a lookup can be specified. So for example spam filter lists, host relay control lists, and many other configuration items could be brought in via LDAP. The following exim router configuration will utilize ldap to search for a user with a mail attribute and then use the mailforwardingattribute to determine what to do with it (using the older Netscape mailrecipient definition). virtual_fireplug_net_aliasfile_ldap: condition = "${if match{$self_hostname}{virtual..fireplug.net}{$domain}}" driver = aliasfile; search_type = ldap, expand, errors_to = sl@whiskey.poste.com queries = "ldap:://wilt.fireplug.net/?mailforwardingaddress?sub?(&(mail=$local_part@$domain)(ou=accounts)):\ ldap:://wilt.fireplug.net/?mailforwardingaddress?sub?(&(mail=\\\\2a@$domain)(ou=accounts))" This is in use here using the older Netscape definition for mailrecipient. I'll have to re-deploy and try out the newer version of mailrecipient and which probably means just converting to MailRoutingAddress and adding provision for the mailHost attribute (which I currently don't use). I've been trying variations on the Netscape approach for the last six months or so. I'm basically happy with the it. -- Stuart Lynne 604-916-4741 PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 88 EC A3 EE 2D 1C 15 68 From owner-ietf-smtp Thu Mar 19 16:53:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA04889 for ietf-smtp-bks; Thu, 19 Mar 1998 16:53:18 -0800 (PST) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA04885 for ; Thu, 19 Mar 1998 16:53:17 -0800 (PST) Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id TAA10314; Thu, 19 Mar 1998 19:52:54 -0500 (EST) Message-Id: <199803200052.TAA10314@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ietf-smtp@imc.org Subject: Re: Mail Routing and LDAP In-reply-to: Your message of "Fri, 13 Mar 1998 14:43:07 PST." <3509B67B.6BFF@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Mar 1998 19:52:53 -0500 Sender: owner-ietf-smtp@imc.org Precedence: bulk > We propose to discuss the merits of the various approaches and > determine whether there is interest in standardizing an approach to > LDAP-based Routing of SMTP Messages. I think this is a good idea, *provided* that this is a purely local thing - hosts outside your domain still route mail using MX records rather than using the LDAP server. Keith From owner-ietf-smtp Thu Mar 19 20:32:22 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA06471 for ietf-smtp-bks; Thu, 19 Mar 1998 20:32:22 -0800 (PST) Received: from algw2.lucent.com (algw2.lucent.com [205.147.213.2]) by mail.proper.com (8.8.8/8.7.3) with SMTP id UAA06467 for ; Thu, 19 Mar 1998 20:32:21 -0800 (PST) Received: from clipper.cb.lucent.com by alig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id XAA11339; Thu, 19 Mar 1998 23:39:37 -0500 Received: by clipper.cb.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id XAA23217; Thu, 19 Mar 1998 23:27:33 -0500 Received: from lucent.com by clipper.cb.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id XAA23214; Thu, 19 Mar 1998 23:27:30 -0500 Message-ID: <3511F008.701100B0@lucent.com> Date: Thu, 19 Mar 1998 23:26:48 -0500 From: Mark Horton Organization: Lucent Technologies X-Mailer: Mozilla 4.05C-EMS-1.3.1 [en] (X11; U; SunOS 5.6 sun4m) MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: Mail Routing and LDAP References: <19980314014228.63678@poste.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk > > 1. UMich's approach (implemented in the "mail500" mailer) > > 2. Netscape's approach (implemented in the Netscape MTA) > > 3. Stanford's approach (implemented in Sendmail 8.8.X) There is another approach which I think is worth consideration. Bell Labs has been using it for about 10 years now, and it's been extremely popular. We're doing it with a proprietary protocol called POST, with a relational database, but the same concepts and functionality would seem well suited to LDAP. Indeed, we'd like to migrate to LDAP but keep this functionality, and it won't work unless this is somewhat standardized. (1) Deliver atom@lucent.com by looking it up in the directory, and delivering to the physical address found in the directory. (2) Pass directory.query@lucent.com (anything with syntax containing dot, equals, slash, colon, or underscore, followed by @lucent.com) to the directory lookup to match one or more possible people and deliver to their physical addresses. Examples of our current syntax: (my directory entry is "Mark R Horton".) Mark.R.Horton@lucent.com (full name match) Mark.Horton@lucent.com (partial name match) M.R.Horton@lucent.com (partial name match) m.horton@lucent.com (ambiguous - return to sender) mark@lucent.com (looks up based on "id" field, see (1) above) mark.horton/state=oh@lucent.com ou=bl0311100/all=y@lucent.com (broadcast to all in department) tl=tmgr/loc=oh0012/all=y@lucentcom (broadcast to all tech mgrs in bldg oh0012) state=nj/all=y@lucent.com (too many people - send to human moderator) (all=y says user intends to match > 1 person and this is OK. Upper/lower case is ignored. . and _ mean the same thing, : and / mean same thing.) This is a very powerful system. Most users depend on it to broadcast to everybody in a building, or in a geographic area, or in an organizational unit. But if we decided to implement an attribute called shoesize, a user could send mail to everyone with shoesize=8 without any special coding or mods to the mail system. We can't anticipate all the combinations that users want, but with this system, we don't have to - they all work. Note that this uses standard SMTP and is interpreted locally, so it does not depend on special URLs or changes to somebody else's mail system. Note also that this does *not* force mail to be routed through one machine called "lucent.com". "lucent.com" is a domain, not a machine. Any machine inside the domain can do the LDAP lookup and deliver directly. Any machine outside the domain will follow MX records to get into the domain at some point, not necessarily always the same point. Machines inside the domain that don't understand the protocol will also follow (possibly different) MX records. And note that, because of the client/server nature of LDAP, it is not necessary to have a separate copy of the directory on every mail server, so you don't have to spend all your resources doing directory synch. Have just enough LDAP servers to handle the load and be redundant - we have 3 POST servers to handle hundreds of mail servers in Lucent. What it does require, if you're going to use standards-based components, then the LDAP client (MTA) and LDAP server have to agree on a few things. Most notably, they must agree on two standard attributes: the high-level user-visible mail address (such as "mark@lucent.com") and the physical address specifying the mail server ("mark@clipper.cb.lucent.com") The job of the MTA, even in the simplest case (1 above) is to take a high-level name, look it up in the directory, and get back the physical address so it can route the mail there. For example, the first could be called "mail" and the second "MailForwardingAddress". Or it could look for attribute "id" value "mark", and still return a MailForwardingAddress. At a bare minimum, we need to agree on these two attributes. We could go further and declare RFC-xxxx which specifies the above syntax, lets each implementation define their own attributes. The RFC would have to say something about broadcasts, and define the semantics of "and" and "or". (Our implementation is simple: multiple values of the same attribute are "ored" together, different attributes are "anded". This works well in practice.) Let me say a few words about broadcasts. The normal behavior if you type something ambiguous, like "m.horton@lucent.com" which matches Mark, Mary, Matt,... is to reject it - we assume the user made an error and should have been more specific. So if the query matches more than 1 person, we return it to sender (or, ideally, refuse the SMTP so the client can offer an opportunity to fix it.) But sometimes you want to broadcast to everybody whose title is "peon". tl=peon@lucent.com would be ambiguous and would bounce. So we put in an "all=yes" or "all=y" attribute, which forces the user to say "yes, dammit, I really wanted to do that" and let the broadcast go through. Thus, tl=peon/all=y@lucent.com goes to all the peons. We've also found we have to guard against broadcast storms. When you send mail to 20,000 people by accident (and people do this routinely), if you don't do anything to prevent it, you get the same old pattern: A: Hi, all! I'm back! B: Welcome back, A! C: Who's A? D: Stop sending all this mail to 20,000 people! E: Take me off this mailing list. F: Take me off, too. G-Z: Me too. Our solution to this problem is to implement a limit. The limit is has a default (2500 in our case), and can be changed by authorized senders or in the MTA configuration. When a broadcast is expanded by the MTA, the number of matches is counted. If it exceeds the limit, we silently forward the message to a configurable Internet e-mail address, the moderator. (Another implementation is to just reject the mail, but there are often legitimate needs to exceed the limits.) The moderator address goes to a person or group whose job is to read such messages and make a judgement whether it's a reasonable message and audience. For the 95% that are reasonable, they are passed back to the MTA with a higher limit. For the mistakes, local policy is followed (we phone the sender and ask if they really wanted to do that, usually they thank us profusely for catching their mistake.) Our system works very well in practice. Lucent has about 160,000 people in our directory. We've been supporting this type of e-mail delivery for over 10 years, in full production. We had enough faith in the system to decree two years ago that all employees use the handle@lucent.com address form, which always causes a directory lookup. We haven't regretted it, except that existing vendors of e-mail products don't support it as well as our internally developed system. Perhaps with an RFC we'll all be able to reap the benefits of LDAP-based mail delivery. Mark From owner-ietf-smtp Fri Mar 20 21:59:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA29079 for ietf-smtp-bks; Fri, 20 Mar 1998 21:59:29 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA29075 for ; Fri, 20 Mar 1998 21:59:27 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA03861 for ; Fri, 20 Mar 1998 21:58:42 -0800 (PST) Received: from wkrp ([205.217.228.35]) by dredd.mcom.com (Netscape Messaging Server 3.52) with SMTP id AAA84; Fri, 20 Mar 1998 21:58:41 -0800 Message-ID: <3513570D.5EBF@netscape.com> Date: Fri, 20 Mar 1998 21:58:37 -0800 From: Hans Lachman X-Mailer: Mozilla 3.0GoldC (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mark Horton CC: ietf-smtp@imc.org Subject: Re: Mail Routing and LDAP References: <19980314014228.63678@poste.com> <3511F008.701100B0@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Mark Horton wrote: ... > (1) Deliver atom@lucent.com by looking it up in the directory, > and delivering to the physical address found in the directory. > > (2) Pass directory.query@lucent.com (anything with syntax containing > dot, equals, slash, colon, or underscore, followed by @lucent.com) to the > directory lookup to match one or more possible people and deliver to > their physical addresses. ... > What it does require, if you're going to use standards-based components, > then the LDAP client (MTA) and LDAP server have to agree on a few things. > Most notably, they must agree on two standard attributes: the high-level > user-visible mail address (such as "mark@lucent.com") and the physical > address specifying the mail server ("mark@clipper.cb.lucent.com") > The job of the MTA, even in the simplest case (1 above) is to take a > high-level name, look it up in the directory, and get back the physical > address so it can route the mail there. For example, the first could be > called "mail" and the second "MailForwardingAddress". Or it could look > for attribute "id" value "mark", and still return a MailForwardingAddress. > At a bare minimum, we need to agree on these two attributes. I agree that this would be the bare minimum to standardize (if any of this is standardized at all). This would allow different vendors' MTAs within an organization to do direct routing to each other, as least for case (1). Some vendors might still want to implement different approaches for whatever reason, but I think there's value in trying to standardize this at some level. The 'mail' attribute seems to be the choice for the high-level user-visible address. As for the physical delivery address, I'd rather not use 'mailForwardingAddress' since we're already using that for "forwarding" (one account forwarding its mail to one or more other accounts; typically user-controlled, like the ".forward" file), which we consider to be different from "routing" (getting the mail to the account in question; typically administrator- controlled, like putting routing aliases in the sendmail aliases file). For "routing" we have an attribute called 'mailRoutingAddress'. Our MTA expects that this contains the physical delivery address (although it's optional if 'mailHost' is set, since we can route based on that). For case (2) it may be a little harder to get consensus among MTA vendors. Regarding doing address matching against the 'cn' attribute, we instead provide an attribute 'mailAlternateAddress' to explicitly set the user's additional email addresses (beyond the one in their 'mail' attribute). This makes uniqueness checking fairly easy, and also avoids "unexpected loss of service" cases due to someone else getting the same 'cn'. I understand this was a problem in some places that had something like the 'cn' matching functionality. By the way, the L.A. IETF meeting is coming up. If you (or anyone else interested in this) are going, maybe we should find a way to hook up. -- Hans From owner-ietf-smtp Sat Mar 21 21:03:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA00941 for ietf-smtp-bks; Sat, 21 Mar 1998 21:03:43 -0800 (PST) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA00937 for ; Sat, 21 Mar 1998 21:03:42 -0800 (PST) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id AAA21026 for ; Sun, 22 Mar 1998 00:03:17 -0500 Message-Id: <199803220503.AAA21026@black-ice.cc.vt.edu> To: ietf-smtp@imc.org Subject: Max RCPT TO: - option to negotiate? From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="" X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Date: Sun, 22 Mar 1998 00:03:17 -0500 Sender: owner-ietf-smtp@imc.org Precedence: bulk Sendmail 8.9.0 (currently in beta test) supports a local configuration option to limit the maximum number of RCPT TOs as documented thusly: confMAX_RCPTS_PER_MESSAGE MaxRecipientsPerMessage [infinite] If set, allow no more than the specified number of recipients in an SMTP envelope. Further recipients receive a 452 error code (i.e., they are deferred for the next delivery attempt). Does anybody see a need/desire/etc for an ESMTP option to advertise this limit, so the upstream end can avoid sending a RCPT TO: that will just get 452'd anyhow? Straw man proposal: 250-MAXRECIP nnn to state that more than nnn receipts will not be accepted. Comments? Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech From owner-ietf-smtp Mon Mar 23 06:04:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA08592 for ietf-smtp-bks; Mon, 23 Mar 1998 06:04:05 -0800 (PST) Received: from lupinella.troll.no (lupinella.troll.no [195.0.254.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA08584 for ; Mon, 23 Mar 1998 06:03:36 -0800 (PST) Received: by troll.no id <79577-3035>; Mon, 23 Mar 1998 15:02:59 +0100 To: Valdis.Kletnieks@vt.edu Cc: ietf-smtp@imc.org Subject: Re: Max RCPT TO: - option to negotiate? References: <199803220503.AAA21026@black-ice.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: Arnt Gulbrandsen Date: 23 Mar 1998 15:02:49 +0100 In-Reply-To: Valdis.Kletnieks@vt.edu's message of "Sun, 22 Mar 1998 00:03:17 -0500" Message-ID: Lines: 16 Sender: owner-ietf-smtp@imc.org Precedence: bulk Valdis.Kletnieks@vt.edu > Does anybody see a need/desire/etc for an ESMTP option to advertise > this limit, so the upstream end can avoid sending a RCPT TO: that > will just get 452'd anyhow? > > Straw man proposal: > > 250-MAXRECIP nnn to state that more than nnn receipts will not be accepted. FWIW, Zmailer says X-RCPTLIMIT n for some n, but I don't know what its SMTP response is after n RCPT TO commands. It -is- protocol bloat, and with ESMTP pipelining the extra commands aren't terribly expensive, so it sounds marginal. --Arnt From owner-ietf-smtp Mon Mar 23 07:31:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA09341 for ietf-smtp-bks; Mon, 23 Mar 1998 07:31:29 -0800 (PST) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA09337 for ; Mon, 23 Mar 1998 07:31:28 -0800 (PST) Received: from black-ice.cc.vt.edu (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id KAA20050; Mon, 23 Mar 1998 10:31:08 -0500 Message-Id: <199803231531.KAA20050@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: Arnt Gulbrandsen Cc: ietf-smtp@imc.org Subject: Re: Max RCPT TO: - option to negotiate? In-Reply-To: Your message of "23 Mar 1998 15:02:49 +0100." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_634613760P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 23 Mar 1998 10:31:03 -0500 Sender: owner-ietf-smtp@imc.org Precedence: bulk --==_Exmh_634613760P Content-Type: text/plain; charset=us-ascii On 23 Mar 1998 15:02:49 +0100, Arnt Gulbrandsen said: > It -is- protocol bloat, and with ESMTP pipelining the extra commands > aren't terribly expensive, so it sounds marginal. Sendmail 8.9.0 won't have pipelining, so it DOES mean an extra whole round trip per additional RCPT TO:. Out of curiosity, what MTA's currently support SMTP pipelining, and what percentage market share do they currently have in total? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_634613760P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNRaANtQBOOoptg9JAQGSEwP9EGSDcVdtbiHxQ7gIuv2sWSVAyjDT8ujV 9JjU8VvDf2I8Yrkj8EtAfw266gCSTIBm9K0/EhbF9Df8fquC1nAbTNyge1Pjov1m 414EY31ZXp+q0UN4yk7zPwwQ4goz30nDvE43oIrruULd7QQ9S4KaQeO8xqKtUzh/ lZRHwCcph5Q= =oppG -----END PGP MESSAGE----- --==_Exmh_634613760P-- From owner-ietf-smtp Mon Mar 23 15:45:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA14534 for ietf-smtp-bks; Mon, 23 Mar 1998 15:45:32 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA14530 for ; Mon, 23 Mar 1998 15:45:31 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IV04A6ZJ3K8Y5K2G@INNOSOFT.COM> for ietf-smtp@imc.org; Mon, 23 Mar 1998 15:44:17 PST Date: Mon, 23 Mar 1998 15:19:04 -0800 (PST) From: Ned Freed Subject: Re: Max RCPT TO: - option to negotiate? In-reply-to: "Your message dated Mon, 23 Mar 1998 10:31:03 -0500" <199803231531.KAA20050@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: Arnt Gulbrandsen , ietf-smtp@imc.org Message-id: <01IV0EQNBWBG8Y5K2G@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk > Content-Type: text/plain; charset=us-ascii > > It -is- protocol bloat, and with ESMTP pipelining the extra commands > > aren't terribly expensive, so it sounds marginal. > Sendmail 8.9.0 won't have pipelining, so it DOES mean an extra > whole round trip per additional RCPT TO:. > Out of curiosity, what MTA's currently support SMTP pipelining, > and what percentage market share do they currently have in total? Ones I know of that do include: Innosoft's PMDF, software.com's Post.Office, ISOCOR's NPlex, SMail, and Qmail. Sendmail, Microsoft's Exchange SMTP enabler, Lotus Notes SMTP gateway, ISODE's PP, and MMDF do not as far as I know. (I believe the latter two actually don't implement ESMTP of any sort.) I've heard mixed reports about Pegasus Mail, possibly as a result of there being several different SMTP gateways for it. I've heard reports that the USDA's SMTP implementation in MUMPS supports pipelining, but cannot find an server to check out right now. I also suspect that Exchange, NOTES, and PP are "pipeline clean" but don't say so. Sendmail is the only MTA I know of that isn't "pipeline clean"; I understand this is an artefact of the way its implemented and not easily fixed. I have no data on market share, or at least none that I can post here. I can, however, say that we've observed that pipelining has improved throughput in many situations. BTW, I have no strong feeling either way about this extension. If someone specifies it I'll implement it in PMDF, if not I won't. Ned From owner-ietf-smtp Mon Mar 23 16:34:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA14849 for ietf-smtp-bks; Mon, 23 Mar 1998 16:34:14 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA14845 for ; Mon, 23 Mar 1998 16:34:13 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IV04A6ZJ3K8Y5K2G@INNOSOFT.COM> for ietf-smtp@imc.org; Mon, 23 Mar 1998 16:33:08 PST Date: Mon, 23 Mar 1998 16:28:35 -0800 (PST) From: Ned Freed Subject: Re: Max RCPT TO: - option to negotiate? In-reply-to: "Your message dated Mon, 23 Mar 1998 15:19:04 -0800 (PST)" <01IV0EQNBWBG8Y5K2G@INNOSOFT.COM> To: Ned Freed Cc: Valdis.Kletnieks@vt.edu, Arnt Gulbrandsen , ietf-smtp@imc.org Message-id: <01IV0GG7NKX08Y5K2G@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <199803231531.KAA20050@black-ice.cc.vt.edu> Sender: owner-ietf-smtp@imc.org Precedence: bulk > Ones I know of that do include: Innosoft's PMDF, software.com's Post.Office, > ISOCOR's NPlex, SMail, and Qmail. Sendmail, Microsoft's Exchange SMTP enabler, > Lotus Notes SMTP gateway, ISODE's PP, and MMDF do not as far as I know. (I > believe the latter two actually don't implement ESMTP of any sort.) I've heard > mixed reports about Pegasus Mail, possibly as a result of there being several > different SMTP gateways for it. I've heard reports that the USDA's SMTP > implementation in MUMPS supports pipelining, but cannot find an server to check > out right now. Some additions to the list: Cisco Multinet SMTP -- server supports pipelining, client doesn't take advantage of it. MX -- server supports it, client takes advantage of it. Process Software SMTP -- doesn't support EHLO and hence no pipelining. CDC Mail*Hub -- doesn't support EHLO and hence no pipelining. Thanks are due to Dan Wing for pointing out the first two. Ned From owner-ietf-smtp Thu Mar 26 16:41:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA28383 for ietf-smtp-bks; Thu, 26 Mar 1998 16:41:31 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA28379 for ; Thu, 26 Mar 1998 16:41:29 -0800 (PST) Received: from isode.com (actually woozle.isode.com) by woozle.isode.com with SMTP (local); Fri, 27 Mar 1998 00:40:55 +0000 To: Ned Freed cc: Arnt Gulbrandsen , ietf-smtp@imc.org Subject: Re: Max RCPT TO: - option to negotiate? In-reply-to: Your message of Mon, 23 Mar 1998 15:19:04 -0800. <01IV0EQNBWBG8Y5K2G@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27313.890959253.1@isode.com> Date: Fri, 27 Mar 1998 00:40:55 +0000 Message-ID: <27314.890959255@isode.com> From: Steve Kille Sender: owner-ietf-smtp@imc.org Precedence: bulk Ned, You write: > >> Out of curiosity, what MTA's currently support SMTP pipelining, >> and what percentage market share do they currently have in total? > >Lotus Notes SMTP gateway, ISODE's PP, and MMDF do not as far as I know. (I >believe the latter two actually don't implement ESMTP of any sort.) > >I also suspect that Exchange, NOTES, and PP are "pipeline clean" > but don't say so I noted the reference to Isode's PP (we do still call it PP, but for marketing purposes it goes under the title "Internet/X.400 Message Switch".) You are correct that PP does not implement SMTP pipelining and that it is "pipeline clean". I don't think we would claim pipelining unless we made the servers take advantage of it (not a big deal to code, but I can't see much benefit, although you would need it for this sort of extension). You are incorrect in your belief that PP does not implement ESMTP. We have supported ESMTP for some long while and continue to add ESMTP extensions. However, the current relase (not the release which is about to ship) can be built with ESMTP turned off, so you will see deployed systems which appear not to have ESMTP. Steve Kille CEO, Isode From owner-ietf-smtp Fri Mar 27 10:32:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA22071 for ietf-smtp-bks; Fri, 27 Mar 1998 10:32:48 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA22067 for ; Fri, 27 Mar 1998 10:32:47 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IV5KK18ODS984IV4@INNOSOFT.COM> for ietf-smtp@imc.org; Fri, 27 Mar 1998 10:31:50 PST Date: Fri, 27 Mar 1998 10:25:44 -0800 (PST) From: Ned Freed Subject: Re: Max RCPT TO: - option to negotiate? In-reply-to: "Your message dated Fri, 27 Mar 1998 00:40:55 +0000" <27314.890959255@isode.com> To: Steve Kille Cc: Ned Freed , Arnt Gulbrandsen , ietf-smtp@imc.org Message-id: <01IV5OZNIU16984IV4@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <"01IV0EQNBWBG8Y5K2G"@INNOSOFT.COM> Sender: owner-ietf-smtp@imc.org Precedence: bulk > I noted the reference to Isode's PP (we do still call it PP, but for > marketing purposes it goes under the title "Internet/X.400 Message Switch".) I hope you won't mind if I continue to refer to it as PP. I don't call PMDF by its marketing name either, for that matter. > You are correct that PP does not implement SMTP pipelining and that it > is "pipeline clean". I don't think we would claim pipelining unless > we made the servers take advantage of it (not a big deal to code, but > I can't see much benefit, although you would need it for this sort of > extension). Um, this demonstrates a misunderstanding of the benefits of pipelining. A server that claims pipelining but _clients_ are the ones that take advantage of it. As such, it is beneficial to the community for a pipeline-clean server to claim pipelining even if the client in the same software package doesn't take advantage of it (yet). And if you don't see the advantage, well, I would suggest that you do some additional timing of SMTP behavior on high latency links. Pipelining often makes a significant difference. > You are incorrect in your belief that PP does not implement ESMTP. We > have supported ESMTP for some long while and continue to add ESMTP > extensions. However, the current relase (not the release which is > about to ship) can be built with ESMTP turned off, so you will see > deployed systems which appear not to have ESMTP. Then you might want to consider enabling it on the version of PP that serves isode.com. Both it and the half-dozen other PP servers I tested did not offer ESMTP support. Ned From owner-ietf-smtp Thu Apr 2 11:27:27 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA07392 for ietf-smtp-bks; Thu, 2 Apr 1998 11:27:27 -0800 (PST) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA07388 for ; Thu, 2 Apr 1998 11:27:26 -0800 (PST) Received: from isode.com (actually woozle.isode.com) by woozle.isode.com with SMTP (local); Thu, 2 Apr 1998 20:27:29 +0100 To: Ned Freed cc: Arnt Gulbrandsen , ietf-smtp@imc.org Subject: Re: Max RCPT TO: - option to negotiate? In-reply-to: Your message of Fri, 27 Mar 1998 10:25:44 -0800. <01IV5OZNIU16984IV4@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24800.891545248.1@isode.com> Date: Thu, 02 Apr 1998 20:27:29 +0100 Message-ID: <24801.891545249@isode.com> From: Steve Kille Sender: owner-ietf-smtp@imc.org Precedence: bulk Ned, >> I noted the reference to Isode's PP (we do still call it PP, but for >> marketing purposes it goes under the title "Internet/X.400 Message Switch".) > >I hope you won't mind if I continue to refer to it as PP. Of course not!! >Um, this demonstrates a misunderstanding of the benefits of pipelining. A >server that claims pipelining but _clients_ are the ones that take advantage of >it. As such, it is beneficial to the community for a pipeline-clean server to >claim pipelining even if the client in the same software package doesn't take >advantage of it (yet). Point taken. We'll get this change made and the server will claim pipelining in the next release. > >And if you don't see the advantage, well, I would suggest that you do some >additional timing of SMTP behavior on high latency links. Pipelining often >makes a significant difference. It will clearly make a big improvement on latency. How much does your experience suggest is helps on throughput? >Then you might want to consider enabling it on the version of PP that serves >isode.com. Both it and the half-dozen other PP servers I tested did not offer >ESMTP support. Will do > > Ned > Steve From owner-ietf-smtp Sun Apr 5 17:23:55 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA09837 for ietf-smtp-bks; Sun, 5 Apr 1998 17:23:55 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA09833 for ; Sun, 5 Apr 1998 17:23:44 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IVHDSJ5NWW984PEV@INNOSOFT.COM> for ietf-smtp@imc.org; Sun, 5 Apr 1998 17:23:21 PST Date: Sun, 05 Apr 1998 17:15:25 -0800 (PST) From: Ned Freed Subject: Re: Max RCPT TO: - option to negotiate? In-reply-to: "Your message dated Thu, 02 Apr 1998 20:27:29 +0100" <24801.891545249@isode.com> To: Steve Kille Cc: Ned Freed , Arnt Gulbrandsen , ietf-smtp@imc.org Message-id: <01IVINYZDAQQ984PEV@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <"01IV5OZNIU16984IV4"@INNOSOFT.COM> Sender: owner-ietf-smtp@imc.org Precedence: bulk > > And if you don't see the advantage, well, I would suggest that you do some > > additional timing of SMTP behavior on high latency links. Pipelining often > > makes a significant difference. > It will clearly make a big improvement on latency. How much does your > experience suggest is helps on throughput? FIguring how throughput is affected is much more difficult. It depends very much on an MTA's queue processing strategy and the fan-out of message destinations. For example, an MTA that enforces a small number of connections per destination handling traffic to a small number of destinations is likely to win big with pipelining. On the other hand, an MTA that doesn't pay attention to destinations and fires up lots of connections to a large number of destinations won't benefit much. But of course one can also argue that both of these MTA strategies have major problems with certain kinds of loads. In practice our customers tune things to process messages based on the mix of traffic they handle, not on the basis of making pipelining work better. In most cases we see pipelining give some benefit; it is rare for it to have no effect and equally rare for it to win big. Ned From owner-ietf-smtp Thu Apr 9 15:28:12 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA21759 for ietf-smtp-bks; Thu, 9 Apr 1998 15:28:12 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA21754 for ; Thu, 9 Apr 1998 15:28:09 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WbMailNT V3.0 beta 1 build 106); Thu, 9 Apr 1998 18:28:56 -0400 Message-Id: <3.0.1.32.19980409182843.007e94f0@lacroix.wildbear.on.ca> X-Sender: "Unverified" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 09 Apr 1998 18:28:43 -0400 To: ietf-smtp@imc.org From: "Jack De Winter" Subject: handling extraneous 500 level SMTP error codes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk just going through a couple of bounce messages that I have received back from mailing lists, and came across a couple of instances that cause me to question my responses. The first is responding to a MAIL FROM with a 551 ... ERROR 1 - call <#> for help. The second is responding to a RCPT TO with a 554 Could not read response from aliasd. Now, in both cases, I could not find (in 821 or 1123) the response codes listed for the commands. Matter of fact, user not local for MAIL FROM does not really make sense unless they have an anti-posting filter or something out in place. Seeing as this is list traffic, it really didnt make sense. The second case I can almost see treating this as I do thr 550 to 553 responses, which indicate failures with the particular address, but not sufficient to abort the connection (like mailbox full, etc.). So, any input there on how these 500 level response should be handled? current usage of any of these responses to these commands? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-smtp Fri Apr 10 06:50:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA12080 for ietf-smtp-bks; Fri, 10 Apr 1998 06:50:10 -0700 (PDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA12076 for ; Fri, 10 Apr 1998 06:50:09 -0700 (PDT) Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id JAA28938; Fri, 10 Apr 1998 09:50:21 -0400 Message-Id: <199804101350.JAA28938@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: "Jack De Winter" Cc: ietf-smtp@imc.org Subject: Re: handling extraneous 500 level SMTP error codes In-Reply-To: Your message of "Thu, 09 Apr 1998 18:28:43 EDT." <3.0.1.32.19980409182843.007e94f0@lacroix.wildbear.on.ca> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_167298264P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 10 Apr 1998 09:50:20 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk --==_Exmh_167298264P Content-Type: text/plain; charset=us-ascii On Thu, 09 Apr 1998 18:28:43 EDT, you said: > Now, in both cases, I could not find (in 821 or 1123) the response > codes listed for the commands. Matter of fact, user not local for > MAIL FROM does not really make sense unless they have an anti-posting > filter or something out in place. Seeing as this is list traffic, > it really didnt make sense. Well.. I often see stuff addressed to 'user@some.isp' going out, they've botched their MX entries, and it ends up being sent to a host that is *not* in the mood to forward it. The other common occurrence is when there's an *expired* mail forwarding in effect... > So, any input there on how these 500 level response should be > handled? current usage of any of these responses to these commands? Appendix E of RFC821 states: 5yz Permanent Negative Completion reply The command was not accepted and the requested action did not occur. The sender-SMTP is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the sender-SMTP to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status). Bottom line: If the reply code starts with a 5, and you dont know what the y and z values are supposed to mean, it's appropriate to insert a .WAV of Dr McCoy saying "Its dead, Jim"... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_167298264P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNS4jm9QBOOoptg9JAQHruAQAjUZhyjbR+6Tz2P9cUZXJUyZ66XHUgzJ1 gO/EmtWFYSBSRq556HXdL2T06RIj+CxTggC/2hXyW+0snZqtnfJjXliuvoYH5Skl DwNDnL2CmakPD8+6PtGXG7VI74U5sgLtaqDP2NMrFeLKgkW4CNxhCF8SaiZWB5WM NELb7hh9OKw= =nAsw -----END PGP MESSAGE----- --==_Exmh_167298264P-- From owner-ietf-smtp Fri Apr 10 11:16:41 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13690 for ietf-smtp-bks; Fri, 10 Apr 1998 11:16:41 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA13686 for ; Fri, 10 Apr 1998 11:16:40 -0700 (PDT) Message-Id: <199804101816.LAA13686@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Fri, 10 Apr 1998 11:16:20 -0700 To: ietf-smtp@imc.org From: Paul Hoffman / IMC Subject: List of ESMTP extensions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk Greetings again. IMC is going to be putting up a list of known ESMTP extensions, and I wanted to do a sanity check before I posted it on the Web site. If you don't see one below for which there is an RFC or Internet Draft, or see anything on the list below that isn't right, please let me know. Thanks! 8BITMIME|RFC 1652|8-bit MIME messages AUTH|draft-myers-smtp-auth|SMTP authentication CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server capabilities CHECKPOINT|RFC 1845|Restarting transmission CHUNKING|RFC 1830|Large and binary messages DSN|RFC 1891|Delivery status notifications ENHANCEDSTATUSCODES|RFC 2034|Enhanced status codes ETRN|RFC 1985|Starting remote message queue EXPN|RFC 821|Expand address HELP|RFC 821|Get help PIPELINING|RFC 2197|Command pipelining RELAY|draft-gellens-submit|Message submission SAML|RFC 821|Send and mail SEND|RFC 821|Send SESSION|draft-ietf-fax-smtp-session|Immediate delivery of messages SIZE|RFC 1870|Announce message size SOML|RFC 821|Send or mail STARTTLS|draft-hoffman-smtp-ssl|SMTP over TLS TURN|RFC 821|Switch client and host --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Fri Apr 10 11:45:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13881 for ietf-smtp-bks; Fri, 10 Apr 1998 11:45:08 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA13877 for ; Fri, 10 Apr 1998 11:45:06 -0700 (PDT) Received: (qmail 6073 invoked by uid 666); 10 Apr 1998 18:47:35 -0000 Date: 10 Apr 1998 18:47:35 -0000 Message-ID: <19980410184735.6071.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-smtp@imc.org Subject: Re: List of ESMTP extensions References: <199804101816.LAA13686@mail.proper.com> Sender: owner-ietf-smtp@imc.org Precedence: bulk See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX, VERB, and VRFY. There are also lots of X extensions that should be documented. > CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server capabilities I continue to be amazed at this proposal. Previous commentary: : CAPS has surpassed ETRN in the ``Most absurd use of port 25'' contest. : : Has anyone informed the authors that store-and-forward mail systems do : not provide an online end-to-end link from the receiver to the sender? : : Why would anyone even imagine putting this feature into SMTP? Is there : something wrong with today's public-information retrieval protocols? I : realize that ftpd and fingerd don't have enough hooks, but why not use : httpd? ---Dan Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html From owner-ietf-smtp Fri Apr 10 12:08:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA14024 for ietf-smtp-bks; Fri, 10 Apr 1998 12:08:31 -0700 (PDT) Received: from HQ.Cisco.COM (hq.cisco.com [171.71.67.16]) by mail.proper.com (8.8.8/8.7.3) with SMTP id MAA14020 for ; Fri, 10 Apr 1998 12:08:31 -0700 (PDT) Received: by HQ.Cisco.COM for ietf-smtp@imc.ORG; Fri, 10 Apr 1998 12:08:21 -0700 Date: Fri, 10 Apr 1998 12:08:21 -0700 From: Dan Wing To: ietf-smtp@imc.org Message-Id: <980410120821.203d525d@Cisco.COM> Subject: Re: List of ESMTP extensions Sender: owner-ietf-smtp@imc.org Precedence: bulk >See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX, >VERB, and VRFY. There are also lots of X extensions that should be >documented. RFC1869 seems to indicate that VRFY is required and thus doesn't need to be advertised in an EHLO response. >> CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server capabilities > >I continue to be amazed at this proposal. Previous commentary: > >: CAPS has surpassed ETRN in the ``Most absurd use of port 25'' contest. That's an honor. :-) >: Has anyone informed the authors that store-and-forward mail systems do >: not provide an online end-to-end link from the receiver to the sender? Yep, I'm aware of that. >: Why would anyone even imagine putting this feature into SMTP? Is there >: something wrong with today's public-information retrieval protocols? I >: realize that ftpd and fingerd don't have enough hooks, but why not use >: httpd? We will likely drop the proposal anyways in favor of draft-ietf-fax-mdn-features-01.txt, anyways, but if you're honestly interested in a justification for draft-ietf-fax-smtp-capabilities I can give you several. -Dan Wing From owner-ietf-smtp Fri Apr 10 12:48:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA14313 for ietf-smtp-bks; Fri, 10 Apr 1998 12:48:23 -0700 (PDT) Received: from dataarch-mail.mcit.com (dataarch-mail.mcit.com [166.35.80.199]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA14308 for ; Fri, 10 Apr 1998 12:48:22 -0700 (PDT) Received: from dataarch1.bos.mci.net (dataarch1.mcit.com) by DATAARCH-MAIL.MCIT.COM (PMDF V5.1-10 #28121) with SMTP id <01IVPKDEH76C000JX6@DATAARCH-MAIL.MCIT.COM> for ietf-smtp@imc.org; Fri, 10 Apr 1998 15:55:13 EDT Date: Fri, 10 Apr 1998 15:48:09 -0400 (Eastern Daylight Time) From: John C Klensin Subject: Re: List of ESMTP extensions In-reply-to: <980410120821.203d525d@Cisco.COM> To: Dan Wing Cc: ietf-smtp@imc.org Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.5 Build (42) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-smtp@imc.org Precedence: bulk On Fri, 10 Apr 1998 12:08:21 -0700 Dan Wing wrote: > >See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX, > >VERB, and VRFY. There are also lots of X extensions that should be > >documented. > > RFC1869 seems to indicate that VRFY is required and thus doesn't need > to be advertised in an EHLO response. That is correct. From owner-ietf-smtp Fri Apr 10 14:05:18 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA14718 for ietf-smtp-bks; Fri, 10 Apr 1998 14:05:18 -0700 (PDT) Received: from elektra.iris.com (elektra.iris.com [198.112.211.20]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA14714 for ; Fri, 10 Apr 1998 14:05:17 -0700 (PDT) From: Mike_Gagnon@iris.com Received: from arista.iris.com ([9.95.65.15]) by elektra.iris.com (Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) with SMTP id 852565E2.00742379; Fri, 10 Apr 1998 16:08:32 -0400 Received: by arista.iris.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852565E2.00741F23 ; Fri, 10 Apr 1998 17:08:21 -0400 X-Lotus-FromDomain: IRIS To: ietf-smtp@imc.org Message-ID: <852565E2.0073969E.00@arista.iris.com> Date: Fri, 10 Apr 1998 17:06:19 -0400 Subject: Re: List of ESMTP extensions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smtp@imc.org Precedence: bulk On the other hand, draft-ietf-drums-smtpupd-06.txt has this to say: Server implementations MUST support VRFY and SHOULD support EXPN. For security reasons, implementations MAY provide local installations a way to disable either or both of these commands through configuration options or the equivalent. When these commands are supported, they are not required to work across relays when relaying is supported. Since they were both optional in RFC 821, they MUST, if supported, be listed in the response to EHLO if service extensions are supported. >On Fri, 10 Apr 1998 12:08:21 -0700 Dan Wing > wrote: > >> >See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX, >> >VERB, and VRFY. There are also lots of X extensions that should be >> >documented. >> >> RFC1869 seems to indicate that VRFY is required and thus doesn't need >> to be advertised in an EHLO response. > >That is correct. From owner-ietf-smtp Fri Apr 10 15:43:46 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA15256 for ietf-smtp-bks; Fri, 10 Apr 1998 15:43:46 -0700 (PDT) Received: from dataarch-mail.mcit.com (dataarch-mail.mcit.com [166.35.80.199]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA15252 for ; Fri, 10 Apr 1998 15:43:45 -0700 (PDT) Received: from dataarch1.bos.mci.net (dataarch1.mcit.com) by DATAARCH-MAIL.MCIT.COM (PMDF V5.1-10 #28121) with SMTP id <01IVPQHQKTAY000IZ3@DATAARCH-MAIL.MCIT.COM> for ietf-smtp@imc.org; Fri, 10 Apr 1998 18:50:30 EDT Date: Fri, 10 Apr 1998 18:43:27 -0400 (Eastern Daylight Time) From: John C Klensin Subject: Re: List of ESMTP extensions In-reply-to: <852565E2.0073969E.00@arista.iris.com> To: Mike_Gagnon@iris.com Cc: klensin@mci.net, ietf-smtp@imc.org Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.5 Build (42) Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-smtp@imc.org Precedence: bulk On Fri, 10 Apr 1998 17:06:19 -0400 Mike_Gagnon@iris.com wrote: > On the other hand, draft-ietf-drums-smtpupd-06.txt has this to say: > > > Server implementations MUST support VRFY and SHOULD support EXPN. > For security reasons, implementations MAY provide local installations >... > is supported. Since they were both optional in RFC 821, they MUST, > if supported, be listed in the response to EHLO if service extensions > are supported. Gaak. This is simply