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 wrong, and the editor will go find his sword and fall on it. The text in section 5 of RFC 1869 (STD 10) is authoritative and VRFY is not listed as an extension/option because it is required. It will be corrected in the next version of the cited I-D. The theory here was that VRFY was promoted to "required" by RFC 1123, which was a long time before we did the ESMTP work. And, for what I hope are obvious reasons, we wanted a conforming 821/1123 server implementation to be able to conform to ESMTP simply by recognizing EHLO and returning what it would have returned to HELO... that meant no listed response for required functions. john From owner-ietf-smtp Fri Apr 10 18:33:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA16184 for ietf-smtp-bks; Fri, 10 Apr 1998 18:33:16 -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 SAA16179 for ; Fri, 10 Apr 1998 18:33:06 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IVPH1H5MV4984UGZ@INNOSOFT.COM> for ietf-smtp@imc.org; Fri, 10 Apr 1998 18:32:10 PDT Date: Fri, 10 Apr 1998 18:18:43 -0700 (PDT) From: Ned Freed Subject: Re: handling extraneous 500 level SMTP error codes In-reply-to: "Your message dated Thu, 09 Apr 1998 18:28:43 -0400" <3.0.1.32.19980409182843.007e94f0@lacroix.wildbear.on.ca> To: Jack De Winter Cc: ietf-smtp@imc.org Message-id: <01IVPPU0VJUS984UGZ@INNOSOFT.COM> 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. While I try and use documented codes in the code I write, I've never bought into the theory that servers which issue undocumented but structurally legal response codes are broken. RFC821 makes it quite clear that the response code set is intended to be extensible. It also makes it clear that interpretation of specific codes really isn't a good thing. > 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. People implement rejections at the MAIL FROM for all sorts of reasons. While I tend to regard such things as fairly problematic, the fact remains that doing this sort of thing is fairly popular and people believe they are well served by it. And I don't think clients have any business second guessing servers in this regard. For all you know this server has had a problem with mail that had the MAIL FROM address you are using and is perfectly justifid in blocking it. If the server is doing the wrong thing the right outcome is to fix it, not try and work around it. > 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.). Actually this one's a bigger problem for me. This sounds like a case where a 4xx code should have been issued (or the address accepted and alias expansion deferred) rather than a 5xx code. But even in a case like this I think it is better to take the code at face value and bounce the message. > So, any input there on how these 500 level response should be > handled? current usage of any of these responses to these commands? I'd handle them by bouncing the message. Ned From owner-ietf-smtp Sat Apr 11 16:00:08 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA03153 for ietf-smtp-bks; Sat, 11 Apr 1998 16:00: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 QAA03149 for ; Sat, 11 Apr 1998 16:00:07 -0700 (PDT) Received: (qmail 13662 invoked by uid 666); 11 Apr 1998 23:02:43 -0000 Date: 11 Apr 1998 23:02:43 -0000 Message-ID: <19980411230243.13660.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-smtp@imc.org Subject: Re: List of ESMTP extensions References: <980410120821.203d525d@Cisco.COM> X-Mutt-References: <980410120821.203d525d@Cisco.COM> Sender: owner-ietf-smtp@imc.org Precedence: bulk Dan Wing writes: > RFC1869 seems to indicate that VRFY is required and thus doesn't need > to be advertised in an EHLO response. Sorry---I assumed the question was about the real world, not the RFCs. > 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. Yes, I have a morbid interest in the sources of engineering disasters. ---Dan Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html From owner-ietf-smtp Mon Apr 13 08:01:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA09625 for ietf-smtp-bks; Mon, 13 Apr 1998 08:01:36 -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 IAA09621 for ; Mon, 13 Apr 1998 08:01:29 -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); Mon, 13 Apr 1998 11:02:27 -0400 Message-Id: <3.0.1.32.19980413110209.00a8aca0@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 13 Apr 1998 11:02:09 -0400 To: "D. J. Bernstein" , ietf-smtp@imc.org From: "Jack De Winter" Subject: Re: List of ESMTP extensions In-Reply-To: <19980410184735.6071.qmail@cr.yp.to> References: <199804101816.LAA13686@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk At 06:47 PM 4/10/98 -0000, D. J. Bernstein 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. > >> 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? Well, seeing as we are supposed to be writing software so that people can use it, and there is and was a need to support transient connections that wanted SMTP access, I dont think 'absurd' should be applied to ETRN. However, seeing as everytime I have tried to check one of Dan's web pages (with the plethora of information that is supposed to be stored there) and I get an extended error and no web pages back from the server, I really dont put much faith in those opinions. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-smtp Mon Apr 13 10:42:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA10832 for ietf-smtp-bks; Mon, 13 Apr 1998 10:42:32 -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 KAA10827 for ; Mon, 13 Apr 1998 10:42:31 -0700 (PDT) Received: by HQ.Cisco.COM for ietf-smtp@imc.ORG; Mon, 13 Apr 1998 10:42:28 -0700 Date: Mon, 13 Apr 1998 10:42:28 -0700 From: Dan Wing To: ietf-smtp@imc.org Message-Id: <980413104228.2039cd05@Cisco.COM> Subject: Re: List of ESMTP extensions Sender: owner-ietf-smtp@imc.org Precedence: bulk >> 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. > >Yes, I have a morbid interest in the sources of engineering disasters. The primary reason to do this is to send color faxes and superfine faxes, without wasting network bandwidth and without requiring the fax offramp to downgrade color/superfine faxes if that is necessary because it connects to a recipient fax machine that doesn't support color/superfine. To do this we need to know the capabilities of the recipient. We're already using SMTP, so using SMTP to determine the capabilities of the recipient seemed like a good idea and avoids the problems of out-of-sync caches and the like. Adding the SMTP extension to an offramp is trivial and solves the problem in a way that is analogous to how today's fax machines determine recipient capabilities exchange. As I said, though, we're probably going to let this I-D expire so going into a lengthy debate isn't useful. -Dan Wing From owner-ietf-smtp Mon Apr 13 11:46:23 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA11246 for ietf-smtp-bks; Mon, 13 Apr 1998 11:46:23 -0700 (PDT) Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA11241; Mon, 13 Apr 1998 11:46:22 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA03965; Mon, 13 Apr 1998 11:46:52 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <199804101816.LAA13686@mail.proper.com> X-Mailer: QUALCOMM Eudora Pro v4.0 for Macintosh Date: Mon, 13 Apr 1998 11:36:09 -0700 To: Paul Hoffman / IMC From: Randall Gellens Subject: Re: List of ESMTP extensions Cc: ietf-smtp@imc.org 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! ATRN, draft-gellens-on-demand, SMTP relay with dynamic IP address. Of course, this is supposed to be on its own port, so you might not want to count it. But someone could include the feature in a standard SMTP server and run it on port 25 if they wanted to. From owner-ietf-smtp Mon Apr 13 15:39:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA12680 for ietf-smtp-bks; Mon, 13 Apr 1998 15:39:38 -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 PAA12675 for ; Mon, 13 Apr 1998 15:39:37 -0700 (PDT) Received: (qmail 24006 invoked by uid 666); 13 Apr 1998 22:42:20 -0000 Date: 13 Apr 1998 22:42:20 -0000 Message-ID: <19980413224220.24004.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> <19980410184735.6071.qmail@cr.yp.to> <3.0.1.32.19980413110209.00a8aca0@lacroix.wildbear.on.ca> Sender: owner-ietf-smtp@imc.org Precedence: bulk Jack De Winter writes: > Well, seeing as we are supposed to be writing software so that people > can use it, and there is and was a need to support transient connections > that wanted SMTP access, I dont think 'absurd' should be applied to ETRN. ETRN is very badly engineered. The fact that it works for some people doesn't mean that it's cost-effective. Putting ETRN on port 25 made it unnecessarily difficult to implement. The same function can be (and normally is) achieved through a separate TCP port---with a much simpler syntax, and a much simpler server that is implemented separately from the SMTP server. In the long run, merging ETRN with SMTP slows down the evolution of both services. > However, seeing as everytime I have tried to check one of Dan's web pages > (with the plethora of information that is supposed to be stored there) and > I get an extended error and no web pages back from the server, I really > dont put much faith in those opinions. Perhaps you should try Netscape, instead of a second-rate browser that doesn't understand how to use the standard FTP commands. ---Dan Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html From owner-ietf-smtp Tue Apr 14 17:38:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA10145 for ietf-smtp-bks; Tue, 14 Apr 1998 17:38:04 -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 RAA10141 for ; Tue, 14 Apr 1998 17:38:03 -0700 (PDT) Message-Id: <199804150038.RAA10141@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Tue, 14 Apr 1998 17:37:47 -0700 To: ietf-smtp@imc.org From: Paul Hoffman / IMC Subject: Re: List of ESMTP extensions In-Reply-To: <199804101816.LAA13686@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk I've now updated the Web page for this mailing list at to include the list with the corrections from the list. Let me know if you see other changes needed. Also, Dan's survey of number of publicly-accessible servers at is about a year old. Has anyone done a similar survey recently? It would be interesting to compare the results over a year. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Wed May 13 06:11:29 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA13871 for ietf-smtp-bks; Wed, 13 May 1998 06:11:29 -0700 (PDT) Received: from yalta.NL.net (yalta.NL.net [193.78.240.21]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA13867 for ; Wed, 13 May 1998 06:11:26 -0700 (PDT) Received: from amf51-107.Amersfoort.NL.net ([193.79.232.211]:35588 "HELO NLNet" ident: "IDENT-NOT-QUERIED") by yalta.NL.net with SMTP id <23510-15143>; Wed, 13 May 1998 15:14:18 +0200 Comments: Authenticated sender is From: "Rolf E. Sonneveld" Organization: Sonnection To: ietf-smtp@imc.org Date: Wed, 13 May 1998 15:16:37 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Testing SMTP/ESMTP conformance Reply-to: R.E.Sonneveld@sonnection.nl X-mailer: Pegasus Mail for Win32 (v2.54) Message-Id: <19980513131419Z23510-15143+652@yalta.NL.net> Sender: owner-ietf-smtp@imc.org Precedence: bulk Hi, all For one of my customers I'm looking for information on how to do some interoperability tests between an SMTP server and an SMTP client. For example I'd like to test normal SMTP functions, SMTP extensions (like 8BITMIME), and also test what happens if in the middle of an SMTP dialogue one of the two parties quit, in relation to the state of the SMTP session. Has anyone ever designed a good test setup for doing these kinds of tests? Any suggestiongs on what I should not forget? Is there any reference available to SMTP test reports? Regards, /rolf -- Rolf E. Sonneveld Sonnection Schrijnwerkerlaan 16 3828 XC Hoogland The Netherlands Tel./Fax. +31 33 480 3968 Mobile: +31 6543 70 20 5 E-mail: R.E.Sonneveld@sonnection.nl Homepage: http://www.sonnection.nl From owner-ietf-smtp Tue May 26 00:52:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA16919 for ietf-smtp-bks; Tue, 26 May 1998 00:52:53 -0700 (PDT) Received: from bang.jmk.su.se (bang.jmk.su.se [130.237.155.254]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA16915 for ; Tue, 26 May 1998 00:52:51 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by bang.jmk.su.se (8.7.6/8.6.6) with ESMTP id JAA12142 for ; Tue, 26 May 1998 09:54:12 +0200 (MET DST) X-Sender: jpalme@mail.dsv.su.se Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 May 1998 09:56:06 +0200 To: ietf-smtp@imc.org From: Jacob Palme Subject: Getting the DSN standard used Sender: owner-ietf-smtp@imc.org Precedence: bulk The DSN standards (RFC 1891, 1892, 1894) have now been ready for more than two years. Yet very few mailers support them. What can be done to get more support? Does sendmail produce DSN in the standardized format? If yes, how can we get people to update to a more recent version of sendmail. If not, how can we get it to support them? Mail clients can support DSNs in several ways. I list them below in my suggested priority order: (1) Display standardised DSNs in a standard format, which contains the information the user needs in easy to read format. (2) Allow filtering incoming DSNs to a special folder. (3) A command to look at a sent message, and then get a list of all delivery and receipt notifications for this message, one line per note. Something like this: Received by: xxx Received by: (printed on paper) yyy Delivered to: zzz Could not be delivered to: qqq This option is of course very useful in conjunction with option (2). (4) Commands to request delivery and receipt notifications and to request supression of them. Mail clients cannot be expected to support this until sendmail and other MTA software starts supporting them. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Tue May 26 02:41:14 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17683 for ietf-smtp-bks; Tue, 26 May 1998 02:41:14 -0700 (PDT) Received: from yalta.NL.net (yalta.NL.net [193.78.240.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17679 for ; Tue, 26 May 1998 02:41:12 -0700 (PDT) Received: from solair1.inter.NL.net ([193.78.240.13]:31239 "EHLO solair1.inter.NL.net") by yalta.NL.net with ESMTP id <17810-19953>; Tue, 26 May 1998 11:45:08 +0200 Received: (from rsonneve@localhost) by solair1.inter.NL.net (8.8.7/8.8.7/NLnet Revision: 1.49 ) id LAA13179; Tue, 26 May 1998 11:44:54 +0200 (MET DST) From: "R.E. Sonneveld" Message-Id: <199805260944.LAA13179@solair1.inter.NL.net> Subject: Re: Getting the DSN standard used To: jpalme@dsv.su.se (Jacob Palme) Date: Tue, 26 May 1998 11:44:53 +0200 (MET DST) Cc: ietf-smtp@imc.org In-Reply-To: from "Jacob Palme" at May 26, 98 09:56:06 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Jacob, > The DSN standards (RFC 1891, 1892, 1894) have now been > ready for more than two years. Yet very few mailers support > them. What can be done to get more support? I'm afraid there are two major obstacles to the widespread use of DSN: 1. the amount of User Agents supporting DSN is low 2. from my experience I know that in a significant number of cases the problem why DSN is not supported by a company e-mail infrastructure the firewall that's being used in the real world. In many cases the firewall has an active mail component, thus limiting the support for SMTP and extensions to what the firewall provides. And more often then not the firewall does not support DSN or does not even ESMTP at all! > Does sendmail produce DSN in the standardized format? If > yes, how can we get people to update to a more recent > version of sendmail. If not, how can we get it to support I think Sendmail is not the problem. Due to Sendmail's security problems, most customers have recent releases of Sendmail deployed. > Mail clients can support DSNs in several ways. I list them > below in my suggested priority order: > > (1) Display standardised DSNs in a standard format, which > contains the information the user needs in easy to read > format. > > (2) Allow filtering incoming DSNs to a special folder. > > (3) A command to look at a sent message, and then get a > list of all delivery and receipt notifications for this > message, one line per note. Something like this: > > Received by: xxx > Received by: (printed on paper) yyy > Delivered to: zzz > Could not be delivered to: qqq > > This option is of course very useful in conjunction > with option (2). > > (4) Commands to request delivery and receipt notifications > and to request supression of them. > > Mail clients cannot be expected to support this until > sendmail and other MTA software starts supporting them. Yes, but I think in many cases the vendors of UA software should do more to support DSN's and vendors of firewalls should get up to date with their e-mail software. Regards, /rolf Rolf E. Sonneveld Sonnection The Netherlands From owner-ietf-smtp Wed May 27 12:07:02 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18592 for ietf-smtp-bks; Wed, 27 May 1998 12:07:02 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18588 for ; Wed, 27 May 1998 12:06:57 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id PAA01487; Wed, 27 May 1998 15:10:57 -0400 (EDT) Message-Id: <199805271910.PAA01487@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "R.E. Sonneveld" cc: jpalme@dsv.su.se (Jacob Palme), ietf-smtp@imc.org, moore@cs.utk.edu Subject: Re: Getting the DSN standard used In-reply-to: Your message of "Tue, 26 May 1998 11:44:53 +0200." <199805260944.LAA13179@solair1.inter.NL.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 May 1998 15:10:47 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk > > The DSN standards (RFC 1891, 1892, 1894) have now been > > ready for more than two years. Yet very few mailers support > > them. What can be done to get more support? First a response to Jacob's comment: Last time I went to an interoperability test, most major vendors of SMTP were supporting DSN. > I'm afraid there are two major obstacles to the widespread use of DSN: > > 1. the amount of User Agents supporting DSN is low Yes, but this only explains the inability to request delivery confirmation. DSNs are very useful even if many clients don't support them. Note that there are two levels of support for DSN in MTAs: 1. if they generate nondelivery reports in DSN format 2. if they advertise the DSN SMTP extension, implying that they support NOTIFY, ENVID, etc. The first is easier to do than the second. > 2. from my experience I know that in a significant number of cases > the problem why DSN is not supported by a company e-mail infrastructure > the firewall that's being used in the real world. In many cases the > firewall has an active mail component, thus limiting the support for > SMTP and extensions to what the firewall provides. And more often then > not the firewall does not support DSN or does not even ESMTP at > all! Yes, firewalls are a major problem. We need a clear community statement to the effect that firewalls that block arbitrary SMTP extensions are nonstandard and broken. Keith From owner-ietf-smtp Wed May 27 14:01:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19448 for ietf-smtp-bks; Wed, 27 May 1998 14:01:43 -0700 (PDT) Received: from yalta.NL.net (yalta.NL.net [193.78.240.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19444 for ; Wed, 27 May 1998 14:01:42 -0700 (PDT) Received: from amf51-11.Amersfoort.NL.net ([193.79.232.115]:8708 "HELO NLNet") by yalta.NL.net with SMTP id <17676-9708>; Wed, 27 May 1998 23:05:41 +0200 Comments: Authenticated sender is From: "Rolf E. Sonneveld" Organization: Sonnection To: Keith Moore Date: Wed, 27 May 1998 23:08:24 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Getting the DSN standard used Reply-to: R.E.Sonneveld@sonnection.nl CC: jpalme@dsv.su.se (Jacob Palme), ietf-smtp@imc.org In-reply-to: <199805271910.PAA01487@spot.cs.utk.edu> References: Your message of "Tue, 26 May 1998 11:44:53 +0200." <199805260944.LAA13179@solair1.inter.NL.net> X-mailer: Pegasus Mail for Win32 (v2.54) Message-Id: <19980527210547Z17676-9708+5796@yalta.NL.net> Sender: owner-ietf-smtp@imc.org Precedence: bulk As a followup to Keith's message: > > > The DSN standards (RFC 1891, 1892, 1894) have now been > > > ready for more than two years. Yet very few mailers support > > > them. What can be done to get more support? > > First a response to Jacob's comment: Last time I went to an > interoperability test, most major vendors of SMTP were supporting DSN. > > I'm afraid there are two major obstacles to the widespread use of DSN: > > > > 1. the amount of User Agents supporting DSN is low > > Yes, but this only explains the inability to request delivery > confirmation. DSNs are very useful even if many clients don't support > them. When I wrote this I was thinking about the support in UA's for the proper and decent presentation of DSN 'compliant' messages/bodyparts. For most 'ordinary' non-technical users the three-part messages are still not very helpful in determining what's wrong or what's OK with the message they had sent. I think this is a similar problem to the problem with the deployment of MIME back in 1992, when MIME just was released. User Agents then presented the user with the raw MIME structure. Now most UA's present MIME format messages properly. > Note that there are two levels of support for DSN in MTAs: > > 1. if they generate nondelivery reports in DSN format > 2. if they advertise the DSN SMTP extension, implying that they > support NOTIFY, ENVID, etc. > > The first is easier to do than the second. > > > > 2. from my experience I know that in a significant number of cases > > the problem why DSN is not supported by a company e-mail infrastructure > > the firewall that's being used in the real world. In many cases the > > firewall has an active mail component, thus limiting the support for > > SMTP and extensions to what the firewall provides. And more often then > > not the firewall does not support DSN or does not even ESMTP at > > all! > > Yes, firewalls are a major problem. > > We need a clear community statement to the effect that firewalls that > block arbitrary SMTP extensions are nonstandard and broken. I support your statement here! /rolf -- Rolf E. Sonneveld Sonnection Schrijnwerkerlaan 16 3828 XC Hoogland The Netherlands Tel./Fax. +31 33 480 3968 Mobile: +31 6543 70 20 5 E-mail: R.E.Sonneveld@sonnection.nl Homepage: http://www.sonnection.nl From owner-ietf-smtp Thu May 28 09:03:38 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13452 for ietf-smtp-bks; Thu, 28 May 1998 09:03:38 -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.8.5) with SMTP id JAA13445 for ; Thu, 28 May 1998 09:03:36 -0700 (PDT) Received: (qmail 20413 invoked by uid 666); 28 May 1998 16:07:59 -0000 Date: 28 May 1998 16:07:59 -0000 Message-ID: <19980528160759.20411.qmail@cr.yp.to> Mail-Followup-To: ietf-smtp@imc.org From: "D. J. Bernstein" To: ietf-smtp@imc.org Subject: Re: Getting the DSN standard used References: Sender: owner-ietf-smtp@imc.org Precedence: bulk Jacob Palme writes: > What can be done to get more support? Give up and start over. MUAs need something easy to parse; MTAs need something easy to generate; users need something that works end-to-end without link-level support. > Mail clients can support DSNs in several ways. Those functions don't require DSN unless they're foolishly implemented. See http://pobox.com/~djb/proto/verp.txt. ---Dan 50000 new aliases in 6 seconds. http://pobox.com/~djb/fastforward.html From owner-ietf-smtp Thu May 28 11:56:55 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14997 for ietf-smtp-bks; Thu, 28 May 1998 11:56:55 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14992 for ; Thu, 28 May 1998 11:56:53 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id VAA14606; Thu, 28 May 1998 21:01:05 +0200 (MET DST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: jpalme@mail.dsv.su.se Message-Id: In-Reply-To: <19980528160759.20411.qmail@cr.yp.to> References: Date: Thu, 28 May 1998 21:01:35 +0200 To: "D. J. Bernstein" , ietf-smtp@imc.org From: Jacob Palme Subject: Re: Getting the DSN standard used Sender: owner-ietf-smtp@imc.org Precedence: bulk At 18.07 +0200 98-05-28, D. J. Bernstein wrote: > Jacob Palme writes: > > What can be done to get more support? > > Give up and start over. MUAs need something easy to parse; MTAs need > something easy to generate; users need something that works end-to-end > without link-level support. The most important part of the DSN standard is the standardized format for non-delivery DSNs. This can be supported *even* if you do not support the ESMTP commands to control generation of DSNs. The value with this standardized format is that (a) Mail clients can display it in ways the user understands. (b) Mail clients can collect the DSNs, so that a user can give a command asking which recipients for a particular message have generated non-delivery DSNs. (c) Non-delivery DSNs can be filtered. In particular, if a user uses option (b), the user might prefer not to see the DSNs at all when they arrive. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Thu May 28 14:35:36 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17117 for ietf-smtp-bks; Thu, 28 May 1998 14:35:36 -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.8.5) with SMTP id OAA17113 for ; Thu, 28 May 1998 14:35:35 -0700 (PDT) Received: (qmail 22508 invoked by uid 666); 28 May 1998 21:40:15 -0000 Date: 28 May 1998 21:40:15 -0000 Message-ID: <19980528214015.22506.qmail@cr.yp.to> Mail-Followup-To: ietf-smtp@imc.org From: "D. J. Bernstein" To: ietf-smtp@imc.org Subject: Re: Getting the DSN standard used References: <19980528160759.20411.qmail@cr.yp.to> Sender: owner-ietf-smtp@imc.org Precedence: bulk Jacob Palme writes: > (b) Mail clients can collect the DSNs, so that a user can give > a command asking which recipients for a particular message > have generated non-delivery DSNs. Pay attention. The MUA can easily do this, 100% reliably, _without_ a standardized bounce format. See http://pobox.com/~djb/proto/verp.txt. > The most important part of the DSN standard is the standardized format > for non-delivery DSNs. How could it possibly be ``important'' to generate a format that is, as a practical matter, understood by neither man nor machine? Extracting useful information from DSN is a royal pain. > To: "D. J. Bernstein" , ietf-smtp@imc.org Please don't send me extra copies of your messages, Jacob. ---Dan 50000 new aliases in 6 seconds. http://pobox.com/~djb/fastforward.html From owner-ietf-smtp Thu May 28 14:32:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17071 for ietf-smtp-bks; Thu, 28 May 1998 14:32:26 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17067 for ; Thu, 28 May 1998 14:32:23 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Thu, 28 May 1998 17:37:35 -0400 Message-Id: <3.0.1.32.19980528173733.00a23c30@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 28 May 1998 17:37:33 -0400 To: "D. J. Bernstein" , ietf-smtp@imc.org From: "Jack De Winter" Subject: Re: Getting the DSN standard used In-Reply-To: <19980528160759.20411.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk At 04:07 PM 5/28/98 -0000, D. J. Bernstein wrote: >Jacob Palme writes: >> What can be done to get more support? > >Give up and start over. MUAs need something easy to parse; MTAs need >something easy to generate; users need something that works end-to-end >without link-level support. > >> Mail clients can support DSNs in several ways. > >Those functions don't require DSN unless they're foolishly implemented. >See http://pobox.com/~djb/proto/verp.txt. Please do not post URLs for sites that most of us cannot access. It is both infuriating and a pain. Try doing something like posting the data here. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From owner-ietf-smtp Thu May 28 14:53:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17333 for ietf-smtp-bks; Thu, 28 May 1998 14:53:11 -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.8.5) with SMTP id OAA17329 for ; Thu, 28 May 1998 14:53:10 -0700 (PDT) Received: (qmail 22740 invoked by uid 666); 28 May 1998 21:57:51 -0000 Date: 28 May 1998 21:57:51 -0000 Message-ID: <19980528215751.22738.qmail@cr.yp.to> Mail-Followup-To: ietf-smtp@imc.org From: "D. J. Bernstein" To: ietf-smtp@imc.org Subject: Re: Getting the DSN standard used References: <19980528160759.20411.qmail@cr.yp.to> <3.0.1.32.19980528173733.00a23c30@lacroix.wildbear.on.ca> Sender: owner-ietf-smtp@imc.org Precedence: bulk Jack De Winter writes: > Please do not post URLs for sites that most of us cannot access. Your current browser has some serious bugs. Why don't you use Netscape? Or lynx, if you need something that works with dumb terminals. ---Dan 50000 new aliases in 6 seconds. http://pobox.com/~djb/fastforward.html From owner-ietf-smtp Thu May 28 16:14:49 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA18043 for ietf-smtp-bks; Thu, 28 May 1998 16:14:49 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18039 for ; Thu, 28 May 1998 16:14:47 -0700 (PDT) Received: from monopoly.andrew.cmu.edu (MONOPOLY.ANDREW.CMU.EDU [128.2.35.132]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id TAA03073; Thu, 28 May 1998 19:19:01 -0400 (EDT) Date: 28 May 1998 19:19:01 -0400 Message-ID: From: Tim Showalter X-Spook: security bomb assassination [Hello to all my fans in domestic surveillance] Uzi Craig Livingstone Marxist Cocaine To: ietf-smtp@imc.org In-reply-to: <3.0.1.32.19980528173733.00a23c30@lacroix.wildbear.on.ca> Subject: Re: Getting the DSN standard used Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk > Date: Thu, 28 May 1998 17:37:33 -0400 > From: "Jack De Winter" > > >Those functions don't require DSN unless they're foolishly implemented. > >See http://pobox.com/~djb/proto/verp.txt. > > Please do not post URLs for sites that most of us cannot access. > It is both infuriating and a pain. Try doing something like posting > the data here. > [...] > (519) 884-4498 http://www.wildbear.on.ca/jacks/ Dan's link works in Netscape 2 (Solaris), Netscape 3 (Linux), Netscape 4 (Linux), and Lynx (Linux). It even worked in the circa 1993 CERN browser "www" (SunOS binary running under Solaris, although www makes you go through the FTP redirect by hand). I've had two problems with Dan's URLs: one, a URL posted to DRUMS in 1996 is invalid; two, deleting the filename off of the URL (to hopefully look at the list of documents in that directory) doesn't work as far as I know. But these are my fault, and my problem, and do not interfere with chasing that link. Surprisingly, the link in your signature appears to be invalid in all of the above browsers plus "telnet www.wildbear.on.ca 80". Incidentially, what browser is preventing you from getting that link? -- Tim Showalter From owner-ietf-smtp Fri May 29 07:18:30 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA08528 for ietf-smtp-bks; Fri, 29 May 1998 07:18:30 -0700 (PDT) Received: from lupinella.troll.no (lupinella.troll.no [195.0.254.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA08524 for ; Fri, 29 May 1998 07:18:26 -0700 (PDT) Received: by troll.no id <79640-11143>; Fri, 29 May 1998 16:22:34 +0200 To: ietf-smtp@imc.org Subject: Re: Getting the DSN standard used References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: Arnt Gulbrandsen Date: 29 May 1998 16:22:28 +0200 In-Reply-To: Jacob Palme's message of "Thu, 28 May 1998 21:01:35 +0200" Message-ID: Lines: 15 Sender: owner-ietf-smtp@imc.org Precedence: bulk Jacob Palme > The most important part of the DSN standard is the standardized format > for non-delivery DSNs. Is it? I am probably almost unique: I send NOTIFY=SUCCESS mail on a regular basis (using some hacks of my own). IMHO, the fact that I can count on receiving either a 'delivered' or a 'relayed' DSN is the most important feature in the long term. The fact that its format is parsable is the second most important part (insert minor sendmail grumble here). Having one widely available mail client that's able to list what recipients have recived any send mail might help a lot. --Arnt From owner-ietf-smtp Fri May 29 10:38:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09851 for ietf-smtp-bks; Fri, 29 May 1998 10:38:54 -0700 (PDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09844 for ; Fri, 29 May 1998 10:38:52 -0700 (PDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Fri, 29 May 1998 13:43:45 -0400 Message-Id: <3.0.1.32.19980529134342.00a07490@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 29 May 1998 13:43:42 -0400 To: Tim Showalter , ietf-smtp@imc.org From: "Jack De Winter" Subject: Re: Getting the DSN standard used In-Reply-To: References: <3.0.1.32.19980528173733.00a23c30@lacroix.wildbear.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk >Dan's link works in Netscape 2 (Solaris), Netscape 3 (Linux), Netscape 4 >(Linux), and Lynx (Linux). It even worked in the circa 1993 CERN >browser "www" (SunOS binary running under Solaris, although www makes >you go through the FTP redirect by hand). > >I've had two problems with Dan's URLs: one, a URL posted to DRUMS in >1996 is invalid; two, deleting the filename off of the URL (to hopefully >look at the list of documents in that directory) doesn't work as far as >I know. But these are my fault, and my problem, and do not interfere >with chasing that link. > >Surprisingly, the link in your signature appears to be invalid in all of >the above browsers plus "telnet www.wildbear.on.ca 80". Noted... moved stuff around on the web site, and thought I had updated my links. >Incidentially, what browser is preventing you from getting that link? I have tried Netscape 2, 3 and 4, IE 3 and 4, and the latest release of Opera, all to no avail. Each of them returns that the request was illegal. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/homepages/jack/ From owner-ietf-smtp Wed Jul 8 18:30:10 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA19994 for ietf-smtp-bks; Wed, 8 Jul 1998 18:30:10 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19983; Wed, 8 Jul 1998 18:30:05 -0700 (PDT) Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id VAA28119; Wed, 8 Jul 1998 21:30:01 -0400 (EDT) Message-Id: <199807090130.VAA28119@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: drums@cs.utk.edu, ietf-smtp@imc.org Subject: [Off Topic] Need review for POP3 extension mechanism cc: moore@cs.utk.edu, ietf-pop3ext@imc.org From: Keith Moore Reply-To: ietf-pop3ext@imc.org Date: Wed, 08 Jul 1998 21:30:01 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk I apologize for an off-topic posting. Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp lists. On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt , for Proposed Standard status. Nobody has commented on the document. I am reluctant to recommend that IESG approve this document without more evidence of support. So I'm asking for more review... Should the document be adopted as is? Does it need more wordsmithing? Are all of these capabilities needed? Are all of the capabilities defined with sufficient precision? Should the document be standards track or should it be Informational or Experimental? Should the extension mechanism be separated from (and perhaps a different status from) the extensions themselves? If the document is approved for Proposed, should all of the proposed extensions be included? Or should some of the extensions be moved to a separate Informational or Experimental? Which ones? In the absence of more community input, my recommendation would be to direct the authors to remove all of the capabilities from this document, except those which are already defined in standards-track documents. Additional capabilities could be defined in a separate experimental or informational RFC. thanks! Keith Moore APPS co-AD From owner-ietf-smtp Fri Jul 10 10:58:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06316 for ietf-smtp-bks; Fri, 10 Jul 1998 10:58:44 -0700 (PDT) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06294; Fri, 10 Jul 1998 10:56:37 -0700 (PDT) Received: from dhcp-899742787.qualcomm.com (dhcp-899742787.qualcomm.com [129.46.137.245]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA19775; Fri, 10 Jul 1998 10:56:05 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: (Unverified) Message-Id: In-Reply-To: <01IZ63P7EKAI99DO6M@INNOSOFT.COM> References: "Your message dated Wed, 08 Jul 1998 14:57:37 -0400 (EDT)" X-Mailer: Eudora [Macintosh version 4.1a14-8.98] Date: Fri, 10 Jul 1998 10:56:05 -0700 To: ietf-smtp@imc.org, ietf-822@imc.org From: Pete Resnick Subject: Re: 8BITMIME to 7BIT Sender: owner-ietf-smtp@imc.org Precedence: bulk A discussion started over on the international mail list, but the question I had seemed more appropriate for ietf-smtp and ietf-822. I've Bcc'ed the international mail list. On 7/8/98 at 7:21 PM -0700, Ned Freed wrote: >You have to check for and make sure not to change anything within a >multipart/signed. (Multipart/encrypted is a nonissue, as the entire part is >encoded.) If the multipart/signed contains 8bit I currently default to sending >it through untouched, which of course is technically illegal but works often >enough that it rarely results in a problem. I also support configurations >where >the signature is simply removed in such cases, either with or without an >attempt to verify. >... >Note, however, that the contents of multipart/signed are supposed to be >7bit-friendly when multipart/signed is used with potentially 7bit-only >transports like SMTP. Unfortunately clients exist that botch this. So I was thinking: Would it be reasonable for us to create a field for the signature sort of like: Content-Signed-Part-Encoding: 8bit which would indicate the CTE used to compute the signature? That way, if an MTA does downgrade a message, the signature can still be verified because you can always recover the original content after a downgrade. The rule for gateways would be: When downgrading a multipart/signed which already has a Content-Signed-Part-Encoding, preserve that field exactly as it was. If there is no Content-Signed-Part-Encoding, add one. Anyone who's currently following the rules and sending 7bit encodings would still be fine. Anyone who's breaking the rules and sending 8bit or binary encodings without any labeling may get some help during the downgrade. The only problem's going to be recipients who can't verify the signature because they don't recognize to upgrade back to the CSPE, but there was some chance that those would fail anyway because the originator sent 8bit blindy in the first place. Comments? pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 or (619)651-4478 Fax: (217)337-1980 or (619)651-1102 From owner-ietf-smtp Tue Jul 21 21:17:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA11183 for ietf-smtp-bks; Tue, 21 Jul 1998 21:17:59 -0700 (PDT) Received: from yuri.exchange.microsoft.com (yuri.exchange.microsoft.com [131.107.88.54]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA11171; Tue, 21 Jul 1998 21:17:49 -0700 (PDT) Received: by yuri.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 21 Jul 1998 21:18:24 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010B37E591@DINO> From: "Mike Gahrns (Exchange)" To: "'ietf-pop3ext@imc.org'" , drums@cs.utk.edu, ietf-smtp@imc.org Subject: RE: [Off Topic] Need review for POP3 extension mechanism Date: Tue, 21 Jul 1998 21:18:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDB527.C46A0970" Sender: owner-ietf-smtp@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDB527.C46A0970 Content-Type: text/plain; charset="iso-8859-1" I apologize for such a late response, but i have been out of the office for the last few weeks. I agree with the others who view this as being a useful draft, and second the motion that it should go as proposed instead of informational or experimental. Although the list has not had a lot of dicussion on it, I know Randy has been discussing this with various people at venues like the ietf, so it has been getting review. My biggest concern was the former LMOS setting allowed for expiration settings to be based on the command used to acccess the msg, which Randy has addressed with the new EXPIRE setting. I do have one minor concern regarding the current wording of the EXPIRE setting. The draft states: "If the expiration policy might differ per user (that is, the EXPIRE argument might change after authentication), the server MUST announce in the AUTHENTICATION state the smallest value which might be used. The server should announce the more accurate value in the TRANSACTION state. It is unclear to me whether the intent of this is to force the server to keep track of the smallest setting a user currently has set, or if it is for the server to annouce the smallest value that an administrator could conceivably set for a particular user. If the intent is the former, than this will be problematic for servers that are not tightly coupled with their directory, as it effectively forces the server to scan a list of all user settings at each log on time. I'll talk to Randy to get clarification, and perhaps come up with some clarification wording in regards to this. Another minor nit is the wording: "If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks." I'd like to see the wording changed to something like: "The client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks and to get any per user capability settings." -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Wednesday, July 08, 1998 6:30 PM To: drums@cs.utk.edu; ietf-smtp@imc.org Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org Subject: [Off Topic] Need review for POP3 extension mechanism I apologize for an off-topic posting. Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp lists. On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt , for Proposed Standard status. Nobody has commented on the document. I am reluctant to recommend that IESG approve this document without more evidence of support. So I'm asking for more review... Should the document be adopted as is? Does it need more wordsmithing? Are all of these capabilities needed? Are all of the capabilities defined with sufficient precision? Should the document be standards track or should it be Informational or Experimental? Should the extension mechanism be separated from (and perhaps a different status from) the extensions themselves? If the document is approved for Proposed, should all of the proposed extensions be included? Or should some of the extensions be moved to a separate Informational or Experimental? Which ones? In the absence of more community input, my recommendation would be to direct the authors to remove all of the capabilities from this document, except those which are already defined in standards-track documents. Additional capabilities could be defined in a separate experimental or informational RFC. thanks! Keith Moore APPS co-AD ------_=_NextPart_001_01BDB527.C46A0970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Off Topic] Need review for POP3 extension mechanism

I apologize for such a late response, but i have been = out of the office for the last few weeks.

I agree with the others who view this as being a = useful draft, and second the motion that it should go as proposed = instead of informational or experimental.

Although the list has not had a lot of dicussion on = it, I know Randy has been discussing this with various people at venues = like the ietf, so it has been getting review.  My biggest concern = was the former LMOS setting allowed for expiration settings to be based = on the command used to acccess the msg, which Randy has addressed with = the new EXPIRE setting.

I do have one minor concern regarding the current = wording of the EXPIRE setting.

The draft states:
"If the expiration policy might differ per user = (that is, the EXPIRE argument might change after authentication), the = server MUST announce in the AUTHENTICATION state the smallest value = which might be used.  The server should announce the more accurate = value in the TRANSACTION state.

It is unclear to me whether the intent of this is to = force the server to keep track of the smallest setting a user currently = has set, or if it is for the server to annouce the smallest value that = an administrator could conceivably set for a particular user.  If = the intent is the former, than this will be problematic for servers = that are not tightly coupled with their directory, as it effectively = forces the server to scan a list of all user settings at each log on = time.

I'll talk to Randy to get clarification, and perhaps = come up with some clarification wording in regards to this.

Another minor nit is the wording:
"If the authentication step negotiates an = integrity protection layer, the client SHOULD reissue the CAPA command = after authenticating to check for active down-negotiation = attacks."

I'd like to see the wording changed to something = like:
"The client SHOULD reissue the CAPA command = after authenticating to check for active down-negotiation attacks and = to get any per user capability settings."



-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Wednesday, July 08, 1998 6:30 PM
To: drums@cs.utk.edu; ietf-smtp@imc.org
Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org
Subject: [Off Topic] Need review for POP3 extension = mechanism


I apologize for an off-topic posting. 
Please send replies to ietf-pop3ext@imc.org, not to = the drums or ietf-smtp lists.

On May 18, a Last Call was issued on for document = draft-gellens-pop3ext-05.txt ,
for Proposed Standard status.  Nobody has = commented on the document.  I am
reluctant to recommend that IESG approve this = document without more evidence
of support.

So I'm asking for more review...

Should the document be adopted as is?  Does it = need more wordsmithing?
Are all of these capabilities needed?
Are all of the capabilities defined with sufficient = precision?

Should the document be standards track or should it = be Informational or
Experimental?

Should the extension mechanism be separated from (and = perhaps a different
status from) the extensions themselves?

If the document is approved for Proposed, should all = of the proposed extensions
be included?  Or should some of the extensions = be moved to a separate
Informational or Experimental?   Which = ones?

In the absence of more community input, my = recommendation would be to direct
the authors to remove all of the capabilities from = this document, except those
which are already defined in standards-track = documents.  Additional capabilities
could be defined in a separate experimental or = informational RFC.

thanks!

Keith Moore
APPS co-AD

------_=_NextPart_001_01BDB527.C46A0970-- From owner-ietf-smtp Wed Jul 22 12:11:44 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA27456 for ietf-smtp-bks; Wed, 22 Jul 1998 12:11:44 -0700 (PDT) Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA27452; Wed, 22 Jul 1998 12:11:42 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA20867; Wed, 22 Jul 1998 12:12:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2FBF98FC7852CF11912A0000000000010B37E591@DINO> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Wed, 22 Jul 1998 12:08:00 -0700 To: "Mike Gahrns (Exchange)" From: Randall Gellens Subject: RE: [Off Topic] Need review for POP3 extension mechanism Cc: "'ietf-pop3ext@imc.org'" , drums@cs.utk.edu, ietf-smtp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-smtp@imc.org Precedence: bulk At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote: >I do have one minor concern regarding the current wording of the >EXPIRE setting. > >The draft states: >"If the expiration policy might differ per user (that is, the EXPIRE >argument might change after authentication), the server MUST announce >in the AUTHENTICATION state the smallest value which might be used. >The server should announce the more accurate value in the TRANSACTION >state. > >It is unclear to me whether the intent of this is to force the server >to keep track of the smallest setting a user currently has set, or if >it is for the server to annouce the smallest value that an >administrator could conceivably set for a particular user. If the >intent is the former, than this will be problematic for servers that >are not tightly coupled with their directory, as it effectively forces >the server to scan a list of all user settings at each log on time. The intent is to let the client know that the server does permit mail to be left on the server, and to present a value which is the smallest which might be set for the user. This could be the smallest value currently in use for any user (so only one value per server), or even the smallest value which the server permits to be set for any user. This way a client can decide (because the user has told the client to leave mail on the server for a larger number of days) if it needs to reissue CAPA after authenticating and/or warn the user. >Another minor nit is the wording: >"If the authentication step negotiates an integrity protection layer, >the client SHOULD reissue the CAPA command after authenticating to >check for active down-negotiation attacks." > >I'd like to see the wording changed to something like: >"The client SHOULD reissue the CAPA command after authenticating to >check for active down-negotiation attacks and to get any per user >capability settings." The intent is to not require clients to issue two CAPA commands. The client pretty much has to issue one before authenticating, to learn which SASL mechanisms are supported, but doesn't have to issue on afterwards, unless the first CAPA reveals that the server supports some capabilities whose parameters might change after authentication, and the client needs the most accurate values (it might be able to use the more general ones), or the client wants to check for down-negotiation attacks. A simple client that only uses a few basic SASL mechanisms, for example, and only needs to know if the server supports TOP, UIDL, and allows mail to be left on the server, doesn't need to issue two CAPAs. (A client which only uses plaintext or APOP could issue only one CAPA, after authenticating.) From owner-ietf-smtp Wed Jul 22 20:42:57 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA00846 for ietf-smtp-bks; Wed, 22 Jul 1998 20:42:57 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00842; Wed, 22 Jul 1998 20:42:55 -0700 (PDT) Received: by tide03.microsoft.com; id UAA17039; Wed, 22 Jul 1998 20:43:45 -0700 (PDT) Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma017036; Wed, 22 Jul 98 20:43:44 -0700 Received: from red-01-imc.dns.microsoft.com ([157.54.1.197]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id UAA28977; Wed, 22 Jul 1998 20:53:56 -0700 (PDT) Received: from popdog.exchange.microsoft.com (POPDOG [172.30.236.242]) by red-01-imc.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id PKF6X2L1; Wed, 22 Jul 1998 20:43:44 -0700 Received: from mikega9 (mikega9.dns.microsoft.com [157.59.255.141]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 37DWQA4C; Wed, 22 Jul 1998 20:43:49 -0700 Message-ID: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com> From: "Mike Gahrns" To: "Randall Gellens" Cc: , , Subject: Re: [Off Topic] Need review for POP3 extension mechanism Date: Wed, 22 Jul 1998 20:46:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smtp@imc.org Precedence: bulk *** within >At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote: > >>I do have one minor concern regarding the current wording of the >>EXPIRE setting. >> >>The draft states: >>"If the expiration policy might differ per user (that is, the EXPIRE >>argument might change after authentication), the server MUST announce >>in the AUTHENTICATION state the smallest value which might be used. >>The server should announce the more accurate value in the TRANSACTION >>state. >> >>It is unclear to me whether the intent of this is to force the server >>to keep track of the smallest setting a user currently has set, or if >>it is for the server to annouce the smallest value that an >>administrator could conceivably set for a particular user. If the >>intent is the former, than this will be problematic for servers that >>are not tightly coupled with their directory, as it effectively forces >>the server to scan a list of all user settings at each log on time. > >The intent is to let the client know that the server does permit mail >to be left on the server, and to present a value which is the smallest >which might be set for the user. This could be the smallest value >currently in use for any user (so only one value per server), or even >the smallest value which the server permits to be set for any user. *** If it is the smallest value which the server permits to be set for any user, I am happy with it. Would it be possible for you to update the draft with the above paragraph? If I had the question, I am sure others will... The more precise we are now with things, will save us interoperability grief later and it really is just a minor clarification so we won't need to worry about another last call. (The smallest value currently in use by any user on a server is problematic for us, but we do not have any objections if other servers want to present this value if they can easily calculate it) This should not pose any interop problems either. Basically, if a client wants to get the accurate setting, they need to re-issue the CAPA command after authenticating, so i do not really think it matters too much what was presented in the unauthenticated state. Having said that, perhaps a better solution would be to define another arguement called "USER". If a client does a CAPA and gets an EXPIRE USER, in the unauthenticated state, it knows that the server supports per user expiry settings. It explicitly informs the user when they need to re-issue the CAPA command after authentication due to per user options. >This way a client can decide (because the user has told the client to >leave mail on the server for a larger number of days) if it needs to >reissue CAPA after authenticating and/or warn the user. *** this is assuming that the client ui has something that allows the user to specify the number of days to leave mail on the server. I believe some clients just have a "leave mail on server" option. In this case, I guess the client will always need to reissue the CAPA command after authentication. The interop problem I see is the following: The client is running against a server where expiry is set on a per user setting. Let's say the server allows the admin to specify per user expiry settings. For the client that is logged on, the per user expiry is set to 30. However, on the server he is running against, there is a user who has expiry set to 15. Or it is a server, where the lowest expiry setting is not available, so the server reports what the theoretical minimum it can be set to, lets say 1. Unless things are spelled out explicitly within your draft, I can see a client issueing only a single CAPA before authentication. Without it doing another CAPA after authentication, the client would be spitting out bogus warnings for the user saying "your messages will be deleted from the server after 15 days" when really the setting is for 30 days. Being really explicit in the draft will ensure that client writers don't make that mistake. > > >>Another minor nit is the wording: >>"If the authentication step negotiates an integrity protection layer, >>the client SHOULD reissue the CAPA command after authenticating to >>check for active down-negotiation attacks." >> >>I'd like to see the wording changed to something like: >>"The client SHOULD reissue the CAPA command after authenticating to >>check for active down-negotiation attacks and to get any per user >>capability settings." > >The intent is to not require clients to issue two CAPA commands. The >client pretty much has to issue one before authenticating, to learn >which SASL mechanisms are supported, but doesn't have to issue on >afterwards, unless the first CAPA reveals that the server supports some >capabilities whose parameters might change after authentication, and >the client needs the most accurate values (it might be able to use the >more general ones), or the client wants to check for down-negotiation >attacks. *** Agreed. The point I was making is that it does not hurt to call out in the doc the need to recheck parameters that might change after authentication. The wording you have only mentions down negotiation attacks. A simple client that only uses a few basic SASL mechanisms, >for example, and only needs to know if the server supports TOP, UIDL, >and allows mail to be left on the server, doesn't need to issue two >CAPAs. (A client which only uses plaintext or APOP could issue only >one CAPA, after authenticating.) Agreed. And perhaps this adds more fuel to returning USER when there are per user settings. From owner-ietf-smtp Wed Aug 5 18:09:59 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA09912 for ietf-smtp-bks; Wed, 5 Aug 1998 18:09:59 -0700 (PDT) Received: from teat (1Cust131.tnt1.lihue.hi.gt.uu.net [208.255.250.131]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA09908 for ; Wed, 5 Aug 1998 18:09:57 -0700 (PDT) Date: Wed, 5 Aug 1998 18:09:57 -0700 (PDT) From: To: Message-Id: <989.283923.691457 HELP@SALESDOMAIN.COM> Subject: MLM CIGARETTES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk please pardon the email intrusion.If you are not interested in more information about our product (or service).We do sincerly apologize.to be removed from our list please e-mail us back with "remove" in the "subject".field. NATIVE TOBACCO FEATURING OMAHA CIGARETTES. 100% NATURAL TOBACCO. 10.95 A CARTON,ORDER 4CNT. AND RECEIVE FREE PRIORITY SHIPPING IN CONTINENTEL U.S. REFER OTHERS AND MAKE $$$$$$. "GREAT TASTE, GOOD PRICE!" FULL FLAVOR , LIGHTS , ULTRA LIGHTS, MENTHOL, YOU MAY ACCESS OUR FAX ON DEMAND AT 1-402-434-8488 DOC.#1131 OR YOU MY CALL OUR TOLL FREE # 1-888-248-6210 OR, VISIT OUR WEB SITE AT: http://www.nativetobacco.com member# is 9148-51956 use this to sign up no entree fee. HURRY COUNTRIES STILL AVALIABLE; From owner-ietf-smtp Sun Sep 6 17:02:09 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA29206 for ietf-smtp-bks; Sun, 6 Sep 1998 17:02:09 -0700 (PDT) Received: from lupinella.troll.no (lupinella.troll.no [195.0.254.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29202 for ; Sun, 6 Sep 1998 17:02:07 -0700 (PDT) Received: by troll.no id <79626-1127>; Mon, 7 Sep 1998 01:45:14 +0200 To: ietf-smtp@imc.org Subject: Latest spammer trick I've seen, and I absolutely hate it. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: Arnt Gulbrandsen Date: 07 Sep 1998 01:45:14 +0200 Message-ID: Lines: 23 Sender: owner-ietf-smtp@imc.org Precedence: bulk I got a message from ftpmail@gamers.org just now, saying that "my request" was syntactically invalid. Here's the headers of "my request". >From agulbra@nvg.unit.no Sun Sep 6 19:26:11 1998 >Received: from www16.web2010.com (www16.web2010.com [209.25.53.1]) > by thegate.gamers.org (8.8.5/8.8.7) with ESMTP id TAA09059 > for ; Sun, 6 Sep 1998 19:26:10 -0400 >From: agulbra@nvg.unit.no >Received: from pavilion.pavilion.net (dialup-04.intecnet.net [207.0.31.195]) by www16.web2010.com (8.8.5/8.6.9) with SMTP id TAA19283; Sun, 6 Sep 1998 19:25:18 -0400 (EDT) >Date: Sun, 6 Sep 1998 19:25:18 -0400 (EDT) >Message-Id: <199809062325.TAA19283@www16.web2010.com> >To: Customer@Yourplace.com >Subject: YOUR CLASSIFIED - AD / 333 NEWSPAPERS !!!! Do spammers do this all the time - using other people's real, valid addresses? Has there been any progress on SMTP authentication drafts? Last I saw was a kind of nice server-/gateway-based thing by Donald Eastman. Is it (or anything else) moving towards production use? --Arnt From owner-ietf-smtp Sun Sep 6 17:30:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA29295 for ietf-smtp-bks; Sun, 6 Sep 1998 17:30:37 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29291 for ; Sun, 6 Sep 1998 17:30:36 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-29 #30494) id <01J1HEHCQFTC91VTA4@INNOSOFT.COM> for ietf-smtp@imc.org; Sun, 6 Sep 1998 17:34:57 PDT Date: Sun, 06 Sep 1998 17:21:26 -0700 (PDT) From: Ned Freed Subject: Re: Latest spammer trick I've seen, and I absolutely hate it. In-reply-to: "Your message dated Mon, 07 Sep 1998 01:45:14 +0200" To: Arnt Gulbrandsen Cc: ietf-smtp@imc.org Message-id: <01J1HT9JLW2Q91VTA4@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk > I got a message from ftpmail@gamers.org just now, saying that "my > request" was syntactically invalid. Here's the headers of "my > request". > > ... > Do spammers do this all the time - using other people's real, valid > addresses? You've been lucky; spammers have been doing this sort of thing for years. > Has there been any progress on SMTP authentication drafts? There has been tremendous progess, both in terms of developing secure message formats as well as SMTP authentication services. Both the S/MIME and PGP groups met at the Chicago IETF and both groups are nearing completion of their work. See http://www.ietf.org/html.charters/wg-dir.html for information on and the status of these groups. There was an informal meeting at the Chicago IETF to discuss the SMTP AUTH draft. But this is not the right list for such discussions; the right list is the ietf-sasl list hosted, I believe, by imc.org. > Last I saw was a kind of nice server-/gateway-based thing by Donald Eastman. I suspect you are referring to MUSE, which was written by Donald Eastlake. AFAIK MUSE is dead. There is, however, a gateway security draft I've written that is similar and which was discussed at the MailRev BOF at the last IETF. A new version of the draft should be out soon and it will then be last called: draft-freed-gatesec-03.txt. > Is it (or anything else) moving towards production use? Both S/MIME and PGP have been in production use for some time now. However, unless and until use of such services is nearly universal they won't offer much hope of solving the spam problem. SMTP AUTH is certainly useful as a part of some relay blocking setups. We're now seeing rapid deployment of this in both clients and servers, although there is still some standards work to be done here. And while this service can in some local setups prevent certain kinds of forgeries, it is again no solution to the general spam or forgery problem. Ned From owner-ietf-smtp Wed Oct 21 06:13:16 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA08032 for ietf-smtp-bks; Wed, 21 Oct 1998 06:13:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA08028 for ; Wed, 21 Oct 1998 06:13:15 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA21660; Wed, 21 Oct 1998 09:14:17 -0400 (EDT) Message-Id: <199810211314.JAA21660@ietf.org> To: IETF-Announce: ; Cc: ietf-smtp@imc.org, ietf-ldapext@netscape.com From: The IESG SUBJECT: Last Call: LDAP Schema Definitions for Intranet Mail Routing - The mailRecipient Object Class to Informational Reply-to: iesg@ietf.org Date: Wed, 21 Oct 1998 09:14:17 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk The IESG has received a request to consider LDAP Schema Definitions for Intranet Mail Routing - The mailRecipient Object Class as a Informational. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 21, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-lachman-ldap-mail-routing-03.txt From owner-ietf-smtp Sun Oct 25 11:59:54 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18917 for ietf-smtp-bks; Sun, 25 Oct 1998 11:59:54 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18913 for ; Sun, 25 Oct 1998 11:59:53 -0800 (PST) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-29 #30494) with ESMTP id <01J3DXV5PR4694EOUS@INNOSOFT.COM> for ietf-smtp@imc.org; Sun, 25 Oct 1998 12:00:47 PDT Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.60]) by elvira.innosoft.com (PMDF V5.2-29 #13579) with SMTP id <0F1E00435FKWKQ@elvira.innosoft.com> for ietf-smtp@imc.org; Sun, 25 Oct 1998 12:00:33 -0800 (PST) Date: Sun, 25 Oct 1998 12:01:32 -0800 (PST) From: Chris Newman Subject: Re: Last Call: LDAP Schema Definitions for Intranet Mail Routing - The mailRecipient Object Class to Informational In-reply-to: <199810211314.JAA21660@ietf.org> Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: iesg@ietf.org Cc: ietf-smtp@imc.org, ietf-ldapext@netscape.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-smtp@imc.org Precedence: bulk On Wed, 21 Oct 1998, The IESG wrote: > The IESG has received a request to consider LDAP Schema Definitions for > Intranet Mail Routing - The mailRecipient Object Class > as a Informational. This has > been reviewed in the IETF but is not the product of an IETF Working > Group. I believe this document needs an IESG warning. Any interpretation of the local-part of the address, including LDAP lookups, is entirely inappropriate until it has been determined that the right-hand-side belongs to the host processing the message (section 5.2.16 of RFC 1123). It would be quite dangerous to permit an architecture where an incautious entry in an LDAP directory could alter mail-routing for a user or host outside the local domain. Therefore, it must be clear that this is a convention for local routing of email only by a host which is listed in an MX or A record for the domain on the right-hand-side of the address. - Chris From owner-ietf-smtp Thu Nov 5 13:25:45 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11726 for ietf-smtp-bks; Thu, 5 Nov 1998 13:25:45 -0800 (PST) Received: from skynet.xs4all.nl (skynet.xs4all.nl [194.109.13.245]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11721 for ; Thu, 5 Nov 1998 13:25:39 -0800 (PST) Received: from skynet.xs4all.nl ([10.1.0.5]) by skynet.xs4all.nl (SkyNet MailServer v1.00Beta) with SMTP id 3642165B.003; Thu, 05 Nov 1998 21:19:23 GMT Received: from SkyNet-Message_Server by skynet.xs4all.nl with Novell_GroupWise; Thu, 05 Nov 1998 22:19:13 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 05 Nov 1998 22:18:59 +0100 From: "Albert Louw" To: Subject: Proposed change for RFC0974 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id NAA11723 Sender: owner-ietf-smtp@imc.org Precedence: bulk Hi, After checking into some heavy problems with some commercial SMTP mailers and SMTP proxy servers it was time to check on the standards and I found that there's quite a problem there. The world is filling up with mail servers that are only available thru batched smtp (waiting to be released by the ETRN command in SMTP (rfc1985). Looking at the below part of RFC0974 (last paragraph of page 5, inserted below to make sure we're reading the same) a mailer MUST try the preference with the lowest value (in 9916433467503f the batched SMTP cases the actual host behind the dial-up link) and MAY try to go on to higher valued preferences if the first attempt fails. Since an average batched host link is down most of the time, the message is almost doomed to be undeliverable, if a mailer only implements the 'MUST' features. Although it's very easy to say that a 'off-line' mailhost should not have an MX record, it's still the reality today and with many ISPs their standard way of creating batched smtp. So, in conclusion, I'd propose a change for the part that a server MAY try the second host in line to MUST try at least the second host in line to ensure that all batched SMTP mail is delivered. Looking forward to your comment, ********* start quote ********** If the list of MX RRs is not empty, the mailer should try to deliver the message to the MXs in order (lowest preference value tried first). The mailer is required to attempt delivery to the lowest valued MX. Implementors are encouraged to write mailers so that they try the MXs in order until one of the MXs accepts the message, or all the MXs have been tried. A somewhat less demanding system, in which a fixed number of MXs is tried, is also reasonable. Note that multiple MXs may have the same preference value. In this case, all MXs at with a given value must be tried before any of a higher value are tried. In addition, in the special case in which there are several MXs with the lowest preference value, all of them should be tried before a message is deemed undeliverable. ********** end quote *********** --- Albert Louw Research & Development Dept. Azlan Network Services --- SkyNet MailServer v1.00Beta Copyright 1998 A.J. Louw. All Rights Reserved. From owner-ietf-smtp Thu Nov 5 14:41:32 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12905 for ietf-smtp-bks; Thu, 5 Nov 1998 14:41:32 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12901 for ; Thu, 5 Nov 1998 14:41:31 -0800 (PST) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 5 Nov 1998 13:57:05 -0800 Message-ID: <01D6C7224936D211BA450000F805D53818EF72@TOTO> From: "Doug Strauss (Exchange)" To: "'Albert Louw'" , ietf-smtp@imc.org Subject: RE: Proposed change for RFC0974 Date: Thu, 5 Nov 1998 13:57:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smtp@imc.org Precedence: bulk There are other conditions to think about with this logic. 1. The host which has the mail queued for delivery is obviously in the MX list. 2. Delivery to MX records should exclude all MX records of equal or greater values. Thus if the config is correct, you would only be trying to deliver to the lowest MX record which is either closer to the final host or is the static IP of the final destination. Assuming you are following this it should solve the problem you state does it not? -doug Microsoft Exchange SMTP test lead -----Original Message----- From: Albert Louw [mailto:albert.louw@skynet.xs4all.nl] Sent: Thursday, November 05, 1998 1:19 PM To: ietf-smtp@imc.org Subject: Proposed change for RFC0974 Hi, After checking into some heavy problems with some commercial SMTP mailers and SMTP proxy servers it was time to check on the standards and I found that there's quite a problem there. The world is filling up with mail servers that are only available thru batched smtp (waiting to be released by the ETRN command in SMTP (rfc1985). Looking at the below part of RFC0974 (last paragraph of page 5, inserted below to make sure we're reading the same) a mailer MUST try the preference with the lowest value (in 9916433467503f the batched SMTP cases the actual host behind the dial-up link) and MAY try to go on to higher valued preferences if the first attempt fails. Since an average batched host link is down most of the time, the message is almost doomed to be undeliverable, if a mailer only implements the 'MUST' features. Although it's very easy to say that a 'off-line' mailhost should not have an MX record, it's still the reality today and with many ISPs their standard way of creating batched smtp. So, in conclusion, I'd propose a change for the part that a server MAY try the second host in line to MUST try at least the second host in line to ensure that all batched SMTP mail is delivered. Looking forward to your comment, ********* start quote ********** If the list of MX RRs is not empty, the mailer should try to deliver the message to the MXs in order (lowest preference value tried first). The mailer is required to attempt delivery to the lowest valued MX. Implementors are encouraged to write mailers so that they try the MXs in order until one of the MXs accepts the message, or all the MXs have been tried. A somewhat less demanding system, in which a fixed number of MXs is tried, is also reasonable. Note that multiple MXs may have the same preference value. In this case, all MXs at with a given value must be tried before any of a higher value are tried. In addition, in the special case in which there are several MXs with the lowest preference value, all of them should be tried before a message is deemed undeliverable. ********** end quote *********** --- Albert Louw Research & Development Dept. Azlan Network Services --- SkyNet MailServer v1.00Beta Copyright 1998 A.J. Louw. All Rights Reserved. From owner-ietf-smtp Thu Nov 5 15:53:34 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13850 for ietf-smtp-bks; Thu, 5 Nov 1998 15:53:34 -0800 (PST) Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13846 for ; Thu, 5 Nov 1998 15:53:33 -0800 (PST) Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA19702; Thu, 5 Nov 1998 15:52:03 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-Id: In-Reply-To: <01D6C7224936D211BA450000F805D53818EF72@TOTO> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 5 Nov 1998 15:48:41 -0800 To: "Doug Strauss (Exchange)" , "'Albert Louw'" , ietf-smtp@imc.org From: Randall Gellens Subject: RE: Proposed change for RFC0974 Sender: owner-ietf-smtp@imc.org Precedence: bulk At 1:57 PM -0800 11/5/98, Doug Strauss (Exchange) wrote: > There are other conditions to think about with this logic. > 1. The host which has the mail queued for delivery is obviously in > the MX list. > 2. Delivery to MX records should exclude all MX records of equal or > greater values. > > Thus if the config is correct, you would only be trying to deliver to the > lowest MX record which is either closer to the final host or is the static > IP of the final destination. > > Assuming you are following this it should solve the problem you state does > it not? My understanding of Albert's message is this: 1. A number of domains are set up with their own, intermittently-connected mail server as the lowest-preference MX, and their ISP (with a full-time connection) as the next MX. 2. Random sites trying to send mail might use an SMTP server which, in compliance with the MUST of 974, only attempts to contact the lowest-preference MX, which is not likely to be connected. Note that 821bis, in "5. Address Resolution and Mail Handling" says: > To provide reliable mail transmission, the > SMTP client MUST be able to try (and retry) each of the relevant addresses > in this list in order, until a delivery attempt succeeds. However, there > MAY also be a configurable limit on the number of alternate addresses that > can be tried. In any case, a host SHOULD try at least two addresses. Which I think addresses Albert's concern. From owner-ietf-smtp Thu Nov 5 16:13:33 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14156 for ietf-smtp-bks; Thu, 5 Nov 1998 16:13:33 -0800 (PST) Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14152 for ; Thu, 5 Nov 1998 16:13:31 -0800 (PST) Received: FROM taxxi.com ([194.87.43.88]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 06 Nov 1998 03:12:02 +0300 Message-ID: <36423EA4.8BD0F7D1@taxxi.com> Date: Fri, 06 Nov 1998 03:11:16 +0300 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: "Doug Strauss (Exchange)" CC: "'Albert Louw'" , ietf-smtp@imc.org Subject: Re: Proposed change for RFC0974 References: <01D6C7224936D211BA450000F805D53818EF72@TOTO> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk "Doug Strauss (Exchange)" wrote: > There are other conditions to think about with this logic. > 1. The host which has the mail queued for delivery is obviously in > the MX list. > 2. Delivery to MX records should exclude all MX records of equal or > greater values. > > Thus if the config is correct, you would only be trying to deliver to the > lowest MX record which is either closer to the final host or is the static > IP of the final destination. > > Assuming you are following this it should solve the problem you state does > it not? I think Albert mentioned different problem: If the attempt to deliver mail to the host with lowest MX value will fail, client MUST (Albert propose), instead of MAY (current wording) try to send mail to the host with higher MX value. But the host with the lowest MX is batched host, that is down most of the time. The problem is that many implementations just ignore MAY and mail is undelivered. > -doug > Microsoft Exchange SMTP test lead > > -----Original Message----- > From: Albert Louw [mailto:albert.louw@skynet.xs4all.nl] > Sent: Thursday, November 05, 1998 1:19 PM > To: ietf-smtp@imc.org > Subject: Proposed change for RFC0974 > > Hi, > > After checking into some heavy problems with some commercial SMTP mailers > and SMTP proxy servers it was time to check on the standards and I found > that there's quite a problem there. > The world is filling up with mail servers that are only available thru > batched smtp (waiting to be released by the ETRN command in SMTP (rfc1985). > Looking at the below part of RFC0974 (last paragraph of page 5, inserted > below to make sure we're reading the same) a mailer MUST try the preference > with the lowest value (in 9916433467503f the batched SMTP cases the actual > host behind the dial-up link) and MAY try to go on to higher valued > preferences if the first attempt fails. > > Since an average batched host link is down most of the time, the message is > almost doomed to be undeliverable, if a mailer only implements the 'MUST' > features. Although it's very easy to say that a 'off-line' mailhost should > not have an MX record, it's still the reality today and with many ISPs their > standard way of creating batched smtp. > > So, in conclusion, I'd propose a change for the part that a server MAY try > the second host in line to MUST try at least the second host in line to > ensure that all batched SMTP mail is delivered. > > Looking forward to your comment, > > ********* start quote ********** > If the list of MX RRs is not empty, the mailer should try to deliver the > message to the MXs in order (lowest preference value tried first). The > mailer is required > to attempt delivery to the lowest valued MX. Implementors are > encouraged to write mailers so that they try the MXs in order until one of > the MXs accepts the > message, or all the MXs have been tried. A somewhat less demanding > system, in which a fixed number of MXs is tried, is also reasonable. Note > that multiple > MXs may have the same preference value. In this case, all MXs at with a > given value must be tried before any of a higher value are tried. In > addition, in the > special case in which there are several MXs with the lowest preference > value, all of them should be tried before a message is deemed undeliverable. > > ********** end quote *********** > > --- > Albert Louw > Research & Development Dept. > Azlan Network Services > > --- > SkyNet MailServer v1.00Beta > Copyright 1998 A.J. Louw. All Rights Reserved. Best Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team "ACAP Explorer" client Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm ------------------------------------------ From owner-ietf-smtp Thu Nov 5 16:24:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14310 for ietf-smtp-bks; Thu, 5 Nov 1998 16:24:48 -0800 (PST) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA14306 for ; Thu, 5 Nov 1998 16:24:47 -0800 (PST) Received: (qmail 12250 invoked by uid 666); 6 Nov 1998 00:27:51 -0000 Date: 6 Nov 1998 00:27:50 -0000 Message-ID: <19981106002750.12248.qmail@cr.yp.to> Mail-Followup-To: ietf-smtp@imc.org From: "D. J. Bernstein" To: ietf-smtp@imc.org Subject: Re: Proposed change for RFC0974 References: Sender: owner-ietf-smtp@imc.org Precedence: bulk Albert Louw writes: > Although it's very easy to say that a 'off-line' mailhost should not > have an MX record, Indeed. It's rude to put an IP address into a global DNS record if the address isn't globally reachable. You're wasting valuable client time that could have been used for successful deliveries to other hosts. Most MTAs, under most circumstances, will try at least two MX records, but if you're relying on this then you should fix your configuration. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html From owner-ietf-smtp Thu Nov 5 16:42:05 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14589 for ietf-smtp-bks; Thu, 5 Nov 1998 16:42:05 -0800 (PST) Received: from skynet.xs4all.nl (skynet.xs4all.nl [194.109.13.245]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14585 for ; Thu, 5 Nov 1998 16:42:02 -0800 (PST) Received: from skynet.xs4all.nl ([10.1.0.5]) by skynet.xs4all.nl (SkyNet MailServer v1.00Beta) with SMTP id 36424466.010; Fri, 06 Nov 1998 00:35:50 GMT Received: from SkyNet-Message_Server by skynet.xs4all.nl with Novell_GroupWise; Fri, 06 Nov 1998 01:35:40 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 06 Nov 1998 01:35:37 +0100 From: "Albert Louw" To: Cc: Subject: Re: Proposed change for RFC0974 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA14586 Sender: owner-ietf-smtp@imc.org Precedence: bulk That's the point yes. --- Albert Louw Research & Development Dept. Azlan Network Services >>> Alexey Melnikov 11/06 1:11 AM >>> "Doug Strauss (Exchange)" wrote: > There are other conditions to think about with this logic. > 1. The host which has the mail queued for delivery is obviously in > the MX list. > 2. Delivery to MX records should exclude all MX records of equal or > greater values. > > Thus if the config is correct, you would only be trying to deliver to the > lowest MX record which is either closer to the final host or is the static > IP of the final destination. > > Assuming you are following this it should solve the problem you state does > it not? I think Albert mentioned different problem: If the attempt to deliver mail to the host with lowest MX value will fail, client MUST (Albert propose), instead of MAY (current wording) try to send mail to the host with higher MX value. But the host with the lowest MX is batched host, that is down most of the time. The problem is that many implementations just ignore MAY and mail is undelivered. > -doug > Microsoft Exchange SMTP test lead > > -----Original Message----- > From: Albert Louw [mailto:albert.louw@skynet.xs4all.nl] > Sent: Thursday, November 05, 1998 1:19 PM > To: ietf-smtp@imc.org > Subject: Proposed change for RFC0974 > > Hi, > > After checking into some heavy problems with some commercial SMTP mailers > and SMTP proxy servers it was time to check on the standards and I found > that there's quite a problem there. > The world is filling up with mail servers that are only available thru > batched smtp (waiting to be released by the ETRN command in SMTP (rfc1985). > Looking at the below part of RFC0974 (last paragraph of page 5, inserted > below to make sure we're reading the same) a mailer MUST try the preference > with the lowest value (in 9916433467503f the batched SMTP cases the actual > host behind the dial-up link) and MAY try to go on to higher valued > preferences if the first attempt fails. > > Since an average batched host link is down most of the time, the message is > almost doomed to be undeliverable, if a mailer only implements the 'MUST' > features. Although it's very easy to say that a 'off-line' mailhost should > not have an MX record, it's still the reality today and with many ISPs their > standard way of creating batched smtp. > > So, in conclusion, I'd propose a change for the part that a server MAY try > the second host in line to MUST try at least the second host in line to > ensure that all batched SMTP mail is delivered. > > Looking forward to your comment, > > ********* start quote ********** > If the list of MX RRs is not empty, the mailer should try to deliver the > message to the MXs in order (lowest preference value tried first). The > mailer is required > to attempt delivery to the lowest valued MX. Implementors are > encouraged to write mailers so that they try the MXs in order until one of > the MXs accepts the > message, or all the MXs have been tried. A somewhat less demanding > system, in which a fixed number of MXs is tried, is also reasonable. Note > that multiple > MXs may have the same preference value. In this case, all MXs at with a > given value must be tried before any of a higher value are tried. In > addition, in the > special case in which there are several MXs with the lowest preference > value, all of them should be tried before a message is deemed undeliverable. > > ********** end quote *********** > > --- > Albert Louw > Research & Development Dept. > Azlan Network Services > > --- > SkyNet MailServer v1.00Beta > Copyright 1998 A.J. Louw. All Rights Reserved. Best Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team "ACAP Explorer" client Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm ------------------------------------------ --- SkyNet MailServer v1.00Beta Copyright 1998 A.J. Louw. All Rights Reserved. --- SkyNet MailServer v1.00Beta Copyright 1998 A.J. Louw. All Rights Reserved. From owner-ietf-smtp Fri Nov 6 03:14:39 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA09722 for ietf-smtp-bks; Fri, 6 Nov 1998 03:14:39 -0800 (PST) Received: from beethoven.paladincorp.com.au (paladincorp.com.au [203.29.35.220]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA09717 for ; Fri, 6 Nov 1998 03:14:34 -0800 (PST) Received: from wagner (wagner.paladincorp.com.au [192.168.0.6]) by beethoven.paladincorp.com.au (8.9.1/8.9.1) with ESMTP id WAA27536 for ; Fri, 6 Nov 1998 22:18:14 +1100 From: "Norman Widders" Date: Fri, 6 Nov 1998 22:18:45 +1100 (GMT) Subject: Re: Proposed change for RFC0974 To: Organization: Paladin Corporation X-Importance: Normal Message-Id: <77296569860505384-910351125-3.16c@wagner.paladincorp.com.au> In-Reply-To: <19981106002750.12248.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: <386418466481979044.wagner.1> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id DAA09719 Sender: owner-ietf-smtp@imc.org Precedence: bulk On 6 Nov 1998 00:27:50 -0000 "D. J. Bernstein" scribbled: Forgive the question, but whats the difference between an IP that is down because of lets say Scheduled Network-Maintenance _and_ an offline host ? Perhaps I am wrong but to all intents they appear the same, yes ? yours faithfully, Norman Widders > Albert Louw writes: > > Although it's very easy to say that a 'off-line' mailhost should > not > > have an MX record, > > Indeed. It's rude to put an IP address into a global DNS record if > the > address isn't globally reachable. You're wasting valuable client > time > that could have been used for successful deliveries to other hosts. > > Most MTAs, under most circumstances, will try at least two MX > records, > but if you're relying on this then you should fix your > configuration. -- ---------------------------------------------------------- Nørman Wïdders NIC: NW296-AU Paladin Corporation Pty Ltd. Ph: +612 9835-4782 Fax: +612 9864-0487 ---------------------------------------------------------- From owner-ietf-smtp Fri Nov 6 06:59:40 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA12323 for ietf-smtp-bks; Fri, 6 Nov 1998 06:59:40 -0800 (PST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12319 for ; Fri, 6 Nov 1998 06:59:39 -0800 (PST) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.9.2.Alpha0/8.9.2.Alpha0) with ESMTP id KAA30740; Fri, 6 Nov 1998 10:02:20 -0500 Message-Id: <199811061502.KAA30740@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: "Norman Widders" Cc: ietf-smtp@imc.org Subject: Re: Proposed change for RFC0974 In-Reply-To: Your message of "Fri, 06 Nov 1998 22:18:45 +1100." <77296569860505384-910351125-3.16c@wagner.paladincorp.com.au> 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[ <77296569860505384-910351125-3.16c@wagner.paladincorp.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1194623522P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 06 Nov 1998 10:02:19 -0500 Sender: owner-ietf-smtp@imc.org Precedence: bulk --==_Exmh_1194623522P Content-Type: text/plain; charset=us-ascii On Fri, 06 Nov 1998 22:18:45 +1100, you said: > Forgive the question, but whats the difference between an IP that is down > because of lets say Scheduled Network-Maintenance _and_ an offline host ? > Perhaps I am wrong but to all intents they appear the same, yes ? Well, for *one* delivery, they appear the same. The distinction is on the long-term differences. The machine I'm posting this from handles a fair amount of mail per day (500+ items a day or more). Now, if one recipient host does down for a backup for 30 minutes, my machine will just re-queue and re-try later. However, many machines I send mail to are *chronically* unavailable (to the point where a retry-every-30-mins strategy still times out after 5 days). Now, it just so happens that many of these offending sites don't HAVE MX entries, so we attempt delivery to their A record. I think the point that was being made was that if they *had* MX entries with a backup at their ISP, that they couldn't use ETRN to suck down their mail unless my machine properly handled rollover to the backup MX entry, because their machine wouldn't know to ETRN to mine, only to the ISP's server. Are there, in fact, any systems with significant market share that manage to get MX record handling wrong? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1194623522P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNkMPe9QBOOoptg9JAQGlggQAxTZ6gkVzu0nRQcl23XHkZ7O5A8bDhmFU g6Znug7nf+hz02kEiza1g/Yc6XHtd09f/J8NDtXDZ8zvN76JQvG9bFu4mPGpenGj WpjhqqlioXCmI4fowH5cECJImlUcQvB1nWjB+4XVYA9cT4+lX15M77wSg7NJCQk7 SmJiJaw/WFk= =yJav -----END PGP MESSAGE----- --==_Exmh_1194623522P-- From owner-ietf-smtp Fri Nov 6 07:22:52 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12519 for ietf-smtp-bks; Fri, 6 Nov 1998 07:22:52 -0800 (PST) Received: from lupinella.troll.no (lupinella.troll.no [195.0.254.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12515 for ; Fri, 6 Nov 1998 07:22:50 -0800 (PST) Received: by troll.no id <79562-8860>; Fri, 6 Nov 1998 16:25:24 +0100 To: Valdis.Kletnieks@vt.edu Cc: "Norman Widders" , ietf-smtp@imc.org Subject: Re: Proposed change for RFC0974 References: <77296569860505384-910351125-3.16c@wagner.paladincorp.com.au> <199811061502.KAA30740@black-ice.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: Arnt Gulbrandsen Date: 06 Nov 1998 16:25:23 +0100 In-Reply-To: Valdis.Kletnieks@vt.edu's message of "Fri, 06 Nov 1998 10:02:19 -0500" Message-ID: Lines: 11 Sender: owner-ietf-smtp@imc.org Precedence: bulk Valdis.Kletnieks@vt.edu > Are there, in fact, any systems with significant market share that manage > to get MX record handling wrong? What has significant market share, except sendmail and perhaps exchange? Whatever firewall says this behaved badly yesterday, market share or not: 220 CheckPoint FireWall-1 secure SMTP server --Arnt From owner-ietf-smtp Fri Nov 6 07:53:04 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12787 for ietf-smtp-bks; Fri, 6 Nov 1998 07:53:04 -0800 (PST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12783 for ; Fri, 6 Nov 1998 07:53:02 -0800 (PST) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WbMail V3.0) with SMTP id b5fb0247a4cf.7b7fc64e.wrm; Fri, 6 Nov 1998 10:56:28 -0500 Message-Id: <3.0.1.32.19981106105607.009745e0@lacroix.wildbear.on.ca> X-Sender: jack@lacroix.wildbear.on.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 06 Nov 1998 10:56:07 -0500 To: Valdis.Kletnieks@vt.edu, "Norman Widders" From: Jack De Winter Subject: Re: Proposed change for RFC0974 Cc: ietf-smtp@imc.org, mel@taxxi.com In-Reply-To: <199811061502.KAA30740@black-ice.cc.vt.edu> References: <77296569860505384-910351125-3.16c@wagner.paladincorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk At 10:02 AM 11/6/98 -0500, Valdis.Kletnieks@vt.edu wrote: >On Fri, 06 Nov 1998 22:18:45 +1100, you said: >Now, it just so happens that many of these offending sites don't HAVE >MX entries, so we attempt delivery to their A record. I think the point >that was being made was that if they *had* MX entries with a backup at >their ISP, that they couldn't use ETRN to suck down their mail unless my >machine properly handled rollover to the backup MX entry, because their >machine wouldn't know to ETRN to mine, only to the ISP's server. > >Are there, in fact, any systems with significant market share that manage >to get MX record handling wrong? My take on this was entirely different. I think the points being raised are: 1) According to Alexey's reading (and mine) of the rfc, you MUST read the first item of a MX record, and MAY go to the other MX records, in listed order of preference if a given MX record fails. 2) There are quite a few sites out there that have an A record and no MX record. 3) DJB feels that having a [static] A record for a site that is only ever intermittantly connected is a waste. [For the record, I think this is a bit silly too. Using DHCP from a dynamic pool would be better if a proper solution such as ETRN or ATRN is provided.] >From my POV, if you have a list of 500 people, and 5% of those addresses are hosts that have tenuous connections to the net, that means for 25 connections, you will try and connect to the first MX record or A record. In the standard case for both, you will fail the connection. For the MX record case, you may decide to go to MX record #2, which if it is the ISP, has a far better chance of being reachable. So, my take on this entire thing is that Alexey thinks it would be a real good idea if we did something about this. The A record case is one that we really can't do anything more about than hand-slapping ("you should really set up MX records for your mail server!"). For the MX record case, perhaps all Alexey is asking for is stronger wording to suggest: that if a given host will normally not be connected to the net that it not appear in the MX records, but have a method for contacting the node listed as the "most preferable" host by MX record, and getting the mail sent from there. ideas? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/homepages/jack/ From owner-ietf-smtp Sun Nov 8 14:15:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25048 for ietf-smtp-bks; Sun, 8 Nov 1998 14:15:58 -0800 (PST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25044 for ; Sun, 8 Nov 1998 14:15:49 -0800 (PST) Received: from alden ([193.216.167.143]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id XAA05767; Sun, 8 Nov 1998 23:16:00 +0100 Message-Id: <3.0.2.32.19981108225239.017915d0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sun, 08 Nov 1998 22:52:39 +0100 To: Jack De Winter , Valdis.Kletnieks@vt.edu, "Norman Widders" From: Harald Tveit Alvestrand Subject: Re: Proposed change for RFC0974 Cc: ietf-smtp@imc.org, mel@taxxi.com In-Reply-To: <3.0.1.32.19981106105607.009745e0@lacroix.wildbear.on.ca> References: <199811061502.KAA30740@black-ice.cc.vt.edu> <77296569860505384-910351125-3.16c@wagner.paladincorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smtp@imc.org Precedence: bulk At 10:56 06.11.98 -0500, Jack De Winter wrote: >3) DJB feels that having a [static] A record for a site that is only ever >intermittantly connected is a waste. [For the record, I think this is a >bit silly too. Using DHCP from a dynamic pool would be better if a >proper solution such as ETRN or ATRN is provided.] I've run with this solution for an interminenttly-connected PC for a few years (static IP on office LAN, laptop that went with me on trips). Sometimes its name escaped into the Great Wild Yonder, so people would send mail to it, so I had an MX (the lowest-valued one, in fact) pointing to my "spool" mailhost. (You can still find it in Four11, I think). If I had trusted my mail+news+other mailers not to reveal the hostname, I might not have bothered with the MX, and thus have been one of the Bad Boys with a working mail system on an interminenttly-connected host. But the A record was, I think, better present than absent; it was always telling the truth about the connection between the name and the IP address, just not saying anything about whether it was there or not. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-ietf-smtp Sun Nov 8 17:22:11 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA25781 for ietf-smtp-bks; Sun, 8 Nov 1998 17:22:11 -0800 (PST) Received: from limmax.k2r.org (limmax.k2r.org [210.160.188.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA25777 for ; Sun, 8 Nov 1998 17:22:09 -0800 (PST) Received: (qmail 3981 invoked by uid 1000); 9 Nov 1998 01:25:10 -0000 Message-ID: <19981109012510.3980.qmail@k2r.org> Date: Mon, 9 Nov 1998 10:25:10 +0900 (JST) From: Kenji Rikitake To: ietf-smtp@imc.org Subject: Re: Proposed change for RFC0974 In-Reply-To: <3.0.1.32.19981106105607.009745e0@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk On Fri, 6 Nov 1998, Jack De Winter wrote: > 1) According to Alexey's reading (and mine) of the rfc, you MUST read > the first item of a MX record, and MAY go to the other MX records, in > listed order of preference if a given MX record fails. I think current SMTP implementation for most MTAs assume that the recipient MUST be able to handle the SMTP connection requests from the sender at any time. So for intermittently-connected sites, the first MX *MUST* be set to a mail server which is also a continuously-connected site anyway, for a reliable service. I understand what Alexey writes, but I think this is rather an operational issue than a standardization issue, since requiring all MTAs to poll all MX sites sounds quite inpractical to me. Maybe the "stronger wording to suggest" Jack mentioned is one of few things we can do for revising the standard document. // Kenji Rikitake From owner-ietf-smtp Wed Nov 11 14:53:53 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29521 for ietf-smtp-bks; Wed, 11 Nov 1998 14:53:53 -0800 (PST) Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29517 for ; Wed, 11 Nov 1998 14:53:50 -0800 (PST) Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 12 Nov 1998 01:57:46 +0300 Message-ID: <364A1636.6CDABBC6@taxxi.com> Date: Thu, 12 Nov 1998 01:56:55 +0300 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: SMTP server resides on non standard port. How can I send mail to it? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Hi, I need to set up my SMTP server on non standard port (for whatever reasons). Anybody supports the following trick to send mail to SMTP on different port: @: If this question was discussed before, just point me politely :-) to the required information. Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm Fax (in San Diego, California): 1 (619) 8393837 ------------------------------------------ From owner-ietf-smtp Wed Nov 11 15:19:56 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29815 for ietf-smtp-bks; Wed, 11 Nov 1998 15:19:56 -0800 (PST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29811 for ; Wed, 11 Nov 1998 15:19:55 -0800 (PST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by pita.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA10465; Wed, 11 Nov 1998 15:22:43 -0800 (PST) Date: Wed, 11 Nov 1998 15:22:43 -0800 (PST) From: Dan Wing To: Alexey Melnikov cc: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I send mail to it? In-Reply-To: <364A1636.6CDABBC6@taxxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk On Thu, 12 Nov 1998, Alexey Melnikov wrote: > Hi, > > I need to set up my SMTP server on non standard port (for whatever > reasons). > Anybody supports the following trick to send mail to SMTP on different > port: > > @: > > If this question was discussed before, just point me politely :-) to the > required information. There are ways to do this with almost every mailer. Please ask your question on the "comp.mail.misc" newsgroup. -Dan Wing From owner-ietf-smtp Wed Nov 11 16:10:55 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00371 for ietf-smtp-bks; Wed, 11 Nov 1998 16:10:55 -0800 (PST) Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00367 for ; Wed, 11 Nov 1998 16:10:52 -0800 (PST) Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 12 Nov 1998 03:14:49 +0300 Message-ID: <364A2841.F46D223A@taxxi.com> Date: Thu, 12 Nov 1998 03:13:53 +0300 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I send mailto it? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Dan Wing wrote: > On Thu, 12 Nov 1998, Alexey Melnikov wrote: > > > Hi, > > > > I need to set up my SMTP server on non standard port (for whatever > > reasons). > > Anybody supports the following trick to send mail to SMTP on different > > port: > > > > @: > > > > If this question was discussed before, just point me politely :-) to the > > required information. > > There are ways to do this with almost every mailer. > > Please ask your question on the "comp.mail.misc" newsgroup. I am sorry for not being precise. I mean *server implementations* (I am not interested how to configure clients, I want to know if there is any server (MTA-to-MTA) [de-facto] standard) Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm Fax (in San Diego, California): 1 (619) 8393837 ------------------------------------------ From owner-ietf-smtp Wed Nov 11 16:11:35 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00388 for ietf-smtp-bks; Wed, 11 Nov 1998 16:11:35 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA00384 for ; Wed, 11 Nov 1998 16:11:34 -0800 (PST) Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA14506; Wed, 11 Nov 1998 16:14:20 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-Id: In-Reply-To: <364A1636.6CDABBC6@taxxi.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Wed, 11 Nov 1998 16:03:43 -0800 To: Alexey Melnikov , ietf-smtp@imc.org From: Randall Gellens Subject: Re: SMTP server resides on non standard port. How can I send mail to it? Sender: owner-ietf-smtp@imc.org Precedence: bulk At 1:56 AM +0300 11/12/98, Alexey Melnikov wrote: > Anybody supports the following trick to send mail to SMTP on different > port: > > @: I'm not sure what specifically you are asking for. Do you mean you want to attach a port number to an email address, so that when the message gets through whichever SMTP servers are needed beforehand, and is ready to be sent to the final one (the one for the end user), you want to instruct the prior SMTP server to use a different port? That is: You send message to your local SMTP server, it relays to server X, ... it sends to final recipient's server, using non-standard port? Or do you simply want to instruct your client to use a different port when submitting messages? From owner-ietf-smtp Wed Nov 11 19:21:31 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02904 for ietf-smtp-bks; Wed, 11 Nov 1998 19:21:31 -0800 (PST) Received: from beethoven.paladincorp.com.au (paladincorp.com.au [203.29.35.220]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02898 for ; Wed, 11 Nov 1998 19:21:27 -0800 (PST) Received: from wagner (wagner.paladincorp.com.au [192.168.0.6]) by beethoven.paladincorp.com.au (8.9.1/8.9.1) with ESMTP id OAA07875 for ; Thu, 12 Nov 1998 14:25:38 +1100 From: "Norman Widders" Date: Thu, 12 Nov 1998 14:26:07 +1100 (GMT) Subject: Re: SMTP server resides on non standard port. How can I send mail to it? To: Organization: Paladin Corporation X-Importance: Normal Message-Id: <72467026630533390-910841167-3.17a@wagner.paladincorp.com.au> In-Reply-To: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: <430114932181269928.wagner.1> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id TAA02899 Sender: owner-ietf-smtp@imc.org Precedence: bulk On Wed, 11 Nov 1998 16:03:43 -0800 Randall Gellens scribbled: Hi, I believe our friend Alexey means like a URL, where I can specify http://www.some.net:70/some.html .. and some mechanism for parsing the port regardless of client or daemon.... ie, me@some.net:24 from the destination, my thoughts are that nobody has probably tried it yet, but it looks interesting imho :) Cheers > At 1:56 AM +0300 11/12/98, Alexey Melnikov wrote: > > > Anybody supports the following trick to send mail to SMTP on > different > > port: > > > > @: > > I'm not sure what specifically you are asking for. Do you mean you > want to attach a port number to an email address, so that when the > message gets through whichever SMTP servers are needed beforehand, > and > is ready to be sent to the final one (the one for the end user), you > > want to instruct the prior SMTP server to use a different port? That > > is: > > You send message to your local SMTP server, it relays to server X, > ... > it sends to final recipient's server, using non-standard port? > > Or do you simply want to instruct your client to use a different port > > when submitting messages? > -- ---------------------------------------------------------- Nørman Wïdders NIC: NW296-AU Paladin Corporation Pty Ltd. Ph: +612 9835-4782 Fax: +612 9864-0487 ---------------------------------------------------------- From owner-ietf-smtp Wed Nov 11 20:28:28 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA03296 for ietf-smtp-bks; Wed, 11 Nov 1998 20:28:28 -0800 (PST) Received: from a4.jck.com ([206.99.215.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA03292 for ; Wed, 11 Nov 1998 20:28:23 -0800 (PST) Received: from p6.jck.com ("port 1362"@[206.99.215.34]) by a4.jck.com (PMDF V5.1-11 #C3296) with SMTP id <0F2A0042MKKRHB@a4.jck.com> for ietf-smtp@imc.org; Wed, 11 Nov 1998 23:31:40 -0500 (EST) Date: Wed, 11 Nov 1998 23:30:49 -0500 (Eastern Standard Time) From: John C Klensin Subject: Re: SMTP server resides on non standard port. How can I send mailto it? In-reply-to: <364A2841.F46D223A@taxxi.com> To: Alexey Melnikov 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 Thu, 12 Nov 1998 03:13:53 +0300 Alexey Melnikov wrote: > I am sorry for not being precise. I mean *server implementations* (I am > not interested how to configure clients, I want to know if there is any > server (MTA-to-MTA) [de-facto] standard) Short answer: No There are also multiple reasons why this would be a bad idea. They include reintroducing a reason for explicit source routes and a great deal of confusion if the target domain actually labels a set of MX records for hosts that don't all use the same port. If this is "first hop" (e.g., "message submission"), then the comments others have made about configuring clients probably apply. If it is trying to reach a general far-end system on a peculiar port, it probably can't be made to work in the general case: the port data would really have to be in the DNS somehow, and running standards/well-known services on variant ports is usually considered offensive to both the architecture and even elementary security considerations. john From owner-ietf-smtp Thu Nov 12 15:07:26 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16889 for ietf-smtp-bks; Thu, 12 Nov 1998 15:07:26 -0800 (PST) Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16884 for ; Thu, 12 Nov 1998 15:07:25 -0800 (PST) Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA02305; Thu, 12 Nov 1998 15:10:07 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-Id: In-Reply-To: <364A2841.F46D223A@taxxi.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 12 Nov 1998 15:02:40 -0800 To: Alexey Melnikov , ietf-smtp@imc.org From: Randall Gellens Subject: Re: SMTP server resides on non standard port. How can I send mailto it? Sender: owner-ietf-smtp@imc.org Precedence: bulk At 3:13 AM +0300 11/12/98, Alexey Melnikov wrote: > I am sorry for not being precise. I mean *server implementations* (I am > not interested how to configure clients, I want to know if there is any > server (MTA-to-MTA) [de-facto] standard) One way to do this is to have the MX records point to a relay SMTP server that listens on port 25, and has been configured to talk to your SMTP server on whatever port is likes. I'm not sure what this buys you in the general case, but it might be useful in some limited situations. From owner-ietf-smtp Thu Nov 12 15:19:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17132 for ietf-smtp-bks; Thu, 12 Nov 1998 15:19:43 -0800 (PST) Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17128 for ; Thu, 12 Nov 1998 15:19:41 -0800 (PST) Received: from taxxi.com ([194.87.43.61]) by mail.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 163; Fri, 13 Nov 1998 02:36:41 +0300 Message-ID: <364B6DBB.D702CB53@taxxi.com> Date: Fri, 13 Nov 1998 02:22:36 +0300 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Randall Gellens CC: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I sendmail to it? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Randall Gellens wrote: > At 1:56 AM +0300 11/12/98, Alexey Melnikov wrote: > > > Anybody supports the following trick to send mail to SMTP on different > > port: > > > > @: > > I'm not sure what specifically you are asking for. Do you mean you > want to attach a port number to an email address, so that when the > message gets through whichever SMTP servers are needed beforehand, and > is ready to be sent to the final one (the one for the end user), you > want to instruct the prior SMTP server to use a different port? That > is: > > You send message to your local SMTP server, it relays to server X, ... > it sends to final recipient's server, using non-standard port? Yes. (Suppose I have two SMTP servers on different ports on the same machine). > Or do you simply want to instruct your client to use a different port > when submitting messages? No, this is too simple :-) Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm Fax (in San Diego, California): 1 (619) 8393837 ------------------------------------------ From owner-ietf-smtp Thu Nov 12 15:28:58 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17306 for ietf-smtp-bks; Thu, 12 Nov 1998 15:28:58 -0800 (PST) Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17302 for ; Thu, 12 Nov 1998 15:28:56 -0800 (PST) Received: from taxxi.com ([194.87.43.61]) by mail.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 166; Fri, 13 Nov 1998 02:46:04 +0300 Message-ID: <364B6FED.C1922BEC@taxxi.com> Date: Fri, 13 Nov 1998 02:31:58 +0300 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: John C Klensin CC: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I send mailto it? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk John C Klensin wrote: > On Thu, 12 Nov 1998 03:13:53 +0300 Alexey Melnikov > wrote: > > > I am sorry for not being precise. I mean *server implementations* (I am > > not interested how to configure clients, I want to know if there is any > > server (MTA-to-MTA) [de-facto] standard) > > Short answer: No > > There are also multiple reasons why this would be a bad idea. > They include reintroducing a reason for explicit source routes Why? > and a great deal of confusion if the target domain actually > labels a set of MX records for hosts that don't all use the same > port. You are right, this is confusing when we have multiple MX records. I missed this point when asked the question. > If this is "first hop" (e.g., "message submission"), then > the comments others have made about configuring clients probably > apply. Agreed. > If it is trying to reach a general far-end system on a > peculiar port, it probably can't be made to work in the general > case: the port data would really have to be in the DNS somehow, > and running standards/well-known services on variant ports is > usually considered offensive to both the architecture and even > elementary security considerations. I am not insisting on using @: syntax. I would like to know how this idea was implemented (if it was) : server is specially configured to connect particular server on non standard port (i.e. the use of configuration files), server uses DNS Well-known service record or Service Location Protocol, other ways. -- Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm Fax (in San Diego, California): 1 (619) 8393837 ------------------------------------------ From owner-ietf-smtp Thu Nov 12 15:31:48 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17364 for ietf-smtp-bks; Thu, 12 Nov 1998 15:31:48 -0800 (PST) Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17360 for ; Thu, 12 Nov 1998 15:31:46 -0800 (PST) Received: from taxxi.com ([194.87.43.61]) by mail.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 125; Fri, 13 Nov 1998 02:48:51 +0300 Message-ID: <364B7095.2C6425FA@taxxi.com> Date: Fri, 13 Nov 1998 02:34:45 +0300 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: Randall Gellens CC: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I sendmailto it? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk Randall Gellens wrote: > At 3:13 AM +0300 11/12/98, Alexey Melnikov wrote: > > > I am sorry for not being precise. I mean *server implementations* (I am > > not interested how to configure clients, I want to know if there is any > > server (MTA-to-MTA) [de-facto] standard) > > One way to do this is to have the MX records point to a relay SMTP > server that listens on port 25, and has been configured to talk to your > SMTP server on whatever port is likes. I'm not sure what this buys you > in the general case, but it might be useful in some limited situations. Yes, I know that some mail proxy can be used in this way. -- Regards, Alexey Melnikov ------------------------------------------ SMTP/POP3/IMAP4/ACAP servers creation team Epsylon Technologies, Russia http://www.taxxi.com Imap Development Kit (my own product) http://194.87.43.111/homerus/mail/idk/index.htm Fax (in San Diego, California): 1 (619) 8393837 ------------------------------------------ From owner-ietf-smtp Thu Nov 12 20:28:37 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA22158 for ietf-smtp-bks; Thu, 12 Nov 1998 20:28:37 -0800 (PST) Received: from a4.jck.com ([206.99.215.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA22153 for ; Thu, 12 Nov 1998 20:28:35 -0800 (PST) Received: from p6.jck.com ("port 1106"@[206.99.215.34]) by a4.jck.com (PMDF V5.1-11 #C3296) with SMTP id <0F2C00711F9EB9@a4.jck.com> for ietf-smtp@imc.org; Thu, 12 Nov 1998 23:32:02 -0500 (EST) Date: Thu, 12 Nov 1998 23:32:00 -0500 (Eastern Standard Time) From: John C Klensin Subject: Re: SMTP server resides on non standard port. How can I send mailto it? In-reply-to: <364B6FED.C1922BEC@taxxi.com> To: Alexey Melnikov 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, 13 Nov 1998 02:31:58 +0300 Alexey Melnikov wrote: > > There are also multiple reasons why this would be a bad idea. > > They include reintroducing a reason for explicit source routes > > Why? So that one can specify different ports at different hops. If there is enough requirement for this to introduce a protocol/ syntax change, then there ought to be enough that I might want to use it down a successively-better-preference MX path. But the DNS can't accomodate different port numbers, so one might want <@host1:port1, @host2:port2, @host3: user@host4:port4> note this also points out a little problem with the syntax you suggest. > I am not insisting on using @: syntax. > I would like to know how this idea was implemented (if it was) : server is > specially configured to connect particular server on non standard port (i.e. > the use of configuration files), server uses DNS Well-known service record or > Service Location Protocol, other ways. To the best of my knowledge, this has been done by private client-side (more generally, sender-side) configuration and out of band communication about the ports to use. There are no DNS or SMTP facilities for specifying funny ports in an address. john From owner-ietf-smtp Fri Nov 13 12:43:47 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29757 for ietf-smtp-bks; Fri, 13 Nov 1998 12:43:47 -0800 (PST) Received: from torque.pothole.com (torque.pothole.com [192.245.52.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29753 for ; Fri, 13 Nov 1998 12:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id PAA12249 for ietf-smtp@imc.org; Fri, 13 Nov 1998 15:47:06 -0500 (EST) Message-Id: <199811132047.PAA12249@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I send mailto it? In-reply-to: Your message of "Thu, 12 Nov 1998 23:32:00 EST." Date: Fri, 13 Nov 1998 15:47:06 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-ietf-smtp@imc.org Precedence: bulk Actually, you can specify the target port in the SRV resource record (RFC 2052), which is currently Experimental and more or less ignored by everyone. However, there is a move afoot to put it on standards track (draft-ietf-dnsind-rfc2052bis-00.txt). If that happens and it gets widely deployed, then in a few years it might solve your problem. Donald From: John C Klensin Date: Thu, 12 Nov 1998 23:32:00 -0500 (Eastern Standard Time) In-reply-to: <364B6FED.C1922BEC@taxxi.com> To: Alexey Melnikov Cc: ietf-smtp@imc.org Message-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Authentication: none Sender: owner-ietf-smtp@imc.org Precedence: bulk > >On Fri, 13 Nov 1998 02:31:58 +0300 Alexey Melnikov > wrote: > >> > There are also multiple reasons why this would be a bad idea. >> > They include reintroducing a reason for explicit source routes >> >> Why? > >So that one can specify different ports at different hops. If >there is enough requirement for this to introduce a protocol/ >syntax change, then there ought to be enough that I might want >to use it down a successively-better-preference MX path. But >the DNS can't accomodate different port numbers, so one might >want > <@host1:port1, @host2:port2, @host3: user@host4:port4> >note this also points out a little problem with the syntax you >suggest. > > >> I am not insisting on using @: syntax. >> I would like to know how this idea was implemented (if it was) : server is >> specially configured to connect particular server on non standard port (i.e. >> the use of configuration files), server uses DNS Well-known service record or >> Service Location Protocol, other ways. > >To the best of my knowledge, this has been done by private >client-side (more generally, sender-side) configuration and out >of band communication about the ports to use. There are no DNS >or SMTP facilities for specifying funny ports in an address. > > john From owner-ietf-smtp Mon Nov 16 19:14:43 1998 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA23757 for ietf-smtp-bks; Mon, 16 Nov 1998 19:14:43 -0800 (PST) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA23753 for ; Mon, 16 Nov 1998 19:14:41 -0800 (PST) Received: from spot.cs.utk.edu (LOCALHOST [127.0.0.1]) by spot.cs.utk.edu (cf v3.2) with ESMTP id WAA21641; Mon, 16 Nov 1998 22:18:04 -0500 (EST) Message-Id: <199811170318.WAA21641@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Donald E. Eastlake 3rd" cc: ietf-smtp@imc.org Subject: Re: SMTP server resides on non standard port. How can I send mailto it? In-reply-to: Your message of "Fri, 13 Nov 1998 15:47:06 EST." <199811132047.PAA12249@torque.pothole.com> Date: Mon, 16 Nov 1998 22:18:03 -0500 Sender: owner-ietf-smtp@imc.org Precedence: bulk > Actually, you can specify the target port in the SRV resource record > (RFC 2052), which is currently Experimental and more or less ignored > by everyone. However, there is a move afoot to put it on standards > track (draft-ietf-dnsind-rfc2052bis-00.txt). If that happens and it > gets widely deployed, then in a few years it might solve your problem. Yes, but we already have MX. We don't need SRV for email, and we certainly don't need the disruption that would result from having yet another way to find the recipient's mail domain. Keith From owner-ietf-smtp Fri Jan 15 11:21:17 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23778 for ietf-smtp-bks; Fri, 15 Jan 1999 08:44:21 -0800 (PST) Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23762; Fri, 15 Jan 1999 08:44:18 -0800 (PST) Date: Fri, 15 Jan 1999 08:44:18 -0800 (PST) Message-Id: <199901151644.IAA23762@mail.proper.com> From: List Manager of ietf-smtp To: ietf-smtp@imc.org Subject: How to be removed from this list Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings again. Occasionally, people will sign up for a mailing list and forget how to be removed. This message is a reminder for those folks. First off, when you subscribe to a mailing list, you almost always get a first message from the list owner telling you about the mailing list, and explaining how to unsubscribe. It is always a good idea to keep those messages, since you never know when you will need to unsubscribe. This is particularly useful when you change email addresses, because it is difficult to unsubscribe from a list after you have a different mailing address. In the case of this list, the method to unsubscribe is to send a message to: ietf-smtp-request@imc.org with the single word: unsubscribe in the body of the message. This is the same as it always has been. To make this easier for you, I have crafted this message so that you should be able to simply reply to this message, and the reply address should be ietf-smtp-request@imc.org (although some mail clients screw this up...). Remove everything from the body of the reply, and put in the single word: unsubscribe If you have tried this method, and the mailing list software won't let you unsubscribe, it is probably because your address has changed. In that case, please send a message to subs@imc.org stating which list (or lists) you want to unsubscribe from, and what you think your previous address was. There is a human (that's me!) who will then try to take care of your request, often within a few days. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Thu Mar 4 23:53:00 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA29283 for ietf-smtp-bks; Thu, 4 Mar 1999 23:53:00 -0800 (PST) Received: from baikonur.demo.ru (www.demo.ru [194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA29265; Thu, 4 Mar 1999 23:51:00 -0800 (PST) Received: from mail.demo.ru ([194.87.43.31]) by baikonur.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 366; Fri, 5 Mar 1999 10:56:49 +0300 Received: from taxxi.com ([24.108.17.129]) by mail.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 204; Fri, 5 Mar 1999 11:15:05 +0300 Message-ID: <36DF8CF4.6A43165@taxxi.com> Date: Fri, 05 Mar 1999 00:51:16 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-submit@imc.org CC: ietf-smtp@imc.org Subject: Submit Server Discovery extension Content-Type: multipart/mixed; boundary="------------529A92F3833DD2685090534E" Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a multi-part message in MIME format. --------------529A92F3833DD2685090534E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've missed deadline, so I am posting new draft to mailing lists. Suggestions are welcome. Also it would be very interested to know whether this feature will have support. -- Regards, Alexey Melnikov --------------529A92F3833DD2685090534E Content-Type: text/plain; charset=us-ascii; name="draft-melnikov-submit-port-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-melnikov-submit-port-00.txt" An SMTP Extension for discovering the location of Submit server Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this draft is unlimited. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Abstract [SUBMIT] defines a new protocol used for message submission. In many circumstances it could be located on port different from the traditional SMTP port. The fate of a message may depend on whether particular server is Submit or SMTP server, because even inside the same organization Submit and SMTP servers may inforce different user policy. Thus the correct discovering of submit server location is important. Currently there is no standardized and generally acceptable way to discover the location of submit server. One may use DNS SRV records, the other may choose to query SLP, LDAP or ACAP server. This document describes an easy way to discover the location of submit server while staying in bounds of SMTP protocol. The advantage of this document is its almost zero cost of implementation. It is possible that that protocol will be eliminated in the future by widely deployed general use protocol. 0. Meta-information on this draft This information is intended to facilitate discussion. It will be removed when this document leaves the Internet-Draft stage. 0.1 Open Issues Should "AUTH=" authentication parameter be allowed in Submit URL? Should multiple URL's be allowed? 1. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 2. Framework for the Submit Server Discovery SMTP service extension The Submit Server Location Discovery SMTP service extension uses the SMTP service extension mechanism described in [ESMTP]. The following SMTP service extension is therefore defined: (1) The name of the SMTP service extension is "Submit Server Location Discovery". (2) The EHLO keyword value associated with this service extension is "SUBMIT". (3) One optional parameter is allowed with this EHLO keyword value, a SMTP URL that specifies the location of Submit Server (referral). The syntax of the parameter is defined in section 5. If the parameter is omitted, this means that that server is Submit Server itself. (4) no additional SMTP verbs are defined by this extension. 4. The Submit Server Discovery SMTP service extension A SMTP client wishing to locate Submit Server may issue the EHLO command to start a SMTP session and to determine if the SMTP server supports the service extension. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword SUBMIT, then the Submit Server Discovery SMTP service extension is supported by the server and client may use the parameter of SUBMIT keyword as an address of Submit Server. The parameter of SUBMIT keyword is either SMTP URL or Truncated SMTP URL. The later is a brief form of SMTP URL with omitted host name. In order to connect to Submit Server client should add the host it used to connect to this particular SMTP Server. A SUBMIT capable ESMTP server SHOULD NOT return an URL referencing to a server that will return a referral. A client MUST NOT follow more than 10 levels of referral without consulting the user. Examples: S: 220 smtp.example.com ESMTP server ready C: EHLO dragon.demo.ru S: 250-smtp.example.com S: 250-AUTH CRAM-MD5 DIGEST-MD5 S: 250 SUBMIT smtp://submit.example.com:11111 C: QUIT 5. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF]. This uses the ABNF core rules as specified in Appendix A of the ABNF specification [ABNF]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. Tokens that are used but otherwise unspecified come from [SMTP-URL]. submit-referral = (url-smtp / url-smtp-truncated) url-smtp-truncated = "smtp://" ":" [port] ;; See [BASIC-URL] for definition of "port". ;; Client should use the same host and ;; specified Submit port. ;; If no port specified then default Submit ;; port is used 6. Security Considerations The Submit Server Discovery extension makes use of SMTP URLs, and as such, have the same security considerations as general internet URLs [BASIC-URL], and in particular SMTP URLs [SMTP-URL]. 7. Copyright Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. References [SMTP-URL] Earhart, "An SMTP URL Interface", Work in progress, [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9. Author's Address Alexey Melnikov Epsylon Technologies Home address : 121293, Russia, Moscow, general Ermolov street, 6 - 90 Email: mel@taxxi.com Fax (San Diego, CA) : 1 (619) 8393837 --------------529A92F3833DD2685090534E-- From owner-ietf-smtp Thu Mar 11 15:32:33 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14910 for ietf-smtp-bks; Thu, 11 Mar 1999 15:32:33 -0800 (PST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14906; Thu, 11 Mar 1999 15:32:32 -0800 (PST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by pita.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA10879; Thu, 11 Mar 1999 15:38:05 -0800 (PST) Date: Thu, 11 Mar 1999 15:38:05 -0800 (PST) From: Dan Wing To: Alexey Melnikov cc: ietf-submit@imc.org, ietf-smtp@imc.org Subject: Re: Submit Server Discovery extension In-Reply-To: <36DF8CF4.6A43165@taxxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote: > I've missed deadline, so I am posting new draft to mailing lists. > Suggestions are welcome. Also it would be very interested to know > whether this feature will have support. How does one determine the IP address (or hostname) of the first SMTP server (which supports the SUBMIT service extension and tells you the submit server you're supposed to use)? -Dan Wing From owner-ietf-smtp Thu Mar 11 18:16:50 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA16604 for ietf-smtp-bks; Thu, 11 Mar 1999 18:16:50 -0800 (PST) Received: from baikonur.demo.ru (www.demo.ru [194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16594; Thu, 11 Mar 1999 18:16:19 -0800 (PST) Received: from taxxi.com ([24.108.17.129]) by baikonur.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 154; Fri, 12 Mar 1999 05:22:08 +0300 Message-ID: <36E878E0.F316B84B@taxxi.com> Date: Thu, 11 Mar 1999 19:16:01 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Wing CC: ietf-submit@imc.org, ietf-smtp@imc.org Subject: Re: Submit Server Discovery extension References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Dan Wing wrote: > On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote: > > > I've missed deadline, so I am posting new draft to mailing lists. > > Suggestions are welcome. Also it would be very interested to know > > whether this feature will have support. > > How does one determine the IP address (or hostname) of the first SMTP > server (which supports the SUBMIT service extension and tells you the > submit server you're supposed to use)? Client should connect to standard (25) SMTP service port first. If server supports Submit extension and is not submit server it will reference client to the right location. -- Regards, AMelnikov From owner-ietf-smtp Thu Mar 11 22:24:03 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA29263 for ietf-smtp-bks; Thu, 11 Mar 1999 22:24:03 -0800 (PST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA29252; Thu, 11 Mar 1999 22:24:00 -0800 (PST) Received: from pita.cisco.com (pita.cisco.com [171.71.68.13]) by pita.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA21715; Thu, 11 Mar 1999 22:29:30 -0800 (PST) Date: Thu, 11 Mar 1999 22:29:30 -0800 (PST) From: Dan Wing To: Alexey Melnikov cc: ietf-submit@imc.org, ietf-smtp@imc.org Subject: Re: Submit Server Discovery extension In-Reply-To: <36E878E0.F316B84B@taxxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 11 Mar 1999 19:16 -0700, Alexey Melnikov wrote: > > On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote: > > > > > I've missed deadline, so I am posting new draft to mailing lists. > > > Suggestions are welcome. Also it would be very interested to know > > > whether this feature will have support. > > > > How does one determine the IP address (or hostname) of the first SMTP > > server (which supports the SUBMIT service extension and tells you the > > submit server you're supposed to use)? > > Client should connect to standard (25) SMTP service port first. If server > supports Submit extension and is not submit server it will reference > client to the right location. I don't see the value here. Why would a client be configured with the address of an SMTP server that is something _other_ than its submit server? If you do decide to go forward with the I-D, though, you certainly need to add information on what a client is supposed to do if it can't resolve the information provided in the SUBMIT response (such as unknown URI or unresolvable DNS hostname). Should the client ignore the ever-so-gentle request to not use that SMTP server as its submit server and just go ahead and use it anyway, or ? -Dan Wing From owner-ietf-smtp Fri Mar 12 10:01:49 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17295 for ietf-smtp-bks; Fri, 12 Mar 1999 10:01:49 -0800 (PST) Received: from mail.demo.ru ([194.87.43.31]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17283; Fri, 12 Mar 1999 10:01:33 -0800 (PST) Received: from taxxi.com ([198.161.92.11]) by mail.demo.ru (Netscape Messaging Server 3.6) with ESMTP id 182; Fri, 12 Mar 1999 21:26:24 +0300 Message-ID: <36E957A1.DABB42C3@taxxi.com> Date: Fri, 12 Mar 1999 11:06:25 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.07C-SGI [en] (X11; I; IRIX 6.5 IP22) MIME-Version: 1.0 To: Dan Wing CC: ietf-submit@imc.org, ietf-smtp@imc.org Subject: Re: Submit Server Discovery extension References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Dan Wing wrote: > On Thu, 11 Mar 1999 19:16 -0700, Alexey Melnikov wrote: > > > > On Fri, 5 Mar 1999 00:51 -0700, Alexey Melnikov wrote: > > > > > > > I've missed deadline, so I am posting new draft to mailing lists. > > > > Suggestions are welcome. Also it would be very interested to know > > > > whether this feature will have support. > > > > > > How does one determine the IP address (or hostname) of the first SMTP > > > server (which supports the SUBMIT service extension and tells you the > > > submit server you're supposed to use)? > > > > Client should connect to standard (25) SMTP service port first. If server > > supports Submit extension and is not submit server it will reference > > client to the right location. > > I don't see the value here. Why would a client be configured with the > address of an SMTP server that is something _other_ than its submit > server? There is no reason. But the question is that *how* client may find the location of a submit server. It is good when user knows the exact location of submit server, but what to do if she doesn't? Imagine that in some organization there is both submit and regular SMTP servers. Regular SMTP only relays mail. It refuses to accept mail from local users. Submit server authenticate user and allows her to inject message in mail system. If Submit server is located on non-standard submit port and/or different host, there is no way to find out its location. In such circumstances user will be unable to send her mail, till she knows exact host and port. > If you do decide to go forward with the I-D, though, you certainly need > to add information on what a client is supposed to do if it can't > resolve the information provided in the SUBMIT response (such as > unknown URI or unresolvable DNS hostname). Should the client ignore > the ever-so-gentle request to not use that SMTP server as its submit > server and just go ahead and use it anyway, or ? Ok. I will think about it. You also gave me an idea what to add to Security Consideration section. -- Regards, Alexey Melnikov From owner-ietf-smtp Fri Mar 12 17:24:07 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA20684 for ietf-smtp-bks; Fri, 12 Mar 1999 17:24:07 -0800 (PST) Received: from strange.qualcomm.com (strange.qualcomm.com [129.46.2.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA20680; Fri, 12 Mar 1999 17:24:05 -0800 (PST) Received: from 129.46.158.108 (randy-mac.qualcomm.com [129.46.158.108]) by strange.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA10795; Fri, 12 Mar 1999 17:28:12 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Fri, 12 Mar 1999 17:26:41 -0800 To: Dan Wing , Alexey Melnikov From: Randall Gellens Subject: Re: Submit Server Discovery extension Cc: ietf-submit@imc.org, ietf-smtp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: v1.0b11 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:29 PM -0800 3/11/99, Dan Wing wrote: > I don't see the value here. Why would a client be configured with the > address of an SMTP server that is something _other_ than its submit > server? It's a migration issue. In any organization (company, ISP, etc.) there are likely to be a lot of existing clients configured to submit messages using port 25 on some server. If the intent is to migrate all users to submit via the submission port, having a response from the old SMTP server may help a lot. From owner-ietf-smtp Wed Apr 28 15:25:35 1999 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29757 for ietf-smtp-bks; Wed, 28 Apr 1999 15:25:35 -0700 (PDT) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29752 for ; Wed, 28 Apr 1999 15:25:33 -0700 (PDT) Received: from demo.ru ([194.87.43.88]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id HAA32689 for ; Thu, 29 Apr 1999 07:35:10 -0600 Message-ID: <37278AF5.6EAB2DF8@demo.ru> Date: Thu, 29 Apr 1999 02:25:57 +0400 From: Alexey Melnikov X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: ru,en-US MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: [Fwd: Support for disconnected clients] Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I am forwarding this letter to mailext mailing list. Please, let me know if anybody implemented CHECKPOINT-aware server/client. -------- Original Message -------- Subject: Support for disconnected clients Date: Wed, 21 Apr 1999 08:02:01 +0700 From: Dave Crocker To: imc-mailconnect@imc.org I just got a query from someone in Russia asking about support for Checkpoint in clients. I don't see an indication that this has been tested at a -mailconnect event so I thought it worth asking about. More generally is the usefulness of focusing on the treatment of those connecting over thin wires. Pipelining would be another feature for this. Not sure which others. In general, dial-up access for email is extremely inefficient with current products, and it would be enormously helpful to have products use the wire better. (Access charges from hotels can be impressive; in two days, my dial-up charges from Chiang Mai to Bangkok were US$ 60...) Comments? d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +1 408 246 8253 Brandenburg Consulting Fax: +1 408 273 6464 675 Spruce Drive Sunnyvale, CA 94086 USA From owner-ietf-smtp Tue Jul 27 07:54:00 1999 Received: by mail.proper.com (8.9.3/8.9.3) id HAA26346 for ietf-smtp-bks; Tue, 27 Jul 1999 07:54:00 -0700 (PDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA26342 for ; Tue, 27 Jul 1999 07:53:59 -0700 (PDT) Received: from cbmail.cb.lucent.com (h135-7-68-153.lucent.com [135.7.68.153]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA24124 for ; Tue, 27 Jul 1999 10:56:15 -0400 (EDT) Received: by cbmail.cb.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA03875; Tue, 27 Jul 1999 10:56:14 -0400 (EDT) From: "Mark Horton" Message-Id: <9907271056.ZM3873@cbmail.cb.lucent.com> Date: Tue, 27 Jul 1999 10:56:14 -0400 X-Mailer: Z-Mail (3.2.1 10oct95) To: ietf-smtp@imc.org Subject: compressed content-transfer-encoding? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Is there an RFC (or movement toward one) for a compressed encoding within MIME? There seems to be a lot of interest lately in compressing attachments. End users are encouraged to zip Office files before mailing them, and at least one product (MaxCompression) does this automatically (in a proprietary way.) Even with modem compression, there seems to be some gain from this, and the disk storage implications on the mail server are also interesting. It seems that a new MIME standard for content-transfer-encoding that would indicate a compressed base64 type ala gzip could be nice. Creative minds might even improve the efficiency of base64 at the same time, if we don't have to worry about translation into EBCDIC anymore. Mark From owner-ietf-smtp Tue Jul 27 11:41:59 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29470 for ietf-smtp-bks; Tue, 27 Jul 1999 11:41:59 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29466 for ; Tue, 27 Jul 1999 11:41:58 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id UAA10400 for ; Tue, 27 Jul 1999 20:44:18 +0200 (MET DST) Mime-Version: 1.0 Message-Id: In-Reply-To: <9907271056.ZM3873@cbmail.cb.lucent.com> References: <9907271056.ZM3873@cbmail.cb.lucent.com> Date: Tue, 27 Jul 1999 20:42:35 +0200 To: ietf-smtp@imc.org From: Jacob Palme Subject: Re: compressed content-transfer-encoding? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10.56 -0400 99-07-27, Mark Horton wrote: >Is there an RFC (or movement toward one) for a compressed encoding >within MIME? HTTP has compression headers. We should find out if and how much they are used, and why. HTTP needs compression even more than e-mail, because people are waiting for documents to show up in real time. If compression has not been successful in HTTP, will it be in e-mail where the need is less than in HTTP? --- --- Excerpts from the HTTP/1.1 specification, RFC 2616 --- --- content-coding = token All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding (section 14.11) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding. The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens: gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. compress The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch coding (LZW). Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. deflate The "zlib" format defined in RFC 1950 [31] in combination with the "deflate" compression mechanism described in RFC 1951 [29]. identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header. New content-coding value tokens SHOULD be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new value SHOULD be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Tue Jul 27 11:55:34 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29667 for ietf-smtp-bks; Tue, 27 Jul 1999 11:55:34 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA29660 for ; Tue, 27 Jul 1999 11:55:31 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <54933(4)>; Tue, 27 Jul 1999 11:57:40 PDT Received: from copper.parc.xerox.com ([13.1.102.170]) by thelma.parc.xerox.com with SMTP id <98495>; Tue, 27 Jul 1999 11:57:30 PDT From: "Larry Masinter" To: "Mark Horton" Cc: Subject: RE: compressed content-transfer-encoding? Date: Tue, 27 Jul 1999 11:57:34 PDT Message-ID: <002001bed861$e2f9c680$aa66010d@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <9907271056.ZM3873@cbmail.cb.lucent.com> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Is there an RFC (or movement toward one) for a compressed encoding > within MIME? > > There seems to be a lot of interest lately in compressing attachments. > End users are encouraged to zip Office files before mailing them, > and at least one product (MaxCompression) does this automatically > (in a proprietary way.) Even with modem compression, there seems to > be some gain from this, and the disk storage implications on the mail > server are also interesting. > > It seems that a new MIME standard for content-transfer-encoding that > would indicate a compressed base64 type ala gzip could be nice. > Creative minds might even improve the efficiency of base64 at the > same time, if we don't have to worry about translation into EBCDIC > anymore. HTTP (RFC 2616) added a different transformational layer (Content-Encoding) to avoid combinatorial explosion with different transfer-encodings (transfer-encodings were also kept distinct from content-transfer-encodings). Valid content-coding tokens include "gzip", "compress" and "deflate". It might be possible to extend Content-Encoding to work with mail. And if you want to avoid Base64 in mail, well, there's BINARYMIME (RFC 1830). Larry -- http://www.parc.xerox.com/masinter From owner-ietf-smtp Tue Jul 27 17:36:07 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA05739 for ietf-smtp-bks; Tue, 27 Jul 1999 17:36:07 -0700 (PDT) Received: from smtp1-alterdial.uu.net (smtp1-alterdial.uu.net [192.48.96.19]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA05726 for ; Tue, 27 Jul 1999 17:35:40 -0700 (PDT) Received: from ieca.com by smtp1-alterdial.uu.net with ESMTP (peer crosschecked as: 1Cust16.tnt1.damascus.md.da.uu.net [153.35.150.16]) id QQgzta08889; Wed, 28 Jul 1999 00:35:02 GMT Message-ID: <379DC38C.4F94BA11@ieca.com> Date: Wed, 28 Jul 1999 05:34:53 +0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: Mark Horton , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? References: <002001bed861$e2f9c680$aa66010d@copper.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Congratulations. We've reinvented the OSI Presentation layer. :-| Kidding aside. This requirement (?) has also been discussed in the context of X.400, but it has never motivated anybody enough to make it happen. My feeling is that RFC 2616 took basically the right approach, though. What we are sorely in need of are some standardized IETF middleware applications that do things like compression, digital signature, etc. for any client application. There are a number of good models for this that could be drawn on. However, I don't think that this will happen until a critical mass of people get fed up with solving every problem n times (for n applications). Chris -------------------------------- | International Electronic | | Communication Analysts, Inc. | | Christopher D. Bonatti | | Principal Engineer | | bonattic@ieca.com | | Tel: 301-208-2349 | -------------------------------- ___________________ Larry Masinter wrote: > > Is there an RFC (or movement toward one) for a compressed encoding > > within MIME? > > > > There seems to be a lot of interest lately in compressing attachments. > > End users are encouraged to zip Office files before mailing them, > > and at least one product (MaxCompression) does this automatically > > (in a proprietary way.) Even with modem compression, there seems to > > be some gain from this, and the disk storage implications on the mail > > server are also interesting. > > > > It seems that a new MIME standard for content-transfer-encoding that > > would indicate a compressed base64 type ala gzip could be nice. > > Creative minds might even improve the efficiency of base64 at the > > same time, if we don't have to worry about translation into EBCDIC > > anymore. > > HTTP (RFC 2616) added a different transformational layer > (Content-Encoding) to avoid combinatorial explosion with different > transfer-encodings (transfer-encodings were also kept distinct > from content-transfer-encodings). Valid content-coding tokens > include "gzip", "compress" and "deflate". > > It might be possible to extend Content-Encoding to work with mail. > > And if you want to avoid Base64 in mail, well, there's BINARYMIME > (RFC 1830). > > Larry > -- > http://www.parc.xerox.com/masinter From owner-ietf-smtp Wed Jul 28 12:03:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA16960 for ietf-smtp-bks; Wed, 28 Jul 1999 12:03:39 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA16951 for ; Wed, 28 Jul 1999 12:03:37 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id PAA27357; Wed, 28 Jul 1999 15:03:23 -0400 (EDT) Message-Id: <199907281903.PAA27357@astro.cs.utk.edu> X-Mailer: exmh version 2.0.2 2/24/98 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Horton" cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Tue, 27 Jul 1999 10:56:14 EDT." <9907271056.ZM3873@cbmail.cb.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jul 1999 15:03:23 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > It seems that a new MIME standard for content-transfer-encoding that > would indicate a compressed base64 type ala gzip could be nice. > Creative minds might even improve the efficiency of base64 at the > same time, if we don't have to worry about translation into EBCDIC > anymore. it's been discussed many times; afaik the biggest problem is that nobody has bothered to write up a concrete proposal. the second biggest problem, of course, is that it would break lots of existing software. Keith From owner-ietf-smtp Wed Jul 28 12:26:41 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA18200 for ietf-smtp-bks; Wed, 28 Jul 1999 12:26:41 -0700 (PDT) Received: from pimail.ima.com (root@pimail.ima.com [202.75.2.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18196 for ; Wed, 28 Jul 1999 12:26:35 -0700 (PDT) Received: from panay by pimail.ima.com (8.8.7/1.14.5) with SMTP id TAA13526; Wed, 28 Jul 1999 19:13:02 GMT Message-ID: <04d601bed92f$2745aac0$6e024bca@panay.ima.com> From: "Tim Kehres" To: "Keith Moore" , "Mark Horton" Cc: Subject: Re: compressed content-transfer-encoding? Date: Thu, 29 Jul 1999 03:26:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >> It seems that a new MIME standard for content-transfer-encoding that >> would indicate a compressed base64 type ala gzip could be nice. >> Creative minds might even improve the efficiency of base64 at the >> same time, if we don't have to worry about translation into EBCDIC >> anymore. > >it's been discussed many times; afaik the biggest problem is that nobody >has bothered to write up a concrete proposal. the second biggest problem, >of course, is that it would break lots of existing software. Just curious - has the idea of doing on the fly compression at the ESMTP level ever been considered? This would have the advantage of not breaking any of the upper layers, and would only be enabled between MTA's with the capability. It would be tough on the MTA's, but with CPU and disk speeds increasing, it might be feasible. Anyway, just a thought... Best Regards, Tim Kehres International Messaging Associates http://www.ima.com From owner-ietf-smtp Wed Jul 28 12:33:55 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA18437 for ietf-smtp-bks; Wed, 28 Jul 1999 12:33:55 -0700 (PDT) Received: from smtp1-alterdial.uu.net (smtp1-alterdial.uu.net [192.48.96.19]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18432 for ; Wed, 28 Jul 1999 12:33:51 -0700 (PDT) Received: from ieca.com by smtp1-alterdial.uu.net with ESMTP (peer crosschecked as: 1Cust68.tnt1.damascus.md.da.uu.net [153.35.150.68]) id QQgzvy02705; Wed, 28 Jul 1999 19:35:59 GMT Message-ID: <379ECEF9.59C54138@ieca.com> Date: Thu, 29 Jul 1999 00:35:53 +0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Mark Horton , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? References: <199907281903.PAA27357@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Keith, Actually, I suspect that you have it backwards because there is a dependency involved. I think that a lot of folks would be willing to write such a proposal (myself included) except for the second problem. ;-) We are victims of our own success. We can't afford to think of better approaches because we can't afford to have a big departure for Web:TNG or SMTP:TNG. Chris __________________ Keith Moore wrote: > > It seems that a new MIME standard for content-transfer-encoding that > > would indicate a compressed base64 type ala gzip could be nice. > > Creative minds might even improve the efficiency of base64 at the > > same time, if we don't have to worry about translation into EBCDIC > > anymore. > > it's been discussed many times; afaik the biggest problem is that nobody > has bothered to write up a concrete proposal. the second biggest problem, > of course, is that it would break lots of existing software. > > Keith From owner-ietf-smtp Wed Jul 28 12:35:02 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA18613 for ietf-smtp-bks; Wed, 28 Jul 1999 12:35:02 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18605 for ; Wed, 28 Jul 1999 12:35:01 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id PAA27597; Wed, 28 Jul 1999 15:35:23 -0400 (EDT) Message-Id: <199907281935.PAA27597@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tim Kehres" cc: "Keith Moore" , "Mark Horton" , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Thu, 29 Jul 1999 03:26:55 +0800." <04d601bed92f$2745aac0$6e024bca@panay.ima.com> Date: Wed, 28 Jul 1999 15:35:23 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Just curious - has the idea of doing on the fly compression at the ESMTP > level ever been considered? aarrgh. SMTP is already complex enough. the last thing I want to see is more complex MTAs adding more failure cases. From owner-ietf-smtp Wed Jul 28 12:48:11 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA18965 for ietf-smtp-bks; Wed, 28 Jul 1999 12:48:11 -0700 (PDT) Received: from pimail.ima.com (root@pimail.ima.com [202.75.2.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA18961 for ; Wed, 28 Jul 1999 12:48:06 -0700 (PDT) Received: from panay by pimail.ima.com (8.8.7/1.14.5) with SMTP id TAA13637; Wed, 28 Jul 1999 19:35:16 GMT Message-ID: <053001bed932$42c2d6d0$6e024bca@panay.ima.com> From: "Tim Kehres" To: "Keith Moore" Cc: "Mark Horton" , Subject: Re: compressed content-transfer-encoding? Date: Thu, 29 Jul 1999 03:49:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >> Just curious - has the idea of doing on the fly compression at the ESMTP >> level ever been considered? > >aarrgh. SMTP is already complex enough. the last thing I want to see >is more complex MTAs adding more failure cases. I was thinking in terms of an ESMTP extension. In any event, by your own admission, doing it as a MIME type would break a lot of software at the end points. At least this way it is only attempted between mutually consenting MTA's and is transparent to the end users. Best Regards, Tim Kehres International Messaging Associates http://www.ima.com From owner-ietf-smtp Wed Jul 28 12:48:50 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA19006 for ietf-smtp-bks; Wed, 28 Jul 1999 12:48:50 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA19001 for ; Wed, 28 Jul 1999 12:48:48 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE3IK7693K99DN0V@INNOSOFT.COM> for ietf-smtp@imc.org; Wed, 28 Jul 1999 12:50:11 PDT Date: Wed, 28 Jul 1999 12:49:10 -0700 (PDT) From: Ned Freed Subject: Re: compressed content-transfer-encoding? In-reply-to: "Your message dated Wed, 28 Jul 1999 15:03:23 -0400" <199907281903.PAA27357@astro.cs.utk.edu> To: Keith Moore Cc: Mark Horton , ietf-smtp@imc.org Message-id: <01JE3K1P9MDY99DN0V@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <9907271056.ZM3873@cbmail.cb.lucent.com> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > It seems that a new MIME standard for content-transfer-encoding that > > would indicate a compressed base64 type ala gzip could be nice. > > Creative minds might even improve the efficiency of base64 at the > > same time, if we don't have to worry about translation into EBCDIC > > anymore. > it's been discussed many times; afaik the biggest problem is that nobody > has bothered to write up a concrete proposal. the second biggest problem, > of course, is that it would break lots of existing software. I actually have it written up, but have never bothered to release the specification because of the deployment problem. We need a deployment mechanism first. And that's precisely what we're trying to get through RESCAP. Ned From owner-ietf-smtp Wed Jul 28 12:52:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA19145 for ietf-smtp-bks; Wed, 28 Jul 1999 12:52:39 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA19141 for ; Wed, 28 Jul 1999 12:52:38 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d6SJsw028474; Wed, 28 Jul 1999 15:54:58 -0400 Message-Id: <199907281954.d6SJsw028474@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: Keith Moore Cc: "Mark Horton" , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-Reply-To: Your message of "Wed, 28 Jul 1999 15:03:23 EDT." <199907281903.PAA27357@astro.cs.utk.edu> 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 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-448553088P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 1999 15:54:57 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --==_Exmh_-448553088P Content-Type: text/plain; charset=us-ascii On Wed, 28 Jul 1999 15:03:23 EDT, Keith Moore said: > it's been discussed many times; afaik the biggest problem is that nobody > has bothered to write up a concrete proposal. the second biggest problem, > of course, is that it would break lots of existing software. That, and the fact that currently, the average text/plain being sent around is relatively small (2-3K or so) and won't be a BIG win (you can't save mor than 3 K, and that's only 2 packets on an ethernet ;) The things that chew up the bandwidth are things like .GIF, .JPG, etc attachements, which usually tend to have some compression already done on them. Now, if you have some big spreadsheets from some big company that specializes in bloatware, perhaps the right thing to do is convince them to make it take less disk space. Yes, disk is cheap, but that hardly justifies intentional waste.... Has anybody done any studies at all on whether said compression would actually *win* us enough to be worth it? As a data point, my MH folders live on a compressed file system (each 4K block is LZ-compressed individually), and takes about 110M compressed and 198M uncompressed. *HOWEVER*, a *very* large chunk of that is Received: headers and the like, which would NOT be compressible... If I get ambitious tonight, I'll see what the compression of the bodyparts ends up being.. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-448553088P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN59gD9QBOOoptg9JAQE2rwQAosxbtyP4x5132Cpl2/5iEAAmdYOzF63c uFOoDU7oEwgUR+ZLZ53YVypSvzLmWCbIVRznoHMTs+PabRHD3TsXzo4gah8aNnJW KuMcX2Of5EGot+/qPY7lJ+dqwokytP3sfSF05eM3BES4/VSGH6ftj++E/iGgTs5v Zfvim9J7aoE= =qBbJ -----END PGP MESSAGE----- --==_Exmh_-448553088P-- From owner-ietf-smtp Wed Jul 28 12:57:48 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA19335 for ietf-smtp-bks; Wed, 28 Jul 1999 12:57:48 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA19331 for ; Wed, 28 Jul 1999 12:57:46 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id PAA27782; Wed, 28 Jul 1999 15:58:11 -0400 (EDT) Message-Id: <199907281958.PAA27782@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tim Kehres" cc: "Keith Moore" , "Mark Horton" , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Thu, 29 Jul 1999 03:49:10 +0800." <053001bed932$42c2d6d0$6e024bca@panay.ima.com> Date: Wed, 28 Jul 1999 15:58:10 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > >aarrgh. SMTP is already complex enough. the last thing I want to see > >is more complex MTAs adding more failure cases. > > > I was thinking in terms of an ESMTP extension. In any event, by your own > admission, doing it as a MIME type would break a lot of software at the end > points. At least this way it is only attempted between mutually consenting > MTA's and is transparent to the end users. an MTA that transparently corrupts your mail isn't necessarily a good thing. note also that compression algorithms tend to be specific to particular kinds of content - what works well with text or object code typically doesn't work well with images, audio, or video. Keith From owner-ietf-smtp Wed Jul 28 12:52:10 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA19117 for ietf-smtp-bks; Wed, 28 Jul 1999 12:52:10 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA19113 for ; Wed, 28 Jul 1999 12:52:09 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE3IK7693K99DN0V@INNOSOFT.COM> for ietf-smtp@imc.org; Wed, 28 Jul 1999 12:54:01 PDT Date: Wed, 28 Jul 1999 12:52:33 -0700 (PDT) From: Ned Freed Subject: Re: compressed content-transfer-encoding? In-reply-to: "Your message dated Thu, 29 Jul 1999 03:26:55 +0800" <04d601bed92f$2745aac0$6e024bca@panay.ima.com> To: Tim Kehres Cc: Keith Moore , Mark Horton , ietf-smtp@imc.org Message-id: <01JE3K6GF59899DN0V@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > > It seems that a new MIME standard for content-transfer-encoding that > > > would indicate a compressed base64 type ala gzip could be nice. > > > Creative minds might even improve the efficiency of base64 at the > > > same time, if we don't have to worry about translation into EBCDIC > > > anymore. > > it's been discussed many times; afaik the biggest problem is that nobody > > has bothered to write up a concrete proposal. the second biggest problem, > > of course, is that it would break lots of existing software. > Just curious - has the idea of doing on the fly compression at the ESMTP > level ever been considered? Yes, but given the existance of the TLS SMTP extension, which can negotiate compression, why bother defining another mechanism? > This would have the advantage of not breaking > any of the upper layers, and would only be enabled between MTA's with the > capability. It would be tough on the MTA's, but with CPU and disk speeds > increasing, it might be feasible. Anyway, just a thought... Compression is a nonissue compared to crypto. But in general we need crypto a lot more than we need to save bandwidth... Ned From owner-ietf-smtp Wed Jul 28 13:08:29 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA19933 for ietf-smtp-bks; Wed, 28 Jul 1999 13:08:29 -0700 (PDT) Received: from pimail.ima.com (root@pimail.ima.com [202.75.2.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA19902 for ; Wed, 28 Jul 1999 13:08:23 -0700 (PDT) Received: from panay by pimail.ima.com (8.8.7/1.14.5) with SMTP id TAA13731; Wed, 28 Jul 1999 19:55:38 GMT Message-ID: <058201bed935$1b0cf280$6e024bca@panay.ima.com> From: "Tim Kehres" To: "Keith Moore" Cc: "Mark Horton" , Subject: Re: compressed content-transfer-encoding? Date: Thu, 29 Jul 1999 04:09:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >> >aarrgh. SMTP is already complex enough. the last thing I want to see >> >is more complex MTAs adding more failure cases. >> >> >> I was thinking in terms of an ESMTP extension. In any event, by your own >> admission, doing it as a MIME type would break a lot of software at the end >> points. At least this way it is only attempted between mutually consenting >> MTA's and is transparent to the end users. > >an MTA that transparently corrupts your mail isn't necessarily a good thing. Yes, of course. I was not advocating the populating of the world with broken software. :-) :-) I've not had a chance to review the RFC that Ned made reference to (TLS STMP Extension), but on the surface it sounds like the capabilities that I was suggesting anyway. Thanks and Best Regards, Tim Kehres International Messaging Associates http://www.ima.com From owner-ietf-smtp Wed Jul 28 13:08:29 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA19932 for ietf-smtp-bks; Wed, 28 Jul 1999 13:08:29 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA19918 for ; Wed, 28 Jul 1999 13:08:27 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE3IK7693K99DN0V@INNOSOFT.COM> for ietf-smtp@imc.org; Wed, 28 Jul 1999 13:09:53 PDT Date: Wed, 28 Jul 1999 13:05:40 -0700 (PDT) From: Ned Freed Subject: Re: compressed content-transfer-encoding? In-reply-to: "Your message dated Wed, 28 Jul 1999 15:58:10 -0400" <199907281958.PAA27782@astro.cs.utk.edu> To: Keith Moore Cc: Tim Kehres , Keith Moore , Mark Horton , ietf-smtp@imc.org Message-id: <01JE3KQ4V4SM99DN0V@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <053001bed932$42c2d6d0$6e024bca@panay.ima.com> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > >aarrgh. SMTP is already complex enough. the last thing I want to see > > >is more complex MTAs adding more failure cases. > > > > > > I was thinking in terms of an ESMTP extension. In any event, by your own > > admission, doing it as a MIME type would break a lot of software at the end > > points. At least this way it is only attempted between mutually consenting > > MTA's and is transparent to the end users. > an MTA that transparently corrupts your mail isn't necessarily a good thing. > note also that compression algorithms tend to be specific to particular > kinds of content - what works well with text or object code typically > doesn't work well with images, audio, or video. I prefer to characterize it this way: There are type-specific compressions, which tend to be built into the media types they are appropriate for and which also may not yield the same output as input, and type-independent compressions, which tend to be applied on top of rather than inside of media types and which always yield the same output as input. We're only talking about the latter sort of compression here. Use of the former is a solved problem, and hence a red herring in this context. Ned From owner-ietf-smtp Wed Jul 28 13:11:10 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id NAA20056 for ietf-smtp-bks; Wed, 28 Jul 1999 13:11:10 -0700 (PDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA20052 for ; Wed, 28 Jul 1999 13:11:04 -0700 (PDT) Received: from cbmail.cb.lucent.com (h135-7-68-153.lucent.com [135.7.68.153]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA14780 for ; Wed, 28 Jul 1999 16:13:32 -0400 (EDT) Received: from lucent.com by cbmail.cb.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA11360; Wed, 28 Jul 1999 16:13:30 -0400 (EDT) Message-ID: <379F6468.76175A8B@lucent.com> Date: Wed, 28 Jul 1999 16:13:28 -0400 From: M Horton Organization: Lucent Technologies X-Mailer: Mozilla 4.6C-CCK-MCD EMS-1.4 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? References: <04d601bed92f$2745aac0$6e024bca@panay.ima.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Just curious - has the idea of doing on the fly compression at the ESMTP > level ever been considered? I think there are two major problems this proposal tries to solve: (1) Big attachments take forever to download over a slow link with POP or IMAP, or to submit with SMTP. (2) Big attachments take up a lot of disk space on the mail server or in mail folders where you save them. Enhancing SMTP doesn't solve either problem. > We need a deployment mechanism first. And that's precisely what we're > trying to get through RESCAP. Not being familiar with RESCAP, do you have a URL for it? Some ideas for deployment: (1) Provide a free tool that will convert the compressed format to the uncompressed format, open source and also compiled for the various platforms. (2) Put up some mail relays on the net. You forward your message to a mail relay - it returns it to you with uncompressed attachments. (3) Have a phased deployment of clients. We choose a date, say, 2 years off, by when we expect most clients will be upgraded. Each client has a switch setting for whether to compress binary attachments, with 3 settings: Always compress Never compress Compress if the send date is after The default setting could be the third one. In addition, the Compose window should let you override the default setting for a specific message. > That, and the fact that currently, the average text/plain being sent > around is relatively small (2-3K or so) and won't be a BIG win (you can't > save mor than 3 K, and that's only 2 packets on an ethernet ;) > > The things that chew up the bandwidth are things like .GIF, .JPG, > etc attachements, which usually tend to have some compression already > done on them. Now, if you have some big spreadsheets from some big > company that specializes in bloatware, perhaps the right thing to do > is convince them to make it take less disk space. Yes, disk is cheap, > but that hardly justifies intentional waste.... I would think one would want a setting in the client saying "only compress attachments if they are larger than ___ KB." My experience is that MS Office files are the usual large attachments that cause problems. While I am hopeful that Microsoft will eventually have a reasonably small default Office format, their web page says Office 2000 files are the same format as Office 97, and that their HTML versions are actually larger than the proprietary format. > Has anybody done any studies at all on whether said compression would > actually *win* us enough to be worth it? As a data point, my MH folders > live on a compressed file system (each 4K block is LZ-compressed > individually), > and takes about 110M compressed and 198M uncompressed. *HOWEVER*, a *very* > large chunk of that is Received: headers and the like, which would NOT > be compressible... I tried compressing (with winzip, which seems to be universally available on PCs) a lot of large Office files I have around. The results were spectacular - 90% compression was common. I really had to hunt to find files that compressed to the expected 50%. I would guess that GZip would do even better. Mark From owner-ietf-smtp Wed Jul 28 13:20:38 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA20485 for ietf-smtp-bks; Wed, 28 Jul 1999 13:20:38 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA20480 for ; Wed, 28 Jul 1999 13:20:37 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id QAA27943; Wed, 28 Jul 1999 16:21:04 -0400 (EDT) Message-Id: <199907282021.QAA27943@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ned Freed cc: Keith Moore , Tim Kehres , Mark Horton , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Wed, 28 Jul 1999 13:05:40 PDT." <01JE3KQ4V4SM99DN0V@INNOSOFT.COM> Date: Wed, 28 Jul 1999 16:21:04 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: my point is that even the "type-independent compressions" (LZW, deflate, etc) are at best ineffective (and at worse pessimal) when applied to different kinds of media types for which they were designed. you therefore don't want to gratuitously apply them to random content-types. Keith From owner-ietf-smtp Wed Jul 28 13:23:46 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA20709 for ietf-smtp-bks; Wed, 28 Jul 1999 13:23:46 -0700 (PDT) Received: from pimail.ima.com (root@pimail.ima.com [202.75.2.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA20700 for ; Wed, 28 Jul 1999 13:23:38 -0700 (PDT) Received: from panay by pimail.ima.com (8.8.7/1.14.5) with SMTP id UAA13797; Wed, 28 Jul 1999 20:10:31 GMT Message-ID: <05a601bed937$2f124df0$6e024bca@panay.ima.com> From: "Tim Kehres" To: "Keith Moore" , Cc: "Mark Horton" , Subject: Re: compressed content-transfer-encoding? Date: Thu, 29 Jul 1999 04:24:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >On Wed, 28 Jul 1999 15:03:23 EDT, Keith Moore said: >> it's been discussed many times; afaik the biggest problem is that nobody >> has bothered to write up a concrete proposal. the second biggest problem, >> of course, is that it would break lots of existing software. > >That, and the fact that currently, the average text/plain being sent >around is relatively small (2-3K or so) and won't be a BIG win (you can't >save mor than 3 K, and that's only 2 packets on an ethernet ;) > >The things that chew up the bandwidth are things like .GIF, .JPG, >etc attachements, which usually tend to have some compression already >done on them. Now, if you have some big spreadsheets from some big >company that specializes in bloatware, perhaps the right thing to do >is convince them to make it take less disk space. Yes, disk is cheap, >but that hardly justifies intentional waste.... > >Has anybody done any studies at all on whether said compression would >actually *win* us enough to be worth it? As a data point, my MH folders >live on a compressed file system (each 4K block is LZ-compressed individually), >and takes about 110M compressed and 198M uncompressed. *HOWEVER*, a *very* >large chunk of that is Received: headers and the like, which would NOT >be compressible... As you say, it is highly dependent upon the attachment type. File types that are already in a compressed state like JPEG's as you reference above won't buy you anything. On the other hand, at least in our environment, we tend to send around a lot of documentation, in the form of Microsoft Word, Adobe FrameMaker, or PDF formats, which compress rather nicely. Images in TIFF format are also highly compressible. I would suspect that as the usage of HTML in email increases, you might get some benefit here as well, but of course only for the larger sized messages. Due to the dependency on the attachment types, I suspect that what might be a significant win for one environment would make no difference in another. In reference to your comment above about the bloatware and convincing people to use less space, I'm not sure what you have in mind here. I'm not aware of any simple way to have for instance your Excel, Word, or Frame files automagically compressed. Above you also mention the online storage of the messages. What is the intent here? Are we trying to save in disk space or bandwidth utilization when the attachment is in transit. I was assuming the later. Saving a couple hundred meg of disk space with the price of drives these days hardly seems worth the effort. Best Regards, Tim Kehres International Messaging Associates http://www.ima.com From owner-ietf-smtp Wed Jul 28 13:24:27 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA20752 for ietf-smtp-bks; Wed, 28 Jul 1999 13:24:27 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA20747 for ; Wed, 28 Jul 1999 13:24:26 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MS-2.2) with ESMTP id QAA15864 for ; Wed, 28 Jul 1999 16:26:18 -0400 (EDT) Received: from att.com ([135.197.90.252](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990728202419un100993dqe>; Wed, 28 Jul 1999 20:24:19 +0000 Message-ID: <379F6710.27D151C8@att.com> Date: Wed, 28 Jul 1999 16:24:48 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tim Kehres CC: Keith Moore , Mark Horton , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? References: <04d601bed92f$2745aac0$6e024bca@panay.ima.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tim Kehres wrote: > > >> It seems that a new MIME standard for content-transfer-encoding that > >> would indicate a compressed base64 type ala gzip could be nice. > >> Creative minds might even improve the efficiency of base64 at the > >> same time, if we don't have to worry about translation into EBCDIC > >> anymore. > > > >it's been discussed many times; afaik the biggest problem is that nobody > >has bothered to write up a concrete proposal. the second biggest problem, > >of course, is that it would break lots of existing software. > > Just curious - has the idea of doing on the fly compression at the ESMTP > level ever been considered? This would have the advantage of not breaking > any of the upper layers, and would only be enabled between MTA's with the > capability. It would be tough on the MTA's, but with CPU and disk speeds > increasing, it might be feasible. Anyway, just a thought... I've heard proposals to possibly do this through a SASL layer. Tony Hansen tony@att.com From owner-ietf-smtp Wed Jul 28 14:27:04 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA23514 for ietf-smtp-bks; Wed, 28 Jul 1999 14:27:04 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA23507 for ; Wed, 28 Jul 1999 14:27:03 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE3IK7693K99DN0V@INNOSOFT.COM> for ietf-smtp@imc.org; Wed, 28 Jul 1999 14:28:28 PDT Date: Wed, 28 Jul 1999 14:23:56 -0700 (PDT) From: Ned Freed Subject: Re: compressed content-transfer-encoding? In-reply-to: "Your message dated Wed, 28 Jul 1999 16:21:04 -0400" <199907282021.QAA27943@astro.cs.utk.edu> To: Keith Moore Cc: Ned Freed , Keith Moore , Tim Kehres , Mark Horton , ietf-smtp@imc.org Message-id: <01JE3NGKYSZ099DN0V@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <01JE3KQ4V4SM99DN0V@INNOSOFT.COM> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > my point is that even the "type-independent compressions" (LZW, > deflate, etc) are at best ineffective (and at worse pessimal) > when applied to different kinds of media types for which they > were designed. you therefore don't want to gratuitously apply > them to random content-types. Actually this isn't true -- for one thing, there's still an advantage to be had by compressing base64 at the transport level. And for another, the type-independent conversions sometimes do manage to squeeze a little more juice out out that the type-specific conversions didn't manage. And when that's not possible, they are smart enough to tell this is the case and opt out; the result is a little CPU lost on the sending side (very cheap), effectively no bloat, and no significant CPU loss on the receiver. The quality of these things really has gone up over the years, so with the proper use of modern options pessimal outcomes are eliminated. Ned From owner-ietf-smtp Wed Jul 28 14:48:17 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA24139 for ietf-smtp-bks; Wed, 28 Jul 1999 14:48:17 -0700 (PDT) Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA24135 for ; Wed, 28 Jul 1999 14:48:16 -0700 (PDT) Received: from unix10.andrew.cmu.edu (UNIX10.ANDREW.CMU.EDU [128.2.15.14]) by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id RAA18446; Wed, 28 Jul 1999 17:50:39 -0400 (EDT) Date: 28 Jul 1999 17:50:32 -0400 Message-ID: From: Timothy L Martin X-Mailer: BatIMail version 3.2 To: Tim Kehres CC: ietf-smtp@imc.org In-reply-to: <379F6710.27D151C8@att.com> Subject: Re: compressed content-transfer-encoding? References: <04d601bed92f$2745aac0$6e024bca@panay.ima.com> <379F6710.27D151C8@att.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > capability. It would be tough on the MTA's, but with CPU and disk speeds > > increasing, it might be feasible. Anyway, just a thought... > > I've heard proposals to possibly do this through a SASL layer. The main issue with this is that current protocols that support SASL only allow for one SASL layer at a time so you could get either compression or kerberos, not both. I still think this could be useful in certain circumstances and would be willing to implement it if anyone were to write a SASL compression draft. From owner-ietf-smtp Wed Jul 28 17:46:19 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA27395 for ietf-smtp-bks; Wed, 28 Jul 1999 17:46:19 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA27389 for ; Wed, 28 Jul 1999 17:46:17 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id UAA29227; Wed, 28 Jul 1999 20:46:43 -0400 (EDT) Message-Id: <199907290046.UAA29227@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ned Freed cc: Keith Moore , Tim Kehres , Mark Horton , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Wed, 28 Jul 1999 14:23:56 PDT." <01JE3NGKYSZ099DN0V@INNOSOFT.COM> Date: Wed, 28 Jul 1999 20:46:43 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > my point is that even the "type-independent compressions" (LZW, > > deflate, etc) are at best ineffective (and at worse pessimal) > > when applied to different kinds of media types for which they > > were designed. you therefore don't want to gratuitously apply > > them to random content-types. > > Actually this isn't true -- for one thing, there's still an advantage to > be had by compressing base64 at the transport level. right, but I was talking about MIME compression. if we compress at the transport level, we might as well just use ssl. > And for another, the > type-independent conversions sometimes do manage to squeeze a little > more juice out out that the type-specific conversions didn't manage. yes, though it's often prety marginal - my guess is that it's not worth the cost of incompatibility. (again, talking about MIME compression) > And when that's not > possible, they are smart enough to tell this is the case and opt out; the > result is a little CPU lost on the sending side (very cheap), effectively no > bloat, and no significant CPU loss on the receiver. basically true, for newer algorithms. Keith From owner-ietf-smtp Thu Jul 29 02:34:55 1999 Received: by mail.proper.com (8.9.3/8.9.3) id CAA07799 for ietf-smtp-bks; Thu, 29 Jul 1999 02:34:55 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA07794 for ; Thu, 29 Jul 1999 02:34:53 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id LAA12213 for ; Thu, 29 Jul 1999 11:37:21 +0200 (MET DST) Mime-Version: 1.0 Message-Id: In-Reply-To: <002001bed861$e2f9c680$aa66010d@copper.parc.xerox.com> References: <002001bed861$e2f9c680$aa66010d@copper.parc.xerox.com> Date: Thu, 29 Jul 1999 11:22:45 +0200 To: ietf-smtp@imc.org From: Jacob Palme Subject: RE: compressed content-transfer-encoding? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 11.57 -0700 99-07-27, Larry Masinter wrote: >HTTP (RFC 2616) added a different transformational layer >(Content-Encoding) to avoid combinatorial explosion with different >transfer-encodings (transfer-encodings were also kept distinct >from content-transfer-encodings). Valid content-coding tokens >include "gzip", "compress" and "deflate". After thinking more about this, I have come to the conclusion that compression should be automatic and supported by the standards. The reason for this is that this will make things easier for the users. The users need not ever see that information is compressed during transmission. The issue is whether compression should be done in the application layer, with special compression headers, etc., or in lower layers. For example, and e-mail message is usually forwarded through at least two store-and-forward MTAs: Original -> Local MTA -> Local MTA -> Final sender for sender for recipient recipient With compression in the application layer, an attachment will be compressed by the original sender, and not uncompressed again until by the final recipient. With compression in the transport layer, the attachment will be compressed and uncompressed for each store-and-forward step. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Thu Jul 29 05:04:03 1999 Received: by mail.proper.com (8.9.3/8.9.3) id FAA12886 for ietf-smtp-bks; Thu, 29 Jul 1999 05:04:03 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA12882 for ; Thu, 29 Jul 1999 05:04:01 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id OAA18091 for ; Thu, 29 Jul 1999 14:06:32 +0200 (MET DST) Mime-Version: 1.0 Message-Id: In-Reply-To: <199907281958.PAA27782@astro.cs.utk.edu> References: <199907281958.PAA27782@astro.cs.utk.edu> Date: Thu, 29 Jul 1999 14:07:41 +0200 To: ietf-smtp@imc.org From: Jacob Palme Subject: Re: compressed content-transfer-encoding? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: We already have a standard for sending compressed data in e-mail. We have an IANA registered content-type application/zip. What more is needed? That mailers start using it? Is there a need for an attribute to "Content-Type:application/zip" with the name "Uncompressed-Content-Type"?. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Thu Jul 29 07:28:06 1999 Received: by mail.proper.com (8.9.3/8.9.3) id HAA15609 for ietf-smtp-bks; Thu, 29 Jul 1999 07:28:06 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA15604 for ; Thu, 29 Jul 1999 07:28:05 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id KAA19344; Thu, 29 Jul 1999 10:28:37 -0400 (EDT) Message-Id: <199907291428.KAA19344@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jacob Palme cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Thu, 29 Jul 1999 14:07:41 +0200." Date: Thu, 29 Jul 1999 10:28:37 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > We already have a standard for sending compressed data in e-mail. > We have an IANA registered content-type application/zip. application/zip is not a standard. From owner-ietf-smtp Thu Jul 29 08:14:20 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA16737 for ietf-smtp-bks; Thu, 29 Jul 1999 08:14:20 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA16733 for ; Thu, 29 Jul 1999 08:14:19 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d6TFGf003148; Thu, 29 Jul 1999 11:16:41 -0400 Message-Id: <199907291516.d6TFGf003148@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: "Tim Kehres" Cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-Reply-To: Your message of "Thu, 29 Jul 1999 04:24:24 +0800." <05a601bed937$2f124df0$6e024bca@panay.ima.com> 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 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1091491590P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 29 Jul 1999 11:16:38 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --==_Exmh_1091491590P Content-Type: text/plain; charset=us-ascii On Thu, 29 Jul 1999 04:24:24 +0800, "Tim Kehres" said: > Above you also mention the online storage of the messages. What is the > intent here? Are we trying to save in disk space or bandwidth utilization > when the attachment is in transit. I was assuming the later. Saving a > couple hundred meg of disk space with the price of drives these days hardly > seems worth the effort. I mentioned online storage only because I had statistics on the compression. What an MUA does in its message store is of course its own business. ;) I'm also distressed at this cavalier "with the cost of..." trend of late. Some places run on tight budgets or have other constraints. I turned on disk compression on my worstation, and got back about 30% of the /home space. This saved me from having to buy a new disk drive. So right there, we've saved $200 just on the cost of the drive. But there's more. Remember to factor in the cost of my downtime while I back up my machine, take it down, do all the needed recabling, replace the drive, boot it up, and restore all the data from tape. Add the cost of most of a day's work for me. Add in the cost of *tomorrow* being shot because I didn't get stuff done today, so tomorrow I'm digging out from under today's backlog. Suddenly, worrying about efficient use of disk space starts looking a lot better - and makes a CPU and/or memory upgrades a lot cheaper in comparison. And I've *got* disk compression software. I don't have CPU compression software. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1091491590P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN6BwVdQBOOoptg9JAQFsYwP/TfmYVy+Et5TIU6CJM5v8YO71H+pO0jfO OILYtlOov+YjzM4KlmSsWtyvBgIAvE2v/2T81DF2a+li8kZnphMFfK5U8Rhid92Y GEn+A3tATJjAuFmuVFQRbPcpXTEt0+PQwAFBD23i8hyjcQW3Reo8RuOMk9OLJ4Xo oMa/q4YnmLw= =6Fzv -----END PGP MESSAGE----- --==_Exmh_1091491590P-- From owner-ietf-smtp Thu Jul 29 08:20:30 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA16873 for ietf-smtp-bks; Thu, 29 Jul 1999 08:20:30 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA16869 for ; Thu, 29 Jul 1999 08:20:29 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d6TFMu016114; Thu, 29 Jul 1999 11:22:56 -0400 Message-Id: <199907291522.d6TFMu016114@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: Keith Moore Cc: Jacob Palme , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-Reply-To: Your message of "Thu, 29 Jul 1999 10:28:37 EDT." <199907291428.KAA19344@astro.cs.utk.edu> 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 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1100814738P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 29 Jul 1999 11:22:56 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --==_Exmh_1100814738P Content-Type: text/plain; charset=us-ascii On Thu, 29 Jul 1999 10:28:37 EDT, Keith Moore said: > > We already have a standard for sending compressed data in e-mail. > > We have an IANA registered content-type application/zip. > > application/zip is not a standard. Not only is it not a standard, but it loses in the translation. Let's say I start with a Microsoft Word application. Currently, I can attach that as an application/msword, and at the remote end, the MUA will be able to intuit proper handling of the *actual file* from that. An application/zip loses that. It basically renders any object as unidentifiable as an application/octet-stream. There's also a security issue, in that I can be confident that a MIME bodypart that is an application/msword is *one* file, the name of which I can either predict and check, or control. It's a lot harder to make *real* sure that you're not unzipping things you didn't want to. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1100814738P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN6BxztQBOOoptg9JAQEz9wP7BjSGAgR57KOdCZrH9PdCaHfqh0QgCSpb F+fM43nabhjMVISvKW/RI4CfgA32FYaKIJbVwwW5vMhrEFmtllXCmb8rlT/U/51O PuQdfDoK6mOLfLYzg3JLGmnLF5wutCoN0GOtqDPiuI4dqOFGB+1+0ahzYlcfyjbl LLBlyEg5+ZE= =pMPY -----END PGP MESSAGE----- --==_Exmh_1100814738P-- From owner-ietf-smtp Thu Jul 29 08:15:36 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA16775 for ietf-smtp-bks; Thu, 29 Jul 1999 08:15:36 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA16771 for ; Thu, 29 Jul 1999 08:15:35 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.10.0.PreAlpha3/8.10.0.PreAlpha3) with ESMTP id d6TFI6027860; Thu, 29 Jul 1999 11:18:06 -0400 Message-Id: <199907291518.d6TFI6027860@black-ice.cc.vt.edu> X-Mailer: exmh version 2.1.0 04/14/1999 To: M Horton Cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-Reply-To: Your message of "Wed, 28 Jul 1999 16:13:28 EDT." <379F6468.76175A8B@lucent.com> 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[ <379F6468.76175A8B@lucent.com> Mime-Version: 1.0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1094026038P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 29 Jul 1999 11:18:05 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: --==_Exmh_1094026038P Content-Type: text/plain; charset=us-ascii On Wed, 28 Jul 1999 16:13:28 EDT, M Horton said: > (3) Have a phased deployment of clients. We choose a date, say, 2 > years off, by when we expect most clients will be upgraded. Each > client has a switch setting for whether to compress binary attachments, > with 3 settings: > Always compress > Never compress > Compress if the send date is after > The default setting could be the third one. Gaak. *NO*. I found a Sendmail 5.65 on our campus this month. Think about that. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_1094026038P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBN6BwrNQBOOoptg9JAQGYywQAnFXjGGQh/Q9vaFl3s9ydhRIbqM9R7PMF CnYlcA7tv6R5uoCYIyPPE440D5Lsk/pcQUY5Rz/Izn456HXxvoXMxW8pB2+Ifj9w /uU3oxIvZr55cYIjK/mWwmkICMRvn42g1zU0VgvlRm4P4W9zZIo+u4P6VLrX2FzN NlzU16PzhDs= =y5jy -----END PGP MESSAGE----- --==_Exmh_1094026038P-- From owner-ietf-smtp Thu Jul 29 09:27:11 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA17698 for ietf-smtp-bks; Thu, 29 Jul 1999 09:27:11 -0700 (PDT) Received: from mail1-im.etl.go.jp (mail1-wide.etl.go.jp [192.31.197.9]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA17694 for ; Thu, 29 Jul 1999 09:27:05 -0700 (PDT) Received: from eccu1-1.etl.go.jp (eccu1-1.etl.go.jp [192.31.200.150]) by mail1-im.etl.go.jp (8.9.1a/3.7W-99072817) with ESMTP id BAA27738 for ; Fri, 30 Jul 1999 01:29:34 +0900 (JST) Received: from etlkbs.etl.go.jp (root@etlkbs-clean [192.31.200.69]) by eccu1-1.etl.go.jp (8.9.3/3.7W-ETL-MASTER) with SMTP id BAA15658; Fri, 30 Jul 1999 01:29:33 +0900 (JST) Received: by etlkbs.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA27596; Fri, 30 Jul 99 01:29:31 JST Date: Fri, 30 Jul 99 01:29:31 JST Mime-Version: 1.0 (generated by vin3.3.4) Content-Type: text/plain; charset=US-ASCII X-Mailer: Vin 3.3.4/990517 on SunOS/4.1.3-JL To: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? From: ysato@etl.go.jp (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) Organization: Message-Id: References: <9907271056.ZM3873@cbmail.cb.lucent.com> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: In message <9907271056.ZM3873@cbmail.cb.lucent.com> on 07/27/99(23:56:14) you "Mark Horton" wrote: |It seems that a new MIME standard for content-transfer-encoding that |would indicate a compressed base64 type ala gzip could be nice. I think the standard should satisfy followings: - Content-Type must indicate the type of the body properly (of course) - any combination of Content-Type and C-T-Encoding should be possible - any order of recursive (nested) C-T-Encodings should be applicable Maybe I reinvented something rejected in past but I'm curious why using message/rfc822 for nested encoding is not good. For example, I think we can send gziped text encoded in base64 like this: Content-Type: message/mime Content-Transfer-Encoding: base64 where the is decoded into a MIME message like this: Content-Type: text/plain Content-Transfer-Encoding: x-gzip Cheers, Yutaka -- Yutaka Sato http://www.etl.go.jp/~ysato/ @ @ Computer Science Division, Electrotechnical Laboratory ( - ) 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan _< >_ From owner-ietf-smtp Thu Jul 29 09:43:24 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA18009 for ietf-smtp-bks; Thu, 29 Jul 1999 09:43:24 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA18005 for ; Thu, 29 Jul 1999 09:43:23 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id MAA20011; Thu, 29 Jul 1999 12:43:54 -0400 (EDT) Message-Id: <199907291643.MAA20011@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ysato@etl.go.jp (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Fri, 30 Jul 1999 01:29:31 +0200." Date: Thu, 29 Jul 1999 12:43:54 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I think the standard should satisfy followings: > - Content-Type must indicate the type of the body properly (of course) > - any combination of Content-Type and C-T-Encoding should be possible > - any order of recursive (nested) C-T-Encodings should be applicable oh no, not this argument again... > Maybe I reinvented something rejected in past but I'm curious why using > message/rfc822 for nested encoding is not good. the more levels of encoding you have, the less chance you have of being able to interoperate. Keith From owner-ietf-smtp Thu Jul 29 10:18:05 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA19150 for ietf-smtp-bks; Thu, 29 Jul 1999 10:18:05 -0700 (PDT) Received: from pimail.ima.com (root@pimail.ima.com [202.75.2.3]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA19146 for ; Thu, 29 Jul 1999 10:17:59 -0700 (PDT) Received: from panay by pimail.ima.com (8.8.7/1.14.5) with SMTP id RAA17661; Thu, 29 Jul 1999 17:05:32 GMT Message-ID: <00d701bed9e6$82c3fb60$6e024bca@panay.ima.com> From: "Tim Kehres" To: , "Jacob Palme" Subject: Re: compressed content-transfer-encoding? Date: Fri, 30 Jul 1999 01:19:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jacob, >With compression in the application layer, an attachment will >be compressed by the original sender, and not uncompressed >again until by the final recipient. In addition however the receiving UA will need to have compatible capabilities with the sending UA. If this is not the case, the message may get there, but will be rendered unusable. I suspect that this is the problem with breaking software that Keith has been suggesting. The advantage of this approach is that you (may) save in local and transient storage. >With compression in the transport layer, the attachment >will be compressed and uncompressed for each store-and-forward >step. In this situation the compression is transparent to both end UA's, and it's application is dependent upon the negioated capabilities of each transport link. Advantages include not having to modify any UA's or have knowledge of recipient UA capabilities. Disadvantage is that there is no gain on the local storage side. Seems like both approaches may have their merits, depending upon what problem you are trying to solve at a given time. Best Regards, -- Tim From owner-ietf-smtp Thu Jul 29 10:46:36 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA19751 for ietf-smtp-bks; Thu, 29 Jul 1999 10:46:36 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA19747 for ; Thu, 29 Jul 1999 10:46:34 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id NAA20567; Thu, 29 Jul 1999 13:47:02 -0400 (EDT) Message-Id: <199907291747.NAA20567@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tim Kehres" cc: ietf-smtp@imc.org, "Jacob Palme" Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Fri, 30 Jul 1999 01:19:27 +0800." <00d701bed9e6$82c3fb60$6e024bca@panay.ima.com> Date: Thu, 29 Jul 1999 13:47:01 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > >With compression in the application layer, an attachment will > >be compressed by the original sender, and not uncompressed > >again until by the final recipient. > > > In addition however the receiving UA will need to have compatible > capabilities with the sending UA. If this is not the case, the message may > get there, but will be rendered unusable. I suspect that this is the > problem with breaking software that Keith has been suggesting. there are two kinds of brokenness that this threatens to introduce: 1. brokenness due to lack of backward compatibility 2. brokenness due to software bugs as a result of increased complexity. email is already too unreliable; the last thing I want to do is make MTAs more complex than they already are (thus further decreasing reliability) for a dubious benefit. note that some approaches to compression are more reliable than others - using a separate per-hop negotiated compression layer on top of SMTP strikes me as more reliable than on-the-fly translation of content-transfer-encodings. particularly if the separate compression layer has built in integrity checking. Keith From owner-ietf-smtp Fri Jul 30 12:35:06 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA13773 for ietf-smtp-bks; Fri, 30 Jul 1999 12:35:06 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13769 for ; Fri, 30 Jul 1999 12:35:04 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id VAA25772 for ; Fri, 30 Jul 1999 21:37:40 +0200 (MET DST) Mime-Version: 1.0 Message-Id: In-Reply-To: <199907291428.KAA19344@astro.cs.utk.edu> References: <199907291428.KAA19344@astro.cs.utk.edu> Date: Fri, 30 Jul 1999 21:25:58 +0200 To: ietf-smtp@imc.org From: Jacob Palme Subject: Re: compressed content-transfer-encoding? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10.28 -0400 99-07-29, Keith Moore wrote: > > We already have a standard for sending compressed data in e-mail. > > We have an IANA registered content-type application/zip. > >application/zip is not a standard. It depends on the definition of a standard. If you define a standard the way RFC 2418 defines "Internet standard" then it is not a standard. But then neither ASCII nor UNICODE nor HTML 4.0 are standards! And not even HTTP is a standard, it is only a draft standard! I would prefer that standards developed by IETF are labelled IETF standards and not Internet standards, since the term "Internet standard" may wrongly give the impression that these are the only standards for the Internet. My definition of a standard is "a common format or protocols used by many different interworking products from different vendors". With that definiton of "standard" certainly application/zip is a standard. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Fri Jul 30 12:36:44 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA13798 for ietf-smtp-bks; Fri, 30 Jul 1999 12:36:44 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13794 for ; Fri, 30 Jul 1999 12:36:43 -0700 (PDT) Received: from localhost (dwing@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA20873 for ; Fri, 30 Jul 1999 12:38:51 -0700 (PDT) Date: Fri, 30 Jul 1999 12:38:50 -0700 (PDT) From: Dan Wing To: ietf-smtp@imc.org Subject: IMAP/POP compression for slow links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: As someone else pointed out, POP and IMAP is where the users feel an impact. I would argue that few people run SMTP servers on slow links, and while most users at work are on fast links (typically ethernet), most users at home or on the road are on slow links. Thus, perhaps an IMAP (and POP) extension to allow on-the-fly compression would give the biggest bang for the buck. It has an additional advantage of not causing the interoperability problems with a new Content-Encoding. Such an extension would be useful even after RESCAP and some kind of Content-Encoding compression were being deployed and would provide a benefit to users even if the sender didn't support RESCAP or the new Content-Encoding compression. -Dan Wing From owner-ietf-smtp Fri Jul 30 12:45:23 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA13862 for ietf-smtp-bks; Fri, 30 Jul 1999 12:45:23 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13858 for ; Fri, 30 Jul 1999 12:45:22 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id PAA13929; Fri, 30 Jul 1999 15:45:54 -0400 (EDT) Message-Id: <199907301945.PAA13929@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Wing cc: ietf-smtp@imc.org Subject: Re: IMAP/POP compression for slow links In-reply-to: Your message of "Fri, 30 Jul 1999 12:38:50 PDT." Date: Fri, 30 Jul 1999 15:45:54 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I would argue that few people run SMTP servers on slow links really? I've heard lots of complaints from people about long delays when trying to submit messages over a dialup line, using SMTP. If TLS can do the compression (and offhand I don't remember if it does this), I see no reason to define a separate layer for this purpose. Keith From owner-ietf-smtp Fri Jul 30 12:47:15 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA13874 for ietf-smtp-bks; Fri, 30 Jul 1999 12:47:15 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA13870 for ; Fri, 30 Jul 1999 12:47:14 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id PAA13941; Fri, 30 Jul 1999 15:47:46 -0400 (EDT) Message-Id: <199907301947.PAA13941@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jacob Palme cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Fri, 30 Jul 1999 21:25:58 +0200." Date: Fri, 30 Jul 1999 15:47:46 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > My definition of a standard is "a common format or protocols > used by many different interworking products from different > vendors". even so, I don't think zip qualifies. it's common, but certainly not ubiquitous, and it's mostly used on a single vendor's platforms. Keith From owner-ietf-smtp Sat Jul 31 06:01:21 1999 Received: by mail.proper.com (8.9.3/8.9.3) id GAA14375 for ietf-smtp-bks; Sat, 31 Jul 1999 06:01:21 -0700 (PDT) Received: from khms.westfalen.de (mail@khms.westfalen.de [193.174.5.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA14371 for ; Sat, 31 Jul 1999 06:01:18 -0700 (PDT) Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.02 #1) id 11AYHu-0001ll-00 (Debian); Sat, 31 Jul 1999 14:30:54 +0200 Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 31 Jul 1999 14:30:05 +0200 Date: 31 Jul 1999 12:40:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf-smtp@imc.org Message-ID: <7LuZy8M1w-B@khms.westfalen.de> In-Reply-To: <199907301947.PAA13941@astro.cs.utk.edu> Subject: Re: compressed content-transfer-encoding? X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <199907301947.PAA13941@astro.cs.utk.edu> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: moore@cs.utk.edu (Keith Moore) wrote on 30.07.99 in <199907301947.PAA13941@astro.cs.utk.edu>: > > My definition of a standard is "a common format or protocols > > used by many different interworking products from different > > vendors". > > even so, I don't think zip qualifies. it's common, but > certainly not ubiquitous, and it's mostly used on a single > vendor's platforms. Well, it's difficult finding a platform zip has not been ported to. OTOH, I have no idea how widespread MIME support for application/zip is. As a data point, it's in my /etc/mime.types (and, incidentally, /etc/mime- magic). That's a Debian/GNU Linux system. And ISTR that the first commercial vendor to ship their OS with an unzipping lib was IBM (OS/2), and that M$ has still not done so. MfG Kai From owner-ietf-smtp Sat Jul 31 08:27:55 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA15943 for ietf-smtp-bks; Sat, 31 Jul 1999 08:27:55 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA15939 for ; Sat, 31 Jul 1999 08:27:54 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id LAA19025; Sat, 31 Jul 1999 11:26:08 -0400 (EDT) Message-Id: <199907311526.LAA19025@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: kaih@khms.westfalen.de (Kai Henningsen) cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "31 Jul 1999 12:40:00 +0200." <7LuZy8M1w-B@khms.westfalen.de> Date: Sat, 31 Jul 1999 11:26:08 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > even so, I don't think zip qualifies. it's common, but > > certainly not ubiquitous, and it's mostly used on a single > > vendor's platforms. > > Well, it's difficult finding a platform zip has not been ported to. indeed, you can find a zip program for almost any platform in existence. but that doesn't mean it's widely used on more than one of those platforms. (similar things could be said for most comprssion/archive formats) but the real problem with the application/zip hack is not the format, it's that it's a very lame way of adding compression to MIME. Keith From owner-ietf-smtp Sat Jul 31 08:58:36 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA16200 for ietf-smtp-bks; Sat, 31 Jul 1999 08:58:36 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA16196 for ; Sat, 31 Jul 1999 08:58:35 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52127(1)>; Sat, 31 Jul 1999 09:01:08 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <97854>; Sat, 31 Jul 1999 09:01:01 PDT From: "Larry Masinter" To: "Keith Moore" Cc: Subject: RE: compressed content-transfer-encoding? Date: Sat, 31 Jul 1999 09:01:00 PDT Message-ID: <000001bedb6d$e2107480$28f3ac98@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199907311526.LAA19025@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > but the real problem with the application/zip hack is not the format, > it's that it's a very lame way of adding compression to MIME. Very cogent argument. Perhaps you meant to say that using the content-type to indicate compression format hides the actual content. These days, anti-virus scanners seem to have a feature for 'scan ZIP files too', so, even though it's lame, the auxiliary mechanisms seem to be making their way through the infrastructure. And Java ships with Zip-file 'file system' support. Even though application/zip is lame, other mechanisms might be worse. Maybe we should look harder at providing what would be necessary to make 'application/zip' actually work, e.g., some top-level indication of what's actually in the package? Larry From owner-ietf-smtp Sat Jul 31 09:01:32 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA16238 for ietf-smtp-bks; Sat, 31 Jul 1999 09:01:32 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA16234 for ; Sat, 31 Jul 1999 09:01:31 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id MAA19175; Sat, 31 Jul 1999 12:02:36 -0400 (EDT) Message-Id: <199907311602.MAA19175@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Larry Masinter" cc: "Keith Moore" , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Sat, 31 Jul 1999 09:01:00 PDT." <000001bedb6d$e2107480$28f3ac98@copper.parc.xerox.com> Date: Sat, 31 Jul 1999 12:02:36 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > Even though application/zip is lame, other mechanisms might be > worse. Maybe we should look harder at providing what would be > necessary to make 'application/zip' actually work, e.g., some > top-level indication of what's actually in the package? this has the same deployment barrier as adding a new content-transfer-encoding - in either case the mime mail reader needs to know what to do with the extra parameter or the new c-t-e. From owner-ietf-smtp Sat Jul 31 09:42:12 1999 Received: by mail.proper.com (8.9.3/8.9.3) id JAA16563 for ietf-smtp-bks; Sat, 31 Jul 1999 09:42:12 -0700 (PDT) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.9.3/8.9.3) with SMTP id JAA16559 for ; Sat, 31 Jul 1999 09:42:11 -0700 (PDT) Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52145(3)>; Sat, 31 Jul 1999 09:44:50 PDT Received: from copper.parc.xerox.com ([13.0.208.21]) by thelma.parc.xerox.com with SMTP id <97859>; Sat, 31 Jul 1999 09:44:44 PDT From: "Larry Masinter" To: Cc: Subject: RE: compressed content-transfer-encoding? Date: Sat, 31 Jul 1999 09:44:44 PDT Message-ID: <000501bedb73$fe189b20$28f3ac98@copper.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199907311602.MAA19175@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > Even though application/zip is lame, other mechanisms might be > > worse. Maybe we should look harder at providing what would be > > necessary to make 'application/zip' actually work, e.g., some > > top-level indication of what's actually in the package? > > this has the same deployment barrier as adding a new > content-transfer-encoding - in either case the mime mail > reader needs to know what to do with the extra parameter > or the new c-t-e. I'm not sure this is true. Unaware MIME mailers will just see they have application/zip, that they either recognize or not, and users of existing MIME mail programs have simple way of configuring their mail reader to at do something sensible with it. Adding a new content-transfer-encoding has a more serious deployment problem, because most deployed systems don't have any kind of extensibility built in for CTE. Mailing around zip files is common practice. Many people are used to dealing with getting a zip file. Leveraging this just means making the common practice easier to accomplish for senders, and less awkward for receivers; it's a product enhancement that mail client vendors could add today. In the menu for 'attach file', it could just have a check box for 'send zipped', for example, and a setting for making 'send zipped' the default for attachments, or for attachments that aren't known to already have better media-specific compression. From owner-ietf-smtp Sat Jul 31 10:04:52 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA16862 for ietf-smtp-bks; Sat, 31 Jul 1999 10:04:52 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA16858; Sat, 31 Jul 1999 10:04:49 -0700 (PDT) Message-Id: <4.2.0.58.19990731100251.0202f100@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 31 Jul 1999 10:05:49 -0700 To: "Larry Masinter" , From: Paul Hoffman / IMC Subject: RE: compressed content-transfer-encoding? Cc: In-Reply-To: <000501bedb73$fe189b20$28f3ac98@copper.parc.xerox.com> References: <199907311602.MAA19175@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I see a problem here with making a content type (zipped) act like a c-t-e. Zipped seems fine for "attachments", that is, leaves in the MIME tree. But some of the requirement for making messages smaller would want to compress a whole message, which might be a nested multipart. At this point, zipped hides the lower layers. If we want a rule that say "you can't use app/zipped for multiparts", how does this become different than a c-t-e? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Sat Jul 31 10:25:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA17003 for ietf-smtp-bks; Sat, 31 Jul 1999 10:25:39 -0700 (PDT) Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA16995 for ; Sat, 31 Jul 1999 10:25:38 -0700 (PDT) Received: from dave-vaio (free.88.106.bayarea.net [205.219.88.106]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id KAA09667; Sat, 31 Jul 1999 10:28:13 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Message-Id: <4.2.0.58.19990731102221.00b71670@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 31 Jul 1999 10:23:13 -0700 To: Keith Moore From: Dave Crocker Subject: Re: compressed content-transfer-encoding? Cc: Jacob Palme , ietf-smtp@imc.org In-Reply-To: <199907291428.KAA19344@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 07:28 AM 7/29/99 , Keith Moore wrote: > > We already have a standard for sending compressed data in e-mail. > > We have an IANA registered content-type application/zip. > >application/zip is not a standard. Just to beat this one into the ground: It's also not a compression mechanism. It does "bagging" of independent obkects, but does not compress the bits. d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +1 408 246 8253 Brandenburg Consulting Fax: +1 408 273 6464 675 Spruce Drive Sunnyvale, CA 94086 USA From owner-ietf-smtp Sat Jul 31 10:25:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA17002 for ietf-smtp-bks; Sat, 31 Jul 1999 10:25:39 -0700 (PDT) Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA16993 for ; Sat, 31 Jul 1999 10:25:37 -0700 (PDT) Received: from dave-vaio (free.88.106.bayarea.net [205.219.88.106]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id KAA09670; Sat, 31 Jul 1999 10:28:15 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Message-Id: <4.2.0.58.19990731102327.00afc550@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 31 Jul 1999 10:26:06 -0700 To: Valdis.Kletnieks@vt.edu From: Dave Crocker Subject: Re: compressed content-transfer-encoding? Cc: "Tim Kehres" , ietf-smtp@imc.org In-Reply-To: <199907291516.d6TFGf003148@black-ice.cc.vt.edu> References: <05a601bed937$2f124df0$6e024bca@panay.ima.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 08:16 AM 7/29/99 , Valdis.Kletnieks@vt.edu wrote: >I'm also distressed at this cavalier "with the cost of..." trend of late. > >Some places run on tight budgets or have other constraints. I turned As in, most of the world. We really do need to remember just how limited bandwidth (in particular) and "Internet performance" are in much of the Internet. Added to that is that much of the user community pays a usage fee for connection time. And it will be a very long time before things improve. d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +1 408 246 8253 Brandenburg Consulting Fax: +1 408 273 6464 675 Spruce Drive Sunnyvale, CA 94086 USA From owner-ietf-smtp Sat Jul 31 10:38:46 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA17097 for ietf-smtp-bks; Sat, 31 Jul 1999 10:38:46 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA17093 for ; Sat, 31 Jul 1999 10:38:45 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id NAA19709; Sat, 31 Jul 1999 13:39:47 -0400 (EDT) Message-Id: <199907311739.NAA19709@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Valdis.Kletnieks@vt.edu, "Tim Kehres" , ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Sat, 31 Jul 1999 10:26:06 PDT." <4.2.0.58.19990731102327.00afc550@mail.bayarea.net> Date: Sat, 31 Jul 1999 13:39:47 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > We really do need to remember just how limited bandwidth (in particular) > and "Internet performance" are in much of the Internet. Added to that is > that much of the user community pays a usage fee for connection time. sure, but compressing modems *are* widely deployed. if the "connection" uses a compressing modem, any additional savings in "connection time" resulting from smtp or mime compression is truly marginal. you'll get more connection time savings from pipelining smtp than you will from compressing the data. Keith From owner-ietf-smtp Sat Jul 31 10:35:37 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA17073 for ietf-smtp-bks; Sat, 31 Jul 1999 10:35:37 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA17069 for ; Sat, 31 Jul 1999 10:35:36 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id NAA19644; Sat, 31 Jul 1999 13:36:40 -0400 (EDT) Message-Id: <199907311736.NAA19644@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Larry Masinter" cc: moore@cs.utk.edu, ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Sat, 31 Jul 1999 09:44:44 PDT." <000501bedb73$fe189b20$28f3ac98@copper.parc.xerox.com> Date: Sat, 31 Jul 1999 13:36:40 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > > Even though application/zip is lame, other mechanisms might be > > > worse. Maybe we should look harder at providing what would be > > > necessary to make 'application/zip' actually work, e.g., some > > > top-level indication of what's actually in the package? > > > > this has the same deployment barrier as adding a new > > content-transfer-encoding - in either case the mime mail > > reader needs to know what to do with the extra parameter > > or the new c-t-e. > > I'm not sure this is true. Unaware MIME mailers will just > see they have application/zip, that they either recognize > or not, and users of existing MIME mail programs have simple > way of configuring their mail reader to at do something > sensible with it. not clear. it's one thing to add an ordinary content-type to an existing mail reader, quite another to add a content-type that says "decode this body part and then dispatch to the appropriate content-type handler for its contents" especially if the contents can contain multiple files, or multiparts, or signed objects. etc. > Adding a new content-transfer-encoding has a more serious > deployment problem, because most deployed systems don't have > any kind of extensibility built in for CTE. yes, but my point is that basically you have to upgrade the MUA anyway to make this work well. might as well do it right. > Mailing around zip files is common practice. Many people are > used to dealing with getting a zip file. Leveraging this > just means making the common practice easier to accomplish > for senders, and less awkward for receivers; it's a product > enhancement that mail client vendors could add today. it's by no means a common practice for everyone - just for some users of certain platforms. even the most common platform on which zip is used doesn't ship with zip support. so no, in general, people are not used to dealing with getting a zip file. so what you are proposing to do is to clutter up the MIME architecture and degrade the recipient's user interface just so a minority of users who already use zip don't have to upgrade immedately. in the long run I don't think it's worth it. Keith From owner-ietf-smtp Sun Aug 1 08:06:54 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA28775 for ietf-smtp-bks; Sun, 1 Aug 1999 08:06:54 -0700 (PDT) Received: from khms.westfalen.de (mail@khms.westfalen.de [193.174.5.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA28771 for ; Sun, 1 Aug 1999 08:06:49 -0700 (PDT) Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.02 #1) id 11Ax9Q-0008D6-00 (Debian); Sun, 01 Aug 1999 17:03:48 +0200 Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 01 Aug 1999 17:03:34 +0200 Date: 01 Aug 1999 13:39:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf-smtp@imc.org Message-ID: <7M2FRVEXw-B@khms.westfalen.de> In-Reply-To: <4.2.0.58.19990731102221.00b71670@mail.bayarea.net> Subject: Re: compressed content-transfer-encoding? X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <199907291428.KAA19344@astro.cs.utk.edu> <4.2.0.58.19990731102221.00b71670@mail.bayarea.net> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: dcrocker@brandenburg.com (Dave Crocker) wrote on 31.07.99 in <4.2.0.58.19990731102221.00b71670@mail.bayarea.net>: > At 07:28 AM 7/29/99 , Keith Moore wrote: > > > We already have a standard for sending compressed data in e-mail. > > > We have an IANA registered content-type application/zip. > > > >application/zip is not a standard. > > Just to beat this one into the ground: > > It's also not a compression mechanism. > > It does "bagging" of independent obkects, but does not compress the bits. This turns out not to be the case. The application/zip format typically compresses the contained objects with deflate. ("typically" because there are other algorithms of only historic significance, and also the option not to use compression; but it's been a long time since I last saw anything except deflate.) Now, I certainly agree that this is a poor match with MIME, but the reason is that it uses a different, incompatible mechanism to describe the contained objects. MfG Kai From owner-ietf-smtp Sun Aug 1 08:06:11 1999 Received: by mail.proper.com (8.9.3/8.9.3) id IAA28767 for ietf-smtp-bks; Sun, 1 Aug 1999 08:06:11 -0700 (PDT) Received: from khms.westfalen.de (mail@khms.westfalen.de [193.174.5.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA28761 for ; Sun, 1 Aug 1999 08:06:01 -0700 (PDT) Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.02 #1) id 11Ax9Q-0008D6-01 (Debian); Sun, 01 Aug 1999 17:03:48 +0200 Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 01 Aug 1999 17:03:34 +0200 Date: 01 Aug 1999 13:46:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf-smtp@imc.org Message-ID: <7M2FRW21w-B@khms.westfalen.de> In-Reply-To: <199907311739.NAA19709@astro.cs.utk.edu> Subject: Re: compressed content-transfer-encoding? X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <4.2.0.58.19990731102327.00afc550@mail.bayarea.net> <199907311739.NAA19709@astro.cs.utk.edu> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: moore@cs.utk.edu (Keith Moore) wrote on 31.07.99 in <199907311739.NAA19709@astro.cs.utk.edu>: > > We really do need to remember just how limited bandwidth (in particular) > > and "Internet performance" are in much of the Internet. Added to that is > > that much of the user community pays a usage fee for connection time. > > sure, but compressing modems *are* widely deployed. if the "connection" > uses a compressing modem, any additional savings in "connection time" > resulting from smtp or mime compression is truly marginal. I don't know about you, but in my experience, modem compression (and similar schemes) typically does a fairly poor job. There's a fairly simple reason. This type of compression must keep latencies from growing too much. This *really* hurts compression. > you'll get more connection time savings from pipelining smtp than you > will from compressing the data. That's only true if the time is dominated by RCPT TO: handling, that is, you're sending many small mails. When you're sending a few large mails, pipelining is completely irrelevant, and compression is very important, because you spend most of the time in the DATA phase anyway. I don't think anyone really wants compression for small mails. MfG Kai From owner-ietf-smtp Sun Aug 1 10:21:31 1999 Received: by mail.proper.com (8.9.3/8.9.3) id KAA29581 for ietf-smtp-bks; Sun, 1 Aug 1999 10:21:31 -0700 (PDT) Received: from lupinella.troll.no (lupinella.troll.no [195.0.254.19]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA29577 for ; Sun, 1 Aug 1999 10:21:28 -0700 (PDT) Received: by troll.no id <75507-26346>; Sun, 1 Aug 1999 19:24:09 +0200 To: kaih@khms.westfalen.de (Kai Henningsen) Cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? References: <4.2.0.58.19990731102327.00afc550@mail.bayarea.net> <199907311739.NAA19709@astro.cs.utk.edu> <7M2FRW21w-B@khms.westfalen.de> From: Arnt Gulbrandsen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 01 Aug 1999 19:24:08 +0200 In-Reply-To: kaih@khms.westfalen.de's message of "01 Aug 1999 13:46:00 +0200" Message-ID: Lines: 13 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: kaih@khms.westfalen.de (Kai Henningsen) > I don't know about you, but in my experience, modem compression (and > similar schemes) typically does a fairly poor job. > > There's a fairly simple reason. This type of compression must keep > latencies from growing too much. This *really* hurts compression. I see what you mean. However, PPP compression (RFC 1962) should not have this problem, since the additional time taken to start sending each packet should be more than offset by the decrease in transmission time. --Arnt From owner-ietf-smtp Sun Aug 1 11:06:26 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29778 for ietf-smtp-bks; Sun, 1 Aug 1999 11:06:26 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29774 for ; Sun, 1 Aug 1999 11:06:25 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id OAA00576; Sun, 1 Aug 1999 14:06:15 -0400 (EDT) Message-Id: <199908011806.OAA00576@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: kaih@khms.westfalen.de (Kai Henningsen) cc: ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "01 Aug 1999 13:46:00 +0200." <7M2FRW21w-B@khms.westfalen.de> Date: Sun, 01 Aug 1999 14:06:15 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > I don't know about you, but in my experience, modem compression (and > similar schemes) typically does a fairly poor job. > > There's a fairly simple reason. This type of compression must keep > latencies from growing too much. This *really* hurts compression. actually my experience is just the opposite ... modem compression (usually based on LZW) does a reasonably good job ... not as good as gzip or bz2 but close enough. and yes, one difference between the effectiveness of these algorithms is the amount of latency/ lookahead that is needed. LZW is amazingly good for an algorithm needing only a fixed amount of memory and one octet lookahead. but for me the disappointing thing about modems is that they add far more latency than you would expect given their speed. I don't think this is the fault of the compression so much as the error correction (I suspect that many modems rely on error correction to compensate for marginal analog circuitry) > > you'll get more connection time savings from pipelining smtp than you > > will from compressing the data. > > That's only true if the time is dominated by RCPT TO: handling, that is, > you're sending many small mails. When you're sending a few large mails, > pipelining is completely irrelevant, and compression is very important, > because you spend most of the time in the DATA phase anyway. right. but even these days most messages are small. and I was assuming that this traffic was already going over compressing modems, which would save almost as much bandwidth as compressing smtp data. Keith From owner-ietf-smtp Sun Aug 1 11:15:07 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29805 for ietf-smtp-bks; Sun, 1 Aug 1999 11:15:07 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29801 for ; Sun, 1 Aug 1999 11:15:06 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id OAA00661; Sun, 1 Aug 1999 14:12:09 -0400 (EDT) Message-Id: <199908011812.OAA00661@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Arnt Gulbrandsen cc: kaih@khms.westfalen.de (Kai Henningsen), ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "01 Aug 1999 19:24:08 +0200." Date: Sun, 01 Aug 1999 14:12:09 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > There's a fairly simple reason. This type of compression must keep > > latencies from growing too much. This *really* hurts compression. > > I see what you mean. However, PPP compression (RFC 1962) should not > have this problem, since the additional time taken to start sending > each packet should be more than offset by the decrease in transmission > time. depends on which PPP compression algorithm is used. the typical (for me at least) "BSD compress" algorithm is almost the same algorithm as the one used in modems. but then again I use NetBSD. I don't know what compression Mac or Windoze stacks use. my understanding is that with compressing modems, the main additional value of PPP compression is in reducing interrupt overhead. Keith From owner-ietf-smtp Sun Aug 1 11:34:04 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29887 for ietf-smtp-bks; Sun, 1 Aug 1999 11:34:04 -0700 (PDT) Received: from lupinella.troll.no (lupinella.troll.no [195.0.254.19]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29883 for ; Sun, 1 Aug 1999 11:34:02 -0700 (PDT) Received: by troll.no id <75540-26346>; Sun, 1 Aug 1999 20:36:34 +0200 To: Keith Moore Cc: kaih@khms.westfalen.de (Kai Henningsen), ietf-smtp@imc.org Subject: Re: compressed content-transfer-encoding? References: <199908011812.OAA00661@astro.cs.utk.edu> From: Arnt Gulbrandsen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 01 Aug 1999 20:36:34 +0200 In-Reply-To: Keith Moore's message of "Sun, 01 Aug 1999 14:12:09 -0400" Message-ID: Lines: 18 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Keith Moore > depends on which PPP compression algorithm is used. the typical > (for me at least) "BSD compress" algorithm is almost the same > algorithm as the one used in modems. Yes, but the data is different :) A PPP-based algorithm can look ahead until the end of the IP packet without cost. A modem has to wait for each byte coming in across a comparatively slow connection, so good compression means waiting for a "long" time before emitting output. In the extreme case, a 56k modem with a 115,200bps host link and twelve-bit BSD compression can't read more than about 1.5-2 characters before it has to emit output or introduce latency. (Maybe I've just understood why people use these newfangled host connections - EPP or whatever. I forget the abbreviation.) --Arnt From owner-ietf-smtp Sun Aug 1 11:53:19 1999 Received: by mail.proper.com (8.9.3/8.9.3) id LAA29948 for ietf-smtp-bks; Sun, 1 Aug 1999 11:53:19 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA29944 for ; Sun, 1 Aug 1999 11:53:18 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id UAA04900; Sun, 1 Aug 1999 20:56:03 +0200 (MET DST) Mime-Version: 1.0 Message-Id: In-Reply-To: <199907311602.MAA19175@astro.cs.utk.edu> References: <199907311602.MAA19175@astro.cs.utk.edu> Date: Sun, 1 Aug 1999 12:00:46 +0200 To: ietf-smtp@imc.org From: Jacob Palme Subject: Re: compressed content-transfer-encoding? Cc: "Keith Moore" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12.02 -0400 99-07-31, Keith Moore wrote: > > Even though application/zip is lame, other mechanisms might be > > worse. Maybe we should look harder at providing what would be > > necessary to make 'application/zip' actually work, e.g., some > > top-level indication of what's actually in the package? > >this has the same deployment barrier as adding a new >content-transfer-encoding - in either case the mime mail >reader needs to know what to do with the extra parameter >or the new c-t-e. No, it has one very important advantage: It will co-work, with existing software using application/zip, in the way people are already accustomed to sending and receiving compressed e-mail in that format. At 10.05 -0700 99-07-31, Paul Hoffman / IMC wrote: >I see a problem here with making a content type (zipped) act like a >c-t-e. Zipped seems fine for "attachments", that is, leaves in the >MIME tree. But some of the requirement for making messages smaller >would want to compress a whole message, which might be a nested >multipart. At this point, zipped hides the lower layers. If we want >a rule that say "you can't use app/zipped for multiparts", how does >this become different than a c-t-e? Zip is not used to compress multiparts, just leaves. This is no serious restriction, since the main part of e-mail messages seldom needs compression. It is the attachments which are often large and bulky. Even when the main part is in HTML format, all the images are in other than the main body part. At 13.36 -0400 99-07-31, Keith Moore wrote: >so what you are proposing to do is to clutter up the MIME >architecture and degrade the recipient's user interface >just so a minority of users who already use zip don't have >to upgrade immedately. in the long run I don't think it's >worth it. The zip format may be in a minority of all mail attachments, simply since most mail attachments are not compressed using any compression format. But the zip format is certainly in a large majority of the e-mailed attachments which are compressed at all, and which are sent to me by various people around the world. The only other compression formats which are common in e-mail are the JPEG and GIF formats. I hardly ever get any e-mail with attachments in any other compression format. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-smtp Sun Aug 1 12:10:15 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA00141 for ietf-smtp-bks; Sun, 1 Aug 1999 12:10:15 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA00135 for ; Sun, 1 Aug 1999 12:10:13 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE917P6HC099DO8V@INNOSOFT.COM> for ietf-smtp@imc.org; Sun, 1 Aug 1999 12:11:58 PDT Date: Sun, 01 Aug 1999 12:06:57 -0700 (PDT) From: Ned Freed Subject: RE: compressed content-transfer-encoding? In-reply-to: "Your message dated Sat, 31 Jul 1999 09:44:44 -0700 (PDT)" <000501bedb73$fe189b20$28f3ac98@copper.parc.xerox.com> To: Larry Masinter Cc: moore@cs.utk.edu, ietf-smtp@imc.org Message-id: <01JE93UQTATY99DO8V@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 References: <199907311602.MAA19175@astro.cs.utk.edu> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > > Even though application/zip is lame, other mechanisms might be > > > worse. Maybe we should look harder at providing what would be > > > necessary to make 'application/zip' actually work, e.g., some > > > top-level indication of what's actually in the package? > > > > this has the same deployment barrier as adding a new > > content-transfer-encoding - in either case the mime mail > > reader needs to know what to do with the extra parameter > > or the new c-t-e. > I'm not sure this is true. Unaware MIME mailers will just > see they have application/zip, that they either recognize > or not, and users of existing MIME mail programs have simple > way of configuring their mail reader to at do something > sensible with it. > Adding a new content-transfer-encoding has a more serious > deployment problem, because most deployed systems don't have > any kind of extensibility built in for CTE. Believe me, from a tech support perspective the problems here are far worse than those associated with a CTE. Think about the implications in the context of IMAP, for example, where separate fetch of body parts is an important feature. > Mailing around zip files is common practice. Many people are > used to dealing with getting a zip file. Leveraging this > just means making the common practice easier to accomplish > for senders, and less awkward for receivers; it's a product > enhancement that mail client vendors could add today. Summary and unconditional rejection of ZIPs is also common because of the inability in some environments to check the content for viruses. > In the menu for 'attach file', it could just have a check > box for 'send zipped', for example, and a setting for making > 'send zipped' the default for attachments, or for attachments > that aren't known to already have better media-specific > compression. In case it isn't clear, I am absolutely opposed to increased use of application/zip within MIME. We need to solve the real problem here, which is to allow end-to-end knowledge of what C-Ts and CTEs are supported. Once this is done we can deploy new CTEs or whatever else we chose willy-nilly. And until it is done none of this stuff, with the exception of TLS-based compression, stands a snowball's chance in hell of being widely deployed. Ned From owner-ietf-smtp Sun Aug 1 12:12:49 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA00180 for ietf-smtp-bks; Sun, 1 Aug 1999 12:12:49 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA00175 for ; Sun, 1 Aug 1999 12:12:48 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE917P6HC099DO8V@INNOSOFT.COM> for ietf-smtp@imc.org; Sun, 1 Aug 1999 12:14:35 PDT Date: Sun, 01 Aug 1999 12:12:33 -0700 (PDT) From: Ned Freed Subject: Re: compressed content-transfer-encoding? In-reply-to: "Your message dated Sat, 31 Jul 1999 12:02:36 -0400" <199907311602.MAA19175@astro.cs.utk.edu> To: Keith Moore Cc: Larry Masinter , Keith Moore , ietf-smtp@imc.org Message-id: <01JE93XZ598699DO8V@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <000001bedb6d$e2107480$28f3ac98@copper.parc.xerox.com> Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > > Even though application/zip is lame, other mechanisms might be > > worse. Maybe we should look harder at providing what would be > > necessary to make 'application/zip' actually work, e.g., some > > top-level indication of what's actually in the package? > this has the same deployment barrier as adding a new > content-transfer-encoding - in either case the mime mail > reader needs to know what to do with the extra parameter > or the new c-t-e. Actually the problems are far worse than a new CTE. We end up having to add a bunch of really gross nonorthogonal nonsense to MIME headers and the butchery we'd need on the IMAP front is too terrible to contemplate. And besides, this is effectively a non-lead CTE, and as such runs smack into the no-nested-CTE consensus that allowed MIME to deploy in the first place. Ned From owner-ietf-smtp Sun Aug 1 12:10:41 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA00150 for ietf-smtp-bks; Sun, 1 Aug 1999 12:10:41 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA00146 for ; Sun, 1 Aug 1999 12:10:40 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf v3.2) with ESMTP id PAA00825; Sun, 1 Aug 1999 15:11:54 -0400 (EDT) Message-Id: <199908011911.PAA00825@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jacob Palme cc: ietf-smtp@imc.org, "Keith Moore" Subject: Re: compressed content-transfer-encoding? In-reply-to: Your message of "Sun, 01 Aug 1999 12:00:46 +0200." Date: Sun, 01 Aug 1999 15:11:53 -0400 Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > At 12.02 -0400 99-07-31, Keith Moore wrote: > > > Even though application/zip is lame, other mechanisms might be > > > worse. Maybe we should look harder at providing what would be > > > necessary to make 'application/zip' actually work, e.g., some > > > top-level indication of what's actually in the package? > > > >this has the same deployment barrier as adding a new > >content-transfer-encoding - in either case the mime mail > >reader needs to know what to do with the extra parameter > >or the new c-t-e. > > No, it has one very important advantage: It will co-work, > with existing software using application/zip, in the way > people are already accustomed to sending and receiving > compressed e-mail in that format. it will co-work with existing software that most people don't have, in the way that a small minority of people are already accustomed to working. the vast majority of people will have to either install new software or learn how to cope with zip files, or both. as long as people have to install new software, why not have them install a new MIME mail reader? saying that people are already accustomed to using zip is a lot like saying that AOL comes with built-in MIME support. > At 13.36 -0400 99-07-31, Keith Moore wrote: > >so what you are proposing to do is to clutter up the MIME > >architecture and degrade the recipient's user interface > >just so a minority of users who already use zip don't have > >to upgrade immedately. in the long run I don't think it's > >worth it. > > The zip format may be in a minority of all mail attachments, > simply since most mail attachments are not compressed > using any compression format. But the zip format is > certainly in a large majority of the e-mailed attachments > which are compressed at all, and which are sent to me > by various people around the world. The only other > compression formats which are common in e-mail are > the JPEG and GIF formats. I hardly ever get any e-mail > with attachments in any other compression format. you're missing the point. just because you have zip installed on your computer doesn't mean that the majority of computer users have zip installed. eith From owner-ietf-smtp Sun Aug 1 18:32:13 1999 Received: by mail.proper.com (8.9.3/8.9.3) id SAA09777 for ietf-smtp-bks; Sun, 1 Aug 1999 18:32:13 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA09768 for ; Sun, 1 Aug 1999 18:32:11 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <01JE917P6HC099DO8V@INNOSOFT.COM> for ietf-smtp@imc.org; Sun, 1 Aug 1999 18:33:59 PDT Date: Sun, 01 Aug 1999 18:31:51 -0700 (PDT) From: Ned Freed Subject: Re: IMAP/POP compression for slow links In-reply-to: "Your message dated Fri, 30 Jul 1999 12:38:50 -0700 (PDT)" To: Dan Wing Cc: ietf-smtp@imc.org Message-id: <01JE9H7CTWDO99DO8V@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > As someone else pointed out, POP and IMAP is where the users feel an > impact. I would argue that few people run SMTP servers on slow links, and > while most users at work are on fast links (typically ethernet), most > users at home or on the road are on slow links. > Thus, perhaps an IMAP (and POP) extension to allow on-the-fly compression > would give the biggest bang for the buck. It has an additional advantage > of not causing the interoperability problems with a new Content-Encoding. Again, you can use TLS with both POP and IMAP (and this is supported by quite a few servers). And TLS provides compression as an option, which is good since TLS will severely limit the ability of modems and such to perform link-level compression. > Such an extension would be useful even after RESCAP and some kind of > Content-Encoding compression were being deployed and would provide a > benefit to users even if the sender didn't support RESCAP or the new > Content-Encoding compression. Actually, the extension that's needed in IMAP is one to remove CTEs completely. Do this and use TLS compression and you should have a reasonably effective solution for large messages. And its one that even works for messages already in message stores. Ned From owner-ietf-smtp Tue Mar 14 11:35:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15392 for ietf-smtp-bks; Tue, 14 Mar 2000 11:35:52 -0800 (PST) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15385 for ; Tue, 14 Mar 2000 11:35:50 -0800 (PST) Message-Id: <4.3.2.20000314113340.00b47590@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 14 Mar 2000 11:33:54 -0800 To: ietf-smtp@imc.org From: Paul Hoffman / IMC Subject: Announcement of MailConnect 6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. IMC is pleased to announce our next testing event, MailConnect 6. The event will focus on IMAP4, POP3, and SMTP, and will be held May 31 and June 1 in San Jose, CA. Full details are available at . The two days of MailConnect 6 will focus on IMAP4. IMAP4 is a well-established specification with new facilities promising substantial improvement for mobile and client/server mail environments. IMAP4 implementations have fully emerged, although the large number of new of IMAP extensions have not been subjected to wide inter-vendor testing. MailConnect 6 will provide an opportunity for intense interoperability testing and repair of IMAP4 implementations. During the previous MailConnect events, it has become clear that client developers need to pay more attention to the disconnected mode of IMAP. MailConnect is an excellent place for client and server vendors to test interoperability in this area. Further, IMAP is a dynamic protocol, and many valuable extensions have been proposed in the past year. Developers will want to meet with other developers at MailConnect to test their early implementations of these extensions. Because most IMAP vendors also have POP3 and SMTP implementations, MailConnect 6 will be a good place to test them as well. A new round of extensions to POP have come out in the past year, and client vendors have expressed strong interest in testing these. Also in the past year, many extensions to SMTP have been standardized and deployed; these new features will be the focus of the SMTP testing at MailConnect 6. Specifically, message submission, SMTP over TLS, and SMTP authorization are likely candidates for participant testing. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smtp Tue Jul 18 11:31:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA04005 for ietf-smtp-bks; Tue, 18 Jul 2000 11:31:12 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04001 for ; Tue, 18 Jul 2000 11:31:11 -0700 (PDT) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.11.0.Beta4/8.11.0.Beta4) with ESMTP id e6IIWUY25908; Tue, 18 Jul 2000 14:32:30 -0400 Message-Id: <200007181832.e6IIWUY25908@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Kyle Jones Cc: sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... In-Reply-To: Your message of "Tue, 18 Jul 2000 10:46:13 PDT." <14708.38885.95422.69372@ice.wonderworks.com> 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[ <14708.33409.447058.273936@horsey.gshapiro.net> <14708.38885.95422.69372@ice.wonderworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1656617848P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2000 14:32:29 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1656617848P Content-Type: text/plain; charset=us-ascii (Am cc'ing the IETF-SMTP list, hopefully it's alive and somebody there will have guidance on this... For the IETF-SMTP list, the discussion is what to properly do if handed this during an SMTP transaction: MAIL FROM: Sendmail currently issues a '250 OK'. On Tue, 18 Jul 2000 10:46:13 PDT, Kyle Jones said: > The attitude I took when I ran a relaying server was that stuff > like a@b@c was better off bounced immediately. I can deal with that attitude. However, RFC821 also lists the following codes on page 56: 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 551 User not local; please try 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 554 Transaction failed But then continues to say: MAIL S: 250 F: 552, 451, 452 E: 500, 501, 421 RCPT S: 250, 251 F: 550, 551, 552, 553, 450, 451, 452 E: 500, 501, 503, 421 (I.e. you can toss a 553 on the RCPT TO, but not on a MAIL FROM). RFC1123 then muddies things up more: 5.2.10 SMTP Replies: RFC-821 Section 4.2 A receiver-SMTP SHOULD send only the reply codes listed in section 4.2.2 of RFC-821 or in this document. A receiver-SMTP SHOULD use the text shown in examples in RFC-821 whenever appropriate. A sender-SMTP MUST determine its actions only by the reply code, not by the text (except for 251 and 551 replies); any text, including no text at all, must be acceptable. The space (blank) following the reply code is considered part of the text. Whenever possible, a sender-SMTP SHOULD test only the first digit of the reply code, as specified in Appendix E of RFC-821. DISCUSSION: Interoperability problems have arisen with SMTP systems using reply codes that are not listed explicitly in RFC- 821 Section 4.3 but are legal according to the theory of reply codes explained in Appendix E. So, is it legal/permissible/suggested to 553 on a MAIL FROM that can be determined to be syntactically invalid? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1656617848P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOXSivHAt5Vm009ewEQJv6QCg5I4Xq7u3EXDRkhAhSTFEaiMVJJYAnjxE wo33Vx0roZv4T8YBixMwdXnf =gEYV -----END PGP SIGNATURE----- --==_Exmh_-1656617848P-- From owner-ietf-smtp Tue Jul 18 12:34:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA06550 for ietf-smtp-bks; Tue, 18 Jul 2000 12:34:13 -0700 (PDT) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06543 for ; Tue, 18 Jul 2000 12:34:12 -0700 (PDT) Received: from shell3.ba.best.com (gjw@shell3.ba.best.com [206.184.139.134]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id MAA23559; Tue, 18 Jul 2000 12:29:05 -0700 (PDT) Date: Tue, 18 Jul 2000 12:29:05 -0700 (PDT) From: "Gregory J. Woodhouse" X-Sender: gjw@shell3.ba.best.com To: Valdis.Kletnieks@vt.edu cc: Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... In-Reply-To: <200007181832.e6IIWUY25908@black-ice.cc.vt.edu> Message-ID: X-Url: http://www.wnetc.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In this case, I think the correct response would be 501, since it is a syntax error in the argument to MAIL. On Tue, 18 Jul 2000 Valdis.Kletnieks@vt.edu wrote: > (Am cc'ing the IETF-SMTP list, hopefully it's alive and somebody there > will have guidance on this... For the IETF-SMTP list, the discussion is > what to properly do if handed this during an SMTP transaction: > > MAIL FROM: > > Sendmail currently issues a '250 OK'. > > On Tue, 18 Jul 2000 10:46:13 PDT, Kyle Jones said: > > The attitude I took when I ran a relaying server was that stuff > > like a@b@c was better off bounced immediately. > > I can deal with that attitude. > > However, RFC821 also lists the following codes on page 56: > > 550 Requested action not taken: mailbox unavailable > [E.g., mailbox not found, no access] > 551 User not local; please try > 552 Requested mail action aborted: exceeded storage allocation > 553 Requested action not taken: mailbox name not allowed > [E.g., mailbox syntax incorrect] > 554 Transaction failed > > But then continues to say: > > MAIL > S: 250 > F: 552, 451, 452 > E: 500, 501, 421 > RCPT > S: 250, 251 > F: 550, 551, 552, 553, 450, 451, 452 > E: 500, 501, 503, 421 > > (I.e. you can toss a 553 on the RCPT TO, but not on a MAIL FROM). > > RFC1123 then muddies things up more: > > 5.2.10 SMTP Replies: RFC-821 Section 4.2 > > A receiver-SMTP SHOULD send only the reply codes listed in > section 4.2.2 of RFC-821 or in this document. A receiver-SMTP > SHOULD use the text shown in examples in RFC-821 whenever > appropriate. > > A sender-SMTP MUST determine its actions only by the reply > code, not by the text (except for 251 and 551 replies); any > text, including no text at all, must be acceptable. The space > (blank) following the reply code is considered part of the > text. Whenever possible, a sender-SMTP SHOULD test only the > first digit of the reply code, as specified in Appendix E of > RFC-821. > > DISCUSSION: > Interoperability problems have arisen with SMTP systems > using reply codes that are not listed explicitly in RFC- > 821 Section 4.3 but are legal according to the theory of > reply codes explained in Appendix E. > > > So, is it legal/permissible/suggested to 553 on a MAIL FROM that can be > determined to be syntactically invalid? > -- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech > > > > --- Gregory Woodhouse gjw@wnetc.com / http://www.wnetc.com/home.html "An atheist staring from his attic window is often nearer to God than the believer caught up in his own false image of God." --Martin Buber From owner-ietf-smtp Tue Jul 18 13:34:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA07802 for ietf-smtp-bks; Tue, 18 Jul 2000 13:34:56 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07798 for ; Tue, 18 Jul 2000 13:34:53 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA24857 for ; Tue, 18 Jul 2000 16:36:44 -0400 (EDT) Received: from att.com ([135.197.90.148]) by maillennium.att.com (labmail) with SMTP id <2000071820342309900k1u02e> (Authid: tony@maillennium.att.com); Tue, 18 Jul 2000 20:34:23 +0000 Message-ID: <3974BF66.D80C2F95@att.com> Date: Tue, 18 Jul 2000 16:34:46 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Valdis.Kletnieks@vt.edu CC: Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... References: <200007181611.e6IGBYY27902@black-ice.cc.vt.edu> <14708.33409.447058.273936@horsey.gshapiro.net> <14708.38885.95422.69372@ice.wonderworks.com> <200007181832.e6IIWUY25908@black-ice.cc.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FWIW, we respond with a 501 code. Tony Hansen tony@att.com Valdis.Kletnieks@vt.edu wrote: > > (Am cc'ing the IETF-SMTP list, hopefully it's alive and somebody there > will have guidance on this... For the IETF-SMTP list, the discussion is > what to properly do if handed this during an SMTP transaction: > > MAIL FROM: > > Sendmail currently issues a '250 OK'. > > On Tue, 18 Jul 2000 10:46:13 PDT, Kyle Jones said: > > The attitude I took when I ran a relaying server was that stuff > > like a@b@c was better off bounced immediately. > > I can deal with that attitude. > > However, RFC821 also lists the following codes on page 56: > > 550 Requested action not taken: mailbox unavailable > [E.g., mailbox not found, no access] > 551 User not local; please try > 552 Requested mail action aborted: exceeded storage allocation > 553 Requested action not taken: mailbox name not allowed > [E.g., mailbox syntax incorrect] > 554 Transaction failed > > But then continues to say: > > MAIL > S: 250 > F: 552, 451, 452 > E: 500, 501, 421 > RCPT > S: 250, 251 > F: 550, 551, 552, 553, 450, 451, 452 > E: 500, 501, 503, 421 > > (I.e. you can toss a 553 on the RCPT TO, but not on a MAIL FROM). > > RFC1123 then muddies things up more: > > 5.2.10 SMTP Replies: RFC-821 Section 4.2 > > A receiver-SMTP SHOULD send only the reply codes listed in > section 4.2.2 of RFC-821 or in this document. A receiver-SMTP > SHOULD use the text shown in examples in RFC-821 whenever > appropriate. > > A sender-SMTP MUST determine its actions only by the reply > code, not by the text (except for 251 and 551 replies); any > text, including no text at all, must be acceptable. The space > (blank) following the reply code is considered part of the > text. Whenever possible, a sender-SMTP SHOULD test only the > first digit of the reply code, as specified in Appendix E of > RFC-821. > > DISCUSSION: > Interoperability problems have arisen with SMTP systems > using reply codes that are not listed explicitly in RFC- > 821 Section 4.3 but are legal according to the theory of > reply codes explained in Appendix E. > > So, is it legal/permissible/suggested to 553 on a MAIL FROM that can be > determined to be syntactically invalid? > -- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature From owner-ietf-smtp Tue Jul 18 21:06:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA29233 for ietf-smtp-bks; Tue, 18 Jul 2000 21:06:56 -0700 (PDT) Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29219 for ; Tue, 18 Jul 2000 21:06:50 -0700 (PDT) Received: from dhcp-033209.tc-conference.inet2000.gr.jp ([133.195.33.209]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JRXJHAYTMI9N44ES@shoe.reston.mci.net> for ietf-smtp@imc.org; Wed, 19 Jul 2000 00:09:08 EST Date: Wed, 19 Jul 2000 00:07:40 -0400 From: John C Klensin Subject: Re: mail-abuse.org tests, and weird addresses... In-reply-to: <200007181832.e6IIWUY25908@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org, drums@cs.utk.edu Message-id: <1892586626.963965260@dhcp-033209.tc-conference.inet2000.gr.jp> MIME-version: 1.0 X-Mailer: Mulberry/2.0.3 (Win32) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, July 18, 2000 2:32 PM -0400 Valdis.Kletnieks@vt.edu wrote: > (Am cc'ing the IETF-SMTP list, hopefully it's alive and > somebody there will have guidance on this... For the IETF-SMTP > list, the discussion is what to properly do if handed this > during an SMTP transaction: > > MAIL FROM: > > Sendmail currently issues a '250 OK'. >... [more of original message below]... Hi. If my memory is correct, 501 (syntax error) is intended, as was the exclusion of 553 from the MAIL FROM responses. I agree that the 1123 text is a little muddy (and it is probably at least partially my fault). Please take a look at draft-ietf-drums-smtpupd-12.txt and see if you think it is clear and good enough; if not, comments should probably go to the DRUMS list (copied on this response). I would think that 553 would be used for a situation in which, e.g., the left-hand-side (local-part) of an address was valid syntax in 821 (etc) terms, but invalid for processing/ delivery on the target host while 501 would be used for things that were lexically unacceptable given the 821 grammar. If that were the theory, then a receiving SMTP wouldn't be able to comment on the sender's local part (in MAIL FROM) as long as it obeyed the 821 syntax. But, again, a receiving host could evaluate a local-part syntax against its own rules. For example, assume my host receives RCPT TO: Almost no one has mailbox names that look like that, so bouncing it with a 553 would be reasonable. Bouncing it with 501 would be less so, since the syntax, is I believe, 821-valid. On the other hand, the example given below is invalid everywhere in 821 systems. john > On Tue, 18 Jul 2000 10:46:13 PDT, Kyle Jones > said: >> The attitude I took when I ran a relaying server was that stuff >> like a@b@c was better off bounced immediately. > > I can deal with that attitude. > > However, RFC821 also lists the following codes on page 56: > > 550 Requested action not taken: mailbox unavailable > [E.g., mailbox not found, no access] > 551 User not local; please try > 552 Requested mail action aborted: exceeded storage > allocation 553 Requested action not taken: mailbox > name not allowed [E.g., mailbox syntax incorrect] > 554 Transaction failed > > But then continues to say: > > MAIL > S: 250 > F: 552, 451, 452 > E: 500, 501, 421 > RCPT > S: 250, 251 > F: 550, 551, 552, 553, 450, 451, 452 > E: 500, 501, 503, 421 > > (I.e. you can toss a 553 on the RCPT TO, but not on a MAIL > FROM). > > RFC1123 then muddies things up more: > > 5.2.10 SMTP Replies: RFC-821 Section 4.2 > > A receiver-SMTP SHOULD send only the reply codes > listed in section 4.2.2 of RFC-821 or in this > document. A receiver-SMTP SHOULD use the text shown > in examples in RFC-821 whenever appropriate. > > A sender-SMTP MUST determine its actions only by the > reply code, not by the text (except for 251 and 551 > replies); any text, including no text at all, must be > acceptable. The space (blank) following the reply > code is considered part of the text. Whenever > possible, a sender-SMTP SHOULD test only the first > digit of the reply code, as specified in Appendix E of > RFC-821. > > DISCUSSION: > Interoperability problems have arisen with SMTP > systems using reply codes that are not listed > explicitly in RFC- 821 Section 4.3 but are legal > according to the theory of reply codes explained > in Appendix E. > > > So, is it legal/permissible/suggested to 553 on a MAIL FROM > that can be determined to be syntactically invalid? > -- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech > > > From owner-ietf-smtp Wed Jul 19 11:17:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19301 for ietf-smtp-bks; Wed, 19 Jul 2000 11:17:30 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19297 for ; Wed, 19 Jul 2000 11:17:28 -0700 (PDT) Received: from Software.com ([207.175.94.135]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000719182035.PKNB459995.mta1biz.bizmailsrvcs.net@Software.com>; Wed, 19 Jul 2000 13:20:35 -0500 Message-ID: <3975E06A.41386027@Software.com> Date: Wed, 19 Jul 2000 10:07:54 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Valdis.Kletnieks@vt.edu CC: Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... References: <200007181611.e6IGBYY27902@black-ice.cc.vt.edu> <14708.33409.447058.273936@horsey.gshapiro.net> <14708.38885.95422.69372@ice.wonderworks.com> <200007181832.e6IIWUY25908@black-ice.cc.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Valdis.Kletnieks@vt.edu wrote: > > (Am cc'ing the IETF-SMTP list, hopefully it's alive and somebody there > will have guidance on this... For the IETF-SMTP list, the discussion is > what to properly do if handed this during an SMTP transaction: > > MAIL FROM: > > Sendmail currently issues a '250 OK'. I think it is a valid address. It was manually routed from one domain to another. I used that feature a few years ago to stop spam as a result of people scanning net-news postings. (I posted with x@y@z). Any email that came to that address at domain 'y' would get extra filters before relaying to domain 'z'. It is another way of doing mail relaying. I did an exhaustive search a few years ago. The ability to route with multiple '@' was in an RFC, so it is valid. (If it has not been superseded). Set mail relay to off, if you can. (I don't know the exact keyword). It should stop working. -Doug From owner-ietf-smtp Wed Jul 19 12:20:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA20872 for ietf-smtp-bks; Wed, 19 Jul 2000 12:20:04 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20867 for ; Wed, 19 Jul 2000 12:20:01 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA27723; Wed, 19 Jul 2000 15:22:24 -0400 (EDT) Message-Id: <200007191922.PAA27723@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Doug Royer cc: Valdis.Kletnieks@vt.edu, Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... In-reply-to: Your message of "Wed, 19 Jul 2000 10:07:54 PDT." <3975E06A.41386027@Software.com> Date: Wed, 19 Jul 2000 15:22:24 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > MAIL FROM: > > > > Sendmail currently issues a '250 OK'. > > I think it is a valid address. it is invalid syntax in both RFC821 or RFC822. Keith From owner-ietf-smtp Wed Jul 19 13:30:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22256 for ietf-smtp-bks; Wed, 19 Jul 2000 13:30:29 -0700 (PDT) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22252 for ; Wed, 19 Jul 2000 13:30:28 -0700 (PDT) Received: from shell3.ba.best.com (gjw@shell3.ba.best.com [206.184.139.134]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id NAA27900; Wed, 19 Jul 2000 13:32:25 -0700 (PDT) Date: Wed, 19 Jul 2000 13:32:25 -0700 (PDT) From: "Gregory J. Woodhouse" X-Sender: gjw@shell3.ba.best.com To: Keith Moore cc: Doug Royer , Valdis.Kletnieks@vt.edu, Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... In-Reply-To: <200007191922.PAA27723@astro.cs.utk.edu> Message-ID: X-Url: http://www.wnetc.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's been a long time, but I once had to use the so-called "%-hack" in my e-mail address, but I believe you are correct that user@host1@host2 is incorrect syntax. I'm curious, does sendmail treat this as equivalent to user%host1@host2? On Wed, 19 Jul 2000, Keith Moore wrote: > > > > MAIL FROM: > > > > > > Sendmail currently issues a '250 OK'. > > > > I think it is a valid address. > > it is invalid syntax in both RFC821 or RFC822. > > Keith > --- Gregory Woodhouse gjw@wnetc.com / http://www.wnetc.com/home.html "An atheist staring from his attic window is often nearer to God than the believer caught up in his own false image of God." --Martin Buber From owner-ietf-smtp Wed Jul 19 13:35:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA22374 for ietf-smtp-bks; Wed, 19 Jul 2000 13:35:29 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22370 for ; Wed, 19 Jul 2000 13:35:27 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.0.Gamma1/8.11.0.Gamma1) id e6JKbvH79951; Wed, 19 Jul 2000 13:37:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14710.4517.40253.709711@horsey.gshapiro.net> Date: Wed, 19 Jul 2000 13:37:57 -0700 (PDT) From: Gregory Neil Shapiro To: "Gregory J. Woodhouse" Cc: Keith Moore , Doug Royer , Valdis.Kletnieks@vt.edu, Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... In-Reply-To: References: <200007191922.PAA27723@astro.cs.utk.edu> X-Mailer: VM 6.75 under 21.2 (beta34) "Molpe" XEmacs Lucid Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: gjw> It's been a long time, but I once had to use the so-called "%-hack" in my gjw> e-mail address, but I believe you are correct that user@host1@host2 is gjw> incorrect syntax. I'm curious, does sendmail treat this as equivalent to gjw> user%host1@host2? Yes. From owner-ietf-smtp Wed Jul 19 14:31:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA22969 for ietf-smtp-bks; Wed, 19 Jul 2000 14:31:30 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22965 for ; Wed, 19 Jul 2000 14:31:28 -0700 (PDT) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.11.0.Beta4/8.11.0.Beta4) with ESMTP id e6JLXvY27914; Wed, 19 Jul 2000 17:33:58 -0400 Message-Id: <200007192133.e6JLXvY27914@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: John C Klensin Cc: ietf-smtp@imc.org, drums@cs.utk.edu Subject: Re: mail-abuse.org tests, and weird addresses... In-Reply-To: Your message of "Wed, 19 Jul 2000 00:07:40 EDT." <1892586626.963965260@dhcp-033209.tc-conference.inet2000.gr.jp> 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_-1278297722P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 19 Jul 2000 17:33:57 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1278297722P Content-Type: text/plain; charset=us-ascii On Wed, 19 Jul 2000 00:07:40 EDT, John C Klensin said: > If my memory is correct, 501 (syntax error) is intended, as was > the exclusion of 553 from the MAIL FROM responses. I agree that > the 1123 text is a little muddy (and it is probably at least > partially my fault). Please take a look at > draft-ietf-drums-smtpupd-12.txt and see if you think it is clear > and good enough; if not, comments should probably go to the DRUMS > list (copied on this response). Yes, 501 *is* the correct error, and your example of an embedded blank getting a 553 was better. smtpupd section 4.3.2 specifically allows any/all of 501, 550, and 553 on the MAIL FROM: which gives future releases of Sendmail sufficient room to work. That text looks good and reasonable. Is there a target date for smtpupd to move out of Draft status and into RFC, where it will be more cite-able without being a moving target? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1278297722P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOXYexXAt5Vm009ewEQLWbwCg69YWHLzqGz7i1q/f7FT7sfSFIvsAn1W8 ersZb5lwY8niPvwREAIwmQRN =uxR1 -----END PGP SIGNATURE----- --==_Exmh_-1278297722P-- From owner-ietf-smtp Wed Jul 19 16:06:02 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00978 for ietf-smtp-bks; Wed, 19 Jul 2000 16:06:02 -0700 (PDT) Received: from htl_fs1.halkin-tool.com (fat-static187.fatwire.net [207.194.170.187]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00973 for ; Wed, 19 Jul 2000 16:06:01 -0700 (PDT) Received: from SOEGIH by htl_fs1.halkin-tool.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id PFNXG7RB; Wed, 19 Jul 2000 14:03:22 -0700 Message-ID: <000e01bff1c6$028d0c40$23c102cb@soegih> From: "Soegi Hartono" To: "Gregory J. Woodhouse" , "Keith Moore" Cc: "Doug Royer" , , "Kyle Jones" , , Subject: Re: mail-abuse.org tests, and weird addresses... Date: Wed, 19 Jul 2000 14:12:05 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've tried to send e-mail like this syntax user%host1@host2, it successfully sent but it's not getting to the final destination, anyone know? -----Original Message----- From: Gregory J. Woodhouse To: Keith Moore Cc: Doug Royer ; Valdis.Kletnieks@vt.edu ; Kyle Jones ; sendmail-beta@Sendmail.ORG ; ietf-smtp@imc.org Date: Wednesday, July 19, 2000 1:40 PM Subject: Re: mail-abuse.org tests, and weird addresses... It's been a long time, but I once had to use the so-called "%-hack" in my e-mail address, but I believe you are correct that user@host1@host2 is incorrect syntax. I'm curious, does sendmail treat this as equivalent to user%host1@host2? On Wed, 19 Jul 2000, Keith Moore wrote: > > > > MAIL FROM: > > > > > > Sendmail currently issues a '250 OK'. > > > > I think it is a valid address. > > it is invalid syntax in both RFC821 or RFC822. > > Keith > --- Gregory Woodhouse gjw@wnetc.com / http://www.wnetc.com/home.html "An atheist staring from his attic window is often nearer to God than the believer caught up in his own false image of God." --Martin Buber From owner-ietf-smtp Wed Jul 19 19:46:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA18454 for ietf-smtp-bks; Wed, 19 Jul 2000 19:46:33 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA18448 for ; Wed, 19 Jul 2000 19:46:32 -0700 (PDT) Received: from Software.com ([207.175.94.135]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000720024946.QBTH459995.mta1biz.bizmailsrvcs.net@Software.com>; Wed, 19 Jul 2000 21:49:46 -0500 Message-ID: <397657BB.65C2A272@Software.com> Date: Wed, 19 Jul 2000 18:36:59 -0700 From: Doug Royer Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Valdis.Kletnieks@vt.edu, Kyle Jones , sendmail-beta@Sendmail.ORG, ietf-smtp@imc.org Subject: Re: mail-abuse.org tests, and weird addresses... References: <200007191922.PAA27723@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > > > > > MAIL FROM: > > > > > > Sendmail currently issues a '250 OK'. > > > > I think it is a valid address. > > it is invalid syntax in both RFC821 or RFC822. > > Keith Yep -Oh well - the older I get the more I think that gray hair is brain cells leaking :-) -Doug From owner-ietf-smtp Thu Jul 20 09:56:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03138 for ietf-smtp-bks; Thu, 20 Jul 2000 09:56:31 -0700 (PDT) Received: from vienna1-mail-relay1.bbnplanet.com (cpk-mail-relay1.bbnplanet.com [192.239.16.198]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03133 for ; Thu, 20 Jul 2000 09:56:27 -0700 (PDT) Received: from deptvass2-cp.va.gov (deptvass2-cp.va.gov [205.128.215.121]) by vienna1-mail-relay1.bbnplanet.com (Postfix) with SMTP id 6F2734FE3F; Thu, 20 Jul 2000 16:58:27 +0000 (GMT) Received: from 152.129.1.70 by vhaishmul4 (InterScan E-Mail VirusWall NT); Thu, 20 Jul 2000 12:04:14 -0500 (Central Daylight Time) Received: by VHAISHHBEXC4 with Internet Mail Service (5.5.2650.21) id <3ZK0AWXF>; Thu, 20 Jul 2000 12:01:52 -0500 Message-ID: <03F40A4BFEFAD111B55E0000F81E4FB1603837@VHAISFEXC1> From: "Woodhouse, Gregory J." To: "'Valdis.Kletnieks@vt.edu'" , John C Klensin Cc: ietf-smtp@imc.org Subject: RE: mail-abuse.org tests, and weird addresses... Date: Thu, 20 Jul 2000 11:58:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe it's in last call now. === Gregory Woodhouse Financial Product Line +1 415 744 6362 "Computer science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, July 19, 2000 2:34 PM To: John C Klensin Cc: ietf-smtp@imc.org; drums@cs.utk.edu Subject: Re: mail-abuse.org tests, and weird addresses... On Wed, 19 Jul 2000 00:07:40 EDT, John C Klensin said: > If my memory is correct, 501 (syntax error) is intended, as was > the exclusion of 553 from the MAIL FROM responses. I agree that > the 1123 text is a little muddy (and it is probably at least > partially my fault). Please take a look at > draft-ietf-drums-smtpupd-12.txt and see if you think it is clear > and good enough; if not, comments should probably go to the DRUMS > list (copied on this response). Yes, 501 *is* the correct error, and your example of an embedded blank getting a 553 was better. smtpupd section 4.3.2 specifically allows any/all of 501, 550, and 553 on the MAIL FROM: which gives future releases of Sendmail sufficient room to work. That text looks good and reasonable. Is there a target date for smtpupd to move out of Draft status and into RFC, where it will be more cite-able without being a moving target? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech From owner-ietf-smtp Mon Aug 14 01:11:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03683 for ietf-smtp-bks; Mon, 14 Aug 2000 01:11:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA03679 for ; Mon, 14 Aug 2000 01:11:34 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JSXRXZ0O0G0000BU@mauve.mrochek.com> for ietf-smtp@imc.org; Mon, 14 Aug 2000 01:11:11 -0700 (PDT) Date: Mon, 14 Aug 2000 01:07:11 -0700 (PDT) Subject: Review needed To: ietf-smtp@imc.org Message-id: <01JSXX8DSO9G0000BU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has been asked to consider draft-ward-esmtp-slide-03.txt, "SMTP Service Extension for Slightly Differing Multicast Messages (SLIDE)", for publication as an experimental protocol. Since this document describes a SMTP extension of some complexity I'd like to get some community feedback on it. Comments can be sent to the list or directly to Patrik (paf@cisco.com) and myself (ned.freed@innosoft.com). Thanks. Ned From owner-ietf-smtp Mon Aug 14 05:57:08 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10547 for ietf-smtp-bks; Mon, 14 Aug 2000 05:57:08 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10543 for ; Mon, 14 Aug 2000 05:57:07 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id IAA06853; Mon, 14 Aug 2000 08:56:36 -0400 (EDT) Message-Id: <200008141256.IAA06853@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@innosoft.com, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: ietf-smtp@imc.org Subject: Re: Review needed In-reply-to: Your message of "Mon, 14 Aug 2000 01:07:11 PDT." <01JSXX8DSO9G0000BU@mauve.mrochek.com> Date: Mon, 14 Aug 2000 08:56:36 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: on SLIDE: it's potentially useful, but difficult to use. I suspect it's difficult to implement on any platform which does not store messages exactly as they are transmitted on the wire, such implementations would be likely to have errors and the errors would be likely to produce corrupt messages and/or messages which contained data not intended for the recipient. using byte counts on MIME messages doesn't seem like the optimal strategy. explicit markers in the message might be better. it needs more discussion of relaying - in particular the need to adjust byte counts due to received headers being added. SLIDERANGE parameters could easily get very long, but there is no advice about how long they should be able to be. presumably SLIDE would work with BINARYMIME also - document should probably discuss that. arguably SLIDE should only be used with BDAT, since an implementation pretty much has to meet the storage transparency requirements of BINARYMIME in order to implement SLIDE correctly. under ordinary circumstances the document would be okay for experimental. however SMTP extensions have a somewhat higher bar - we need to believe that they will not be harmful if deployed. I am uncomfortable with the idea that buggy implementations of SLIDE might end up in popular MTAs and that SLIDE would be automatically used if present in EHLO. suggestions: either don't publish, or (more likely) publish with some additional restrictions: - the document needs to be absolutely clear that only messages originated with SLIDERANGEs can be relayed with SLIDERANGEs, and those SLIDERANGEs have to correspond to the ranges chosen by the originator. (e.g. MTAs shouldn't use SLIDERANGE to relay messages to several recipients with a slightly different Received field for each recipient...even though that would be quite useful...because it would trigger buggy implementations.) - SLIDE should not be enabled by default; MTAs should need explicit configuration before advertising SLIDE or acccepting SLIDERANGE parameters. From owner-ietf-smtp Mon Aug 14 08:22:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15960 for ietf-smtp-bks; Mon, 14 Aug 2000 08:22:53 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15945 for ; Mon, 14 Aug 2000 08:22:49 -0700 (PDT) Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-450.cisco.com [144.254.47.198]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id RAA13138; Mon, 14 Aug 2000 17:22:23 +0200 Message-Id: <4.3.2.7.2.20000814153133.04db8258@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Aug 2000 15:38:49 +0200 To: ned.freed@innosoft.com, ietf-smtp@imc.org From: Harald Alvestrand Subject: Re: Review needed In-Reply-To: <01JSXX8DSO9G0000BU@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:07 14/08/2000 -0700, ned.freed@innosoft.com wrote: >The IESG has been asked to consider draft-ward-esmtp-slide-03.txt, "SMTP >Service Extension for Slightly Differing Multicast Messages (SLIDE)", for >publication as an experimental protocol. Since this document describes a >SMTP extension of some complexity I'd like to get some community >feedback on it. If we can kill it, I would recommend doing so. The proposal allows us an almost infinite amount of nonsense, including sending signed messages in one transaction with some copies that verify and some that don't, sending messages with different Received: lines, and so on and so forth. Note also that it fails to respect any kind of envelope/header/body separation; the SLIDERANGEs can point anywhere, including at the header/body boundary. So this is legal: From: a < range for B starts here To: b You know, I sent this message: From: a < range for C starts here To: c I fail completely to see that the percieved bandwidth reduction is anywhere near being a payback for the added complexity. If bandwidth is an issue, a GZIP SMTP extension makes much more sense, and saves much more bandwidth, without destroying the SMTP model of header/body separation (what's left of it). If it was a separate protocol, not an SMTP thingy, it could be left to die on its own. As it is, it does not have my approval. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-smtp Mon Aug 14 19:15:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07202 for ietf-smtp-bks; Mon, 14 Aug 2000 19:15:50 -0700 (PDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07197 for ; Mon, 14 Aug 2000 19:15:49 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id WAA21266 for ; Mon, 14 Aug 2000 22:15:01 -0400 (EDT) Received: from att.com ([135.197.86.161]) by maillennium.att.com (labmail) with SMTP id <20000815021245099001nvrue> (Authid: tony@maillennium.att.com); Tue, 15 Aug 2000 02:12:46 +0000 Message-ID: <3998A53D.971900F3@att.com> Date: Mon, 14 Aug 2000 22:04:45 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ned.freed@innosoft.com CC: ietf-smtp@imc.org Subject: Re: Review needed References: <01JSXX8DSO9G0000BU@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ned.freed@innosoft.com wrote: > > The IESG has been asked to consider draft-ward-esmtp-slide-03.txt, "SMTP > Service Extension for Slightly Differing Multicast Messages (SLIDE)", for > publication as an experimental protocol. Since this document describes a > SMTP extension of some complexity I'd like to get some community > feedback on it. > > Comments can be sent to the list or directly to Patrik (paf@cisco.com) > and myself (ned.freed@innosoft.com). When I read it, I thought it was way too complex for the little it offered. It didn't look like anything we'd want to implement. Tony Hansen tony@att.com From owner-ietf-smtp Mon Aug 14 19:52:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA11261 for ietf-smtp-bks; Mon, 14 Aug 2000 19:52:56 -0700 (PDT) Received: from home.royer.com (home.royer.com [12.44.115.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11256 for ; Mon, 14 Aug 2000 19:52:54 -0700 (PDT) Received: from home.royer.com ([192.168.168.10]) by home.royer.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Mon, 14 Aug 2000 19:52:35 -0700 Message-ID: <3998B073.7E819282@home.royer.com> Date: Mon, 14 Aug 2000 19:52:35 -0700 From: Doug Royer Reply-To: ietf-smtp@imc.org X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: Review needed References: <01JSXX8DSO9G0000BU@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > The IESG has been asked to consider draft-ward-esmtp-slide-03.txt, "SMTP > Service Extension for Slightly Differing Multicast Messages (SLIDE)", for > publication as an experimental protocol. Since this document describes a > SMTP extension of some complexity I'd like to get some community > feedback on it. It looks to me like a protocol for bulk email clients to send spam to a larger number of recipients with a lesser amount of chattiness. Or at the very least a way for bulk email clients to offload their data processing to the MX host that might not want to do this workload. As in: Dear ... rest of junk mail common to all... If I am right - please let this fade away. Is there any other purpose? Bandwidth reduction - yea. But it does not make that much difference until there is a large recipient list. And what kind of client besides bulk email clients would generate this kind of email? -Doug From owner-ietf-smtp Mon Aug 14 20:53:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA16134 for ietf-smtp-bks; Mon, 14 Aug 2000 20:53:19 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16126 for ; Mon, 14 Aug 2000 20:53:17 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA28515 for ; Mon, 14 Aug 2000 23:53:00 -0400 (EDT) Message-Id: <200008150353.XAA28515@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ietf-smtp@imc.org Subject: Re: Review needed In-reply-to: Your message of "Mon, 14 Aug 2000 19:52:35 PDT." <3998B073.7E819282@home.royer.com> X-SUBJECT-MSG-FROM: Doug Royer Date: Mon, 14 Aug 2000 23:53:00 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > And what kind of client besides bulk email clients would generate > this kind of email? well, any client that sent large but slightly differing messages to different recipients, over slow links. you could optimize bcc handling, for instance, by sending the message to the primary recipients and the bcc recipients in a single DATA command. but yes, it seems like the sort of thing that would mostly benefit spammers. Keith From owner-ietf-smtp Tue Aug 15 06:29:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA22400 for ietf-smtp-bks; Tue, 15 Aug 2000 06:29:28 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22395 for ; Tue, 15 Aug 2000 06:29:27 -0700 (PDT) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (localhost) by black-ice.cc.vt.edu (8.12.0.PreAlpha0/8.12.0.PreAlpha0) with ESMTP id e7FDTAa26824; Tue, 15 Aug 2000 09:29:10 -0400 Message-Id: <200008151329.e7FDTAa26824@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Keith Moore Cc: ietf-smtp@imc.org Subject: Re: Review needed In-Reply-To: Your message of "Mon, 14 Aug 2000 23:53:00 EDT." <200008150353.XAA28515@astro.cs.utk.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_-229565188P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 15 Aug 2000 09:29:09 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-229565188P Content-Type: text/plain; charset=us-ascii On Mon, 14 Aug 2000 23:53:00 EDT, Keith Moore said: > but yes, it seems like the sort of thing that would mostly benefit > spammers. Or any mailing-list-management software, like the stuff that runs at imc.org to run the ietf-smtp mailing list. Virginia Tech runs a rather large Listserv site (one of the top 10 in the world based on numbers of lists), and there's a large number of things that Listserv currently can't do very well due to the requirement that you either have to send one identical message to *all* the recipients, or go through an entire MAIL FROM/RCPT TO for each individual recipient. Just yesterday on the Listserv Manager's mailing list, there was a request to be able to add a footer to each mail (which Listserv supports), but have it contain the address the recipient was subscribed from (which can't be done due to the identical-message issue). If Listserv were able to send out an *almost* identical message to all the receivers, but be able to stash something unique in the message body or RFC822 headers for each recipient, it would make debugging things like "I can't unsubscribe because my old address is forwarded tomy new one and I can't REMEMBER my old one" a lot easier to debug". And we get a lot more of those problems than you'd believe., This note is to be taken as support of the *CONCEPT* of slightly differing messages - I have *NOT* read the draft yet, and am NOT saying it's a good implementation. I'll be reading the draft hopefully later today.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-229565188P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOZlFpXAt5Vm009ewEQL4LACfUZtYR/IBJD92aAtR8hgteERchUcAoKgc tTzxRW+595G6HCjqqivbhFsS =Ewq3 -----END PGP SIGNATURE----- --==_Exmh_-229565188P-- From owner-ietf-smtp Tue Aug 15 06:25:58 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA22221 for ietf-smtp-bks; Tue, 15 Aug 2000 06:25:58 -0700 (PDT) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22217 for ; Tue, 15 Aug 2000 06:25:56 -0700 (PDT) Received: from ieca.com (mva-aa-066.capu.net [207.226.159.66]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA06212; Tue, 15 Aug 2000 09:25:38 -0400 Message-ID: <399944CC.43D31AA1@ieca.com> Date: Tue, 15 Aug 2000 09:25:32 -0400 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ned.freed@innosoft.com CC: ietf-smtp@imc.org, paf@Cisco.COM Subject: Re: Review needed References: <01JSXX8DSO9G0000BU@mauve.mrochek.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6A1DCB031C471B53A3FE0045" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms6A1DCB031C471B53A3FE0045 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I can see a legitimate argument for this sort of thing. In particular, the application for piecewise signing and encryption strike me as potentially a good idea for any mass-mailed encrypted material. However, there might be better and more tailored ways to accomplish this (like maybe as a security RFC). SLIDE does not sound difficult to implement from the server side, but I suspect that its use would have a very negative impact on server performance when network multicasting cannot be accomplished for all recipients. Maybe this is okay if we're only talking about a special multicasting class of mail server. I would not like to design the user interface for the client, though. ;-) I did not like the following sentence wrt the increased length of RCPT TO command lines. > Of course, since the value could conceivably be longer than > 256 characters, implementations are welcome to allot more space for > this purpose. This seems like it would encourage products with different capacities that could not be easily negotiated in EHLO. Some additional language is necessary in 3.2 concerning "message trimming". This sounds like it might cover support for relaying to recipients not accessable via a multicast group, however, the overall scenario for relaying is not described. There should be a description of what happens in the multicast case, and what happens if the message must be relayed to a non-multicast non-slide capable host. I think the concern about this benefiting spammers is a little overblown. I do not see anything in this draft that would cause any of the existing or planned anti-spam techniques to be circumvented. Neither does it seem likely that a spam outfit would be able to use this service extension to much positive effect. Without network multicasting to EVERY recipient host this merely shifts the load from their special purpose client to their special purpose server. Trying this out on a larger scale seems like the only way to gain some experience in how such a service extension might be used. We have comparatively little experience with multicast applications in the IETF to be making calls on the "value" of the extension. I wouldn't have any problem with this going forward as an *experimental* RFC. Chris bonattic@ieca.com _____________________ ned.freed@innosoft.com wrote: > The IESG has been asked to consider draft-ward-esmtp-slide-03.txt, "SMTP > Service Extension for Slightly Differing Multicast Messages (SLIDE)", for > publication as an experimental protocol. Since this document describes a > SMTP extension of some complexity I'd like to get some community > feedback on it. > > Comments can be sent to the list or directly to Patrik (paf@cisco.com) > and myself (ned.freed@innosoft.com). > > Thanks. > > Ned --------------ms6A1DCB031C471B53A3FE0045 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ7AYJKoZIhvcNAQcCoIIJ3TCCCdkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B+4wggS4MIIEIaADAgECAhACOZkTH5mWlYOiMWNS0NA/MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTIzMTAwMDAw MFoXDTAwMTIzMDIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxHDAaBgNVBAMUE0NocmlzdG9waGVyIEJvbmF0dGkxIDAe BgkqhkiG9w0BCQEWEWJvbmF0dGljQGllY2EuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB ANKXlrz4lCtsKxQPevEUJ59yPcZpDmBoZnivM/oJtD1bUq0uUPml8eaZThkLVb3lx5Y3bHMe iZUT86EDSuHBp78CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYL YIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCG SAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2 M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVh YzkzYmNhZmY4YTBiYWU2ZGY1ZDcxMTQ5OWJhMmI4NDRmOWYzZWE0NTA2MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEE BQADgYEAPEGSRUMcSfb9eE0h/Bqqe0Q6h0YgoqFEL7MCsCFC3QOwvgNROksoF2+dJOCnOGum vE3Pg6pyXJC02Qmt0qm2hmg3FLTNy0No9UnVld1NH0oejco+eeSfPO2xY0OFj1GojzeGZGfH hmhB1V43k1Be90B9i/Vn4Tw6UsnhIjg9NgMwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVd r+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1Yt xwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEG MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq hkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5 SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVga STyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAcYwggHCAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhACOZkTH5mWlYOiMWNS 0NA/MAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wMDA4MTUxMzI1MzJaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ KoZIhvcNAQkEMRYEFOcUJ8/GufLlDYUl9McaxpzsMBkCMA0GCSqGSIb3DQEBAQUABEAeGy9F FWVF5p7mk9mnxpzkcsneG9JE7qgmy90+8Y3w2gLXieptigrqoRIFw/fIgwCjALYOeY5LOdG7 dcGUNcgT --------------ms6A1DCB031C471B53A3FE0045-- From owner-ietf-smtp Tue Aug 15 07:43:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26760 for ietf-smtp-bks; Tue, 15 Aug 2000 07:43:03 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26756 for ; Tue, 15 Aug 2000 07:43:01 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA03066; Tue, 15 Aug 2000 10:42:44 -0400 (EDT) Message-Id: <200008151442.KAA03066@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bonatti, Chris" cc: ned.freed@innosoft.com, ietf-smtp@imc.org, paf@Cisco.COM Subject: Re: Review needed In-reply-to: Your message of "Tue, 15 Aug 2000 09:25:32 EDT." <399944CC.43D31AA1@ieca.com> Date: Tue, 15 Aug 2000 10:42:44 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think the concern about this benefiting spammers is a little overblown. I > do not see anything in this draft that would cause any of the existing or > planned anti-spam techniques to be circumvented. Neither does it seem likely > that a spam outfit would be able to use this service extension to much > positive effect. uh...if someone complains about a spam, then it's currently quite feasible to search mail queues and message stores for identical messages (after the received lines), and remove them. if every spam is slightly different, this becomes much more difficult. Keith From owner-ietf-smtp Tue Aug 15 08:55:55 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA02003 for ietf-smtp-bks; Tue, 15 Aug 2000 08:55:55 -0700 (PDT) Received: from smtp-a.capu.net (IDENT:0@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01996 for ; Tue, 15 Aug 2000 08:55:53 -0700 (PDT) Received: from ieca.com (mva-aa-034.capu.net [207.226.159.34]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA16510; Tue, 15 Aug 2000 11:55:36 -0400 Message-ID: <399967F2.490BBCBC@ieca.com> Date: Tue, 15 Aug 2000 11:55:30 -0400 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: ned.freed@innosoft.com, ietf-smtp@imc.org, paf@Cisco.COM Subject: Re: Review needed References: <200008151442.KAA03066@astro.cs.utk.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms34499AA50F31DB7D2870FC7E" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms34499AA50F31DB7D2870FC7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit True, but a lot of the spam that I get is tailored anyway, and therefore not identical. I suppose the senders are just using a big custom client to submit a zillion message that start, "Dear Christopher", "Dear Keith", etc. So they've already got a way to do this. Chris _______________ Keith Moore wrote: > > I think the concern about this benefiting spammers is a little overblown. I > > do not see anything in this draft that would cause any of the existing or > > planned anti-spam techniques to be circumvented. Neither does it seem likely > > that a spam outfit would be able to use this service extension to much > > positive effect. > > uh...if someone complains about a spam, then it's currently quite feasible > to search mail queues and message stores for identical messages (after the > received lines), and remove them. if every spam is slightly different, > this becomes much more difficult. > > Keith --------------ms34499AA50F31DB7D2870FC7E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ7AYJKoZIhvcNAQcCoIIJ3TCCCdkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B+4wggS4MIIEIaADAgECAhACOZkTH5mWlYOiMWNS0NA/MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTIzMTAwMDAw MFoXDTAwMTIzMDIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxHDAaBgNVBAMUE0NocmlzdG9waGVyIEJvbmF0dGkxIDAe BgkqhkiG9w0BCQEWEWJvbmF0dGljQGllY2EuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB ANKXlrz4lCtsKxQPevEUJ59yPcZpDmBoZnivM/oJtD1bUq0uUPml8eaZThkLVb3lx5Y3bHMe iZUT86EDSuHBp78CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYL YIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9D UFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCG SAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2 M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVkM2YyMTQxYmVh YzkzYmNhZmY4YTBiYWU2ZGY1ZDcxMTQ5OWJhMmI4NDRmOWYzZWE0NTA2MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEE BQADgYEAPEGSRUMcSfb9eE0h/Bqqe0Q6h0YgoqFEL7MCsCFC3QOwvgNROksoF2+dJOCnOGum vE3Pg6pyXJC02Qmt0qm2hmg3FLTNy0No9UnVld1NH0oejco+eeSfPO2xY0OFj1GojzeGZGfH hmhB1V43k1Be90B9i/Vn4Tw6UsnhIjg9NgMwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVd r+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNV BAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJ QUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBT dWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1Yt xwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zG mo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEG MEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkq hkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5 SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVga STyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAcYwggHCAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhACOZkTH5mWlYOiMWNS 0NA/MAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wMDA4MTUxNTU1MzBaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJ KoZIhvcNAQkEMRYEFG0DI2IdAOkzSBxr1HLAy8hMyvHEMA0GCSqGSIb3DQEBAQUABECNSpCl agJK50BhvQnLzK48LgQVkeH9huC4++xj/F8udSjycssM4Pgc3wtjoyGPfjKN/QhD9tGrXWyi eYYsXeYb --------------ms34499AA50F31DB7D2870FC7E-- From owner-ietf-smtp Tue Aug 15 10:45:11 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08252 for ietf-smtp-bks; Tue, 15 Aug 2000 10:45:11 -0700 (PDT) Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08248 for ; Tue, 15 Aug 2000 10:45:10 -0700 (PDT) Received: from Software.com ([207.175.94.179]) by mta1biz.bizmailsrvcs.net with ESMTP id <20000815174601.WMVY459995.mta1biz.bizmailsrvcs.net@Software.com> for ; Tue, 15 Aug 2000 12:46:01 -0500 Message-ID: <39997086.1EC75C53@Software.com> Date: Tue, 15 Aug 2000 09:32:06 -0700 From: Doug Royer Reply-To: ietf-smtp@imc.org Organization: Software.com X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: Review needed References: <200008151442.KAA03066@astro.cs.utk.edu> <399967F2.490BBCBC@ieca.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Bonatti, Chris" wrote: > > True, but a lot of the spam that I get is tailored anyway, and therefore not > identical. I suppose the senders are just using a big custom client to submit a > zillion message that start, "Dear Christopher", "Dear Keith", etc. So they've > already got a way to do this. Yes - but if you are saying, so let anyone do it this new way... The spammer currently consume the CPU cycles to do the distribution. If this were to go past experimental, each MTA would assume that load. Many MTAs have configuration parameters that allow them to limit the number of connections per sender. (Site X can not send more than Y number of email's per day). I personally have never had a need to do this kind of thing. But perhaps there is a reason for this kind of thing. -Doug From owner-ietf-smtp Tue Aug 15 11:13:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA09831 for ietf-smtp-bks; Tue, 15 Aug 2000 11:13:27 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09826 for ; Tue, 15 Aug 2000 11:13:25 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA18615 for ; Tue, 15 Aug 2000 14:13:12 -0400 (EDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA18610 for ; Tue, 15 Aug 2000 14:13:12 -0400 (EDT) Received: from buzz.ons.octel.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id NAA29873 for ; Tue, 15 Aug 2000 13:13:07 -0500 (CDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id NAA21778 for ; Tue, 15 Aug 2000 13:13:09 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 13:08:34 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F41337040510D2@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: ietf-smtp@imc.org Subject: RE: Review needed Date: Tue, 15 Aug 2000 13:08:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I see insufficient value for this extension between mail domains or across the general Internet to justify the risk to the infrastructure. However, this extension appears well suited for mail submission. It provides a way for a ligher-weight client to submit a raft of message to a submission server that can then assume value-added post-processing responsiblities. The extension off-loads an enormous amount of traffic to a presumably better-connected, specialized mail server from a less well connected client. As such, the extension would be useful to standardize even if explicitly not recommended for inter-domain use. Use with submission would also address many of the CPU and SPAM concerns raised by others by making the use of the extension subject to the policy of the submission server owner and limiting the extra processing burden to that server. Greg V. From owner-ietf-smtp Tue Aug 15 11:44:22 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA10775 for ietf-smtp-bks; Tue, 15 Aug 2000 11:44:22 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10770 for ; Tue, 15 Aug 2000 11:44:20 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA09848; Tue, 15 Aug 2000 14:43:30 -0400 (EDT) Message-Id: <200008151843.OAA09848@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Vaudreuil, Greg M (Greg)" cc: ietf-smtp@imc.org Subject: Re: Review needed In-reply-to: Your message of "Tue, 15 Aug 2000 13:08:33 CDT." <6B57F36F4FF9D111B30A0008C7F41337040510D2@exdal1.ons.octel.com> Date: Tue, 15 Aug 2000 14:43:30 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wonder...would typical mail clients bother to use this when submitting mail (say for bcc processing) if it were implemented by submission servers? Keith From owner-ietf-smtp Tue Aug 15 11:59:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11089 for ietf-smtp-bks; Tue, 15 Aug 2000 11:59:27 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11085 for ; Tue, 15 Aug 2000 11:59:25 -0700 (PDT) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (localhost) by black-ice.cc.vt.edu (8.12.0.PreAlpha0/8.12.0.PreAlpha0) with ESMTP id e7FIx6a23642; Tue, 15 Aug 2000 14:59:06 -0400 Message-Id: <200008151859.e7FIx6a23642@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: Keith Moore Cc: "Vaudreuil, Greg M (Greg)" , ietf-smtp@imc.org Subject: Re: Review needed In-Reply-To: Your message of "Tue, 15 Aug 2000 14:43:30 EDT." <200008151843.OAA09848@astro.cs.utk.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_915805976P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 15 Aug 2000 14:59:06 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_915805976P Content-Type: text/plain; charset=us-ascii On Tue, 15 Aug 2000 14:43:30 EDT, Keith Moore said: > I wonder...would typical mail clients bother to use this when submitting > mail (say for bcc processing) if it were implemented by submission servers? Typical mail clients probably don't need this. The clients that need it are mailing list processors. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_915805976P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOZmS+XAt5Vm009ewEQJkMACfXPdoLs1T082DWBc2BLB2cBkEoygAnjhD AQCmu1HZMj1EHmDjdNwdPZOF =dEqt -----END PGP SIGNATURE----- --==_Exmh_915805976P-- From owner-ietf-smtp Tue Aug 15 12:04:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11278 for ietf-smtp-bks; Tue, 15 Aug 2000 12:04:00 -0700 (PDT) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11260 for ; Tue, 15 Aug 2000 12:03:55 -0700 (PDT) Received: (qmail 3976 invoked from network); 15 Aug 2000 19:03:32 -0000 Received: from saturn.hosting4u.net (209.15.2.17) by mail-gate.hosting4u.net with SMTP; 15 Aug 2000 19:03:32 -0000 Received: from engws5 ([207.194.170.187]) by saturn.hosting4u.net ; Tue, 15 Aug 2000 14:03:30 -0500 Message-ID: <001801c006ec$233888d0$23c102cb@engws5> From: "Soegi Hartono" To: "Vaudreuil, Greg M \(Greg\)" Cc: References: <6B57F36F4FF9D111B30A0008C7F41337040510D2@exdal1.ons.octel.com> Subject: Re: Review needed Date: Tue, 15 Aug 2000 12:07:59 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Disposition-Notification-To: "Soegi Hartono" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does anyone has any list of smtp syntax (i.e. mail forwarding, header for transcript/receipt, or e-mail tracking etc) thanks Soegi ----- Original Message ----- From: "Vaudreuil, Greg M (Greg)" To: Sent: Tuesday, August 15, 2000 11:08 AM Subject: RE: Review needed I see insufficient value for this extension between mail domains or across the general Internet to justify the risk to the infrastructure. However, this extension appears well suited for mail submission. It provides a way for a ligher-weight client to submit a raft of message to a submission server that can then assume value-added post-processing responsiblities. The extension off-loads an enormous amount of traffic to a presumably better-connected, specialized mail server from a less well connected client. As such, the extension would be useful to standardize even if explicitly not recommended for inter-domain use. Use with submission would also address many of the CPU and SPAM concerns raised by others by making the use of the extension subject to the policy of the submission server owner and limiting the extra processing burden to that server. Greg V. From owner-ietf-smtp Tue Aug 15 12:14:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11731 for ietf-smtp-bks; Tue, 15 Aug 2000 12:14:55 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11727 for ; Tue, 15 Aug 2000 12:14:54 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA10849; Tue, 15 Aug 2000 15:14:35 -0400 (EDT) Message-Id: <200008151914.PAA10849@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Valdis.Kletnieks@vt.edu cc: Keith Moore , "Vaudreuil, Greg M (Greg)" , ietf-smtp@imc.org Subject: Re: Review needed In-reply-to: Your message of "Tue, 15 Aug 2000 14:59:06 EDT." <200008151859.e7FIx6a23642@black-ice.cc.vt.edu> Date: Tue, 15 Aug 2000 15:14:35 -0400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Typical mail clients probably don't need this. that's my guess also, but I'd like to hear from client implementors. From owner-ietf-smtp Tue Aug 15 12:23:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11962 for ietf-smtp-bks; Tue, 15 Aug 2000 12:23:15 -0700 (PDT) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11957 for ; Tue, 15 Aug 2000 12:23:14 -0700 (PDT) Received: (qmail 18783 invoked from network); 15 Aug 2000 19:23:01 -0000 Received: from saturn.hosting4u.net (209.15.2.17) by mail-gate.hosting4u.net with SMTP; 15 Aug 2000 19:23:01 -0000 Received: from engws5 ([207.194.170.187]) by saturn.hosting4u.net ; Tue, 15 Aug 2000 14:22:56 -0500 Message-ID: <001801c006ee$da5a2da0$23c102cb@engws5> From: "Soegi Hartono" To: References: <200008151843.OAA09848@astro.cs.utk.edu> Subject: Re: Review needed Date: Tue, 15 Aug 2000 12:27:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Disposition-Notification-To: "Soegi Hartono" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: was this e-mail meant to be sent to me? thanks ----- Original Message ----- From: "Keith Moore" To: "Vaudreuil, Greg M (Greg)" Cc: Sent: Tuesday, August 15, 2000 11:43 AM Subject: Re: Review needed I wonder...would typical mail clients bother to use this when submitting mail (say for bcc processing) if it were implemented by submission servers? Keith From owner-ietf-smtp Tue Aug 15 12:53:19 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12717 for ietf-smtp-bks; Tue, 15 Aug 2000 12:53:19 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12712 for ; Tue, 15 Aug 2000 12:53:18 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA06487 for ; Tue, 15 Aug 2000 15:53:04 -0400 (EDT) Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA06467; Tue, 15 Aug 2000 15:53:03 -0400 (EDT) Received: from buzz.ons.octel.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr) id PAA12011 for ; Tue, 15 Aug 2000 15:53:02 -0400 (EDT) Received: from txq005ims01.ons.octel.com (exchange [155.184.13.200]) by buzz.ons.octel.com (8.8.8+Sun/8.8.6) with ESMTP id OAA26479; Tue, 15 Aug 2000 14:53:01 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 14:48:26 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F41337040510D4@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: Keith Moore , Valdis.Kletnieks@vt.edu Cc: ietf-smtp@imc.org Subject: RE: Review needed Date: Tue, 15 Aug 2000 14:48:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I can imagine a number of mail-enabled applications that perform polling/voting and wish to send out unique ballot numbers or other identifiers. If would be nice if the sending client application did not have to send each of the many separate messages as part of "submission". Note I use a broader definition of submission than simply supporting end-user thick-weight clients. I classify any useful service on behalf of a sending application (which may be a standard email client) as part of the conceptual submission server. Greg V. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Tuesday, August 15, 2000 2:15 PM To: Valdis.Kletnieks@vt.edu Cc: Keith Moore; Vaudreuil, Greg M (Greg); ietf-smtp@imc.org Subject: Re: Review needed > Typical mail clients probably don't need this. that's my guess also, but I'd like to hear from client implementors. From owner-ietf-smtp Wed Sep 6 09:10:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13950 for ietf-smtp-bks; Wed, 6 Sep 2000 09:10:12 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13944 for ; Wed, 6 Sep 2000 09:10:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: