Subject: RE: Review needed
From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Keith Moore <[email-masked]>, [email-masked]
Cc: [email-masked]
Date: Tue, 15 Aug 2000 14:48:24 -0500
List-Id: <ietf-smtp.imc.org>

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:[email-masked]]
Sent: Tuesday, August 15, 2000 2:15 PM
To: [email-masked]
Cc: Keith Moore; Vaudreuil, Greg M (Greg); [email-masked]
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: "Soegi Hartono" <[email-masked]>
To: <[email-masked]>
Subject: Re: Review needed 
Date: Tue, 15 Aug 2000 12:27:27 -0700
Disposition-Notification-To: "Soegi Hartono" <[email-masked]>
Sender: [email-masked]

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

thanks

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Cc: <[email-masked]>
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: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, "Vaudreuil, Greg M (Greg)" <[email-masked]>, [email-masked]
Subject: Re: Review needed 
Date: Tue, 15 Aug 2000 15:14:35 -0400
Sender: [email-masked]

> Typical mail clients probably don't need this.

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

From: "Soegi Hartono" <[email-masked]>
To: "Vaudreuil, Greg M \(Greg\)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Review needed
Date: Tue, 15 Aug 2000 12:07:59 -0700
Disposition-Notification-To: "Soegi Hartono" <[email-masked]>
Sender: [email-masked]

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)" <[email-masked]>
To: <[email-masked]>
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: [email-masked]
To: Keith Moore <[email-masked]>
Cc: "Vaudreuil, Greg M (Greg)" <[email-masked]>, [email-masked]
Subject: Re: Review needed 
Date: Tue, 15 Aug 2000 14:59:06 -0400
Sender: [email-masked]

--==_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

--==_Exmh_915805976P--

From: Keith Moore <[email-masked]>
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
cc: [email-masked]
Subject: Re: Review needed 
Date: Tue, 15 Aug 2000 14:43:30 -0400
Sender: [email-masked]

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: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked]
Subject: RE: Review needed
Date: Tue, 15 Aug 2000 13:08:33 -0500
Sender: [email-masked]

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.

Date: Tue, 15 Aug 2000 09:32:06 -0700
From: Doug Royer <[email-masked]>
Reply-To: [email-masked]
Organization: Software.com
To: [email-masked]
Subject: Re: Review needed
Sender: [email-masked]

"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

Date: Tue, 15 Aug 2000 11:55:30 -0400
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Keith Moore <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Review needed
Sender: [email-masked]

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

eYYsXeYb
--------------ms34499AA50F31DB7D2870FC7E--

From: Keith Moore <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Review needed 
Date: Tue, 15 Aug 2000 10:42:44 -0400
Sender: [email-masked]

> 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: [email-masked]
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Review needed 
Date: Tue, 15 Aug 2000 09:29:09 -0400
Sender: [email-masked]

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

On Mon, 14 Aug 2000 23:53:00 EDT, Keith Moore <[email-masked]>  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

--==_Exmh_-229565188P--

Date: Tue, 15 Aug 2000 09:25:32 -0400
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Review needed
Sender: [email-masked]

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
[email-masked]

_____________________

[email-masked] 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 ([email-masked])
> and myself ([email-masked]).
>
> 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

dcGUNcgT
--------------ms6A1DCB031C471B53A3FE0045--

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: Review needed 
Date: Mon, 14 Aug 2000 23:53:00 -0400
Sender: [email-masked]

> 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

Date: Mon, 14 Aug 2000 19:52:35 -0700
From: Doug Royer <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Review needed
Sender: [email-masked]

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

Date: Mon, 14 Aug 2000 22:04:45 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
CC: [email-masked]
Subject: Re: Review needed
Sender: [email-masked]

[email-masked] 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 ([email-masked])
> and myself ([email-masked]).

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
	[email-masked]

Date: Mon, 14 Aug 2000 15:38:49 +0200
To: [email-masked], [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: Review needed
Sender: [email-masked]

At 01:07 14/08/2000 -0700, [email-masked] 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, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

From: Keith Moore <[email-masked]>
To: [email-masked], Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: [email-masked]
Subject: Re: Review needed 
Date: Mon, 14 Aug 2000 08:56:36 -0400
Sender: [email-masked]

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: [email-masked]
Date: Mon, 14 Aug 2000 01:07:11 -0700 (PDT)
Subject: Review needed
To: [email-masked]
Sender: [email-masked]

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 ([email-masked])
and myself ([email-masked]).

Thanks.

				Ned