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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <KXYSQ5PD>; Tue, 15 Aug 2000 14:48:26 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F41337040510D4@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Keith Moore <moore@cs.utk.edu>, 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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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.


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 <ietf-smtp@imc.org>; 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" <sg19305%buzzsaw.com@planeteer.com>
To: <ietf-smtp@imc.org>
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" <sg19305%buzzsaw.com@planeteer.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

was this e-mail meant to be sent to me?

thanks


----- Original Message -----
From: "Keith Moore" <moore@cs.utk.edu>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Cc: <ietf-smtp@imc.org>
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




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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
To: Valdis.Kletnieks@vt.edu
cc: Keith Moore <moore@cs.utk.edu>, "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, 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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

> Typical mail clients probably don't need this.

that's my guess also, but I'd like to hear from client implementors.


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 <ietf-smtp@imc.org>; 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" <sg19305%buzzsaw.com@planeteer.com>
To: "Vaudreuil, Greg M \(Greg\)" <gregv@lucent.com>
Cc: <ietf-smtp@imc.org>
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" <sg19305%buzzsaw.com@planeteer.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

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)" <gregv@lucent.com>
To: <ietf-smtp@imc.org>
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.




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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
Cc: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>, 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[<!v4-0bVIpaxF#-) %9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
References: <200008151843.OAA09848@astro.cs.utk.edu>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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--


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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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


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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; Tue, 15 Aug 2000 13:13:09 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.2448.0) id <KXYSQZB4>; Tue, 15 Aug 2000 13:08:34 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F41337040510D2@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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.


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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <Doug.Royer@software.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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


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 <ietf-smtp@imc.org>; 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" <BonattiC@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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--



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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
To: "Bonatti, Chris" <BonattiC@ieca.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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


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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
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[<!v4-0bVIpaxF#-) %9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
References: <200008150353.XAA28515@astro.cs.utk.edu>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

--==_Exmh_-229565188P
Content-Type: text/plain; charset=us-ascii

On Mon, 14 Aug 2000 23:53:00 EDT, Keith Moore <moore@cs.utk.edu>  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--


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 <ietf-smtp@imc.org>; 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" <BonattiC@ieca.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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--



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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
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 <doug@home.royer.com> 
Date: Mon, 14 Aug 2000 23:53:00 -0400
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

> 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


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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <doug@home.royer.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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 <spammed>

  ... 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


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 <ietf-smtp@imc.org>; 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 <ietf-smtp@imc.org>; 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 <tony@att.com>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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


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 <ietf-smtp@imc.org>; 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 <Harald@Alvestrand.no>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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



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 <ietf-smtp@imc.org>; 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 <moore@cs.utk.edu>
To: ned.freed@innosoft.com, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@Cisco.COM>
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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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.



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 <ietf-smtp@imc.org>; 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: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=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