Subject: Re: draft-ietf-drums-msg-fmt-02.txt

From: "Bart Schaefer" <[email-masked]>
Date: Sun, 29 Jun 1997 18:12:57 -0700

On Jun 29,  8:41pm, Pete Resnick wrote:
} Subject: Re: draft-ietf-drums-msg-fmt-02.txt
}
} Note: Reintroducing a message into the transport system and using resent
} fields is a different operation from "forwarding". Forwarding a message is to
} make it the body of a new message. A forwarded message does not appear to
} have come from the original sender, but is an entirely new message from the
} forwarder of the message. Resent headers are not intended for use with
} forwarding.
} 
} Do you really think I need to move this up to the top of the section?

The sieve draft being discussed over on ietf-mta-filters is using the
term `forward' to mean what DRUMS is tagging with `Resent-' headers.
I think the terminology had better be consistent everywhere.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

---

From: Pete Resnick <[email-masked]>
Date: Sun, 29 Jun 1997 21:42:42 -0400

>I think the terminology had better be consistent everywhere.

What DRUMS is referring to as "resending" and using "Resent-*" headers for
I've heard called "resending", "redirecting", and "bouncing". All mail
packages I've ever heard of use "forward" in the same way that DRUMS does.
The only place that the word "forwarding" is used to indicate what DRUMS is
calling "resending" is, unfortunately, in RFC 822. But 822 does not make
the distinction and does not recognize the act of sending a message as the
contents of another message. 822's use is simply confusing the issue, as it
clearly did in the sieve draft.

Perhaps I should indicate that this departs from 822 in the note cited above.

The sieve draft should be corrected to use the same terminology as DRUMS.

pr

--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980

---

From: Chris Newman <[email-masked]>
Date: Mon, 30 Jun 1997 09:12:08 -0700 (PDT)

There are really 3 different concepts here.

There is MTA level forwarding (e.g. Unix .forward file) which simply
rewrites the SMTP envelope recipient.  Note that MTA level functions
shouldn't alter the headers (other than adding Received).  This can
generate an RFC 1891 notification.  The term "forwarding address" is
well-known and tightly bound to this concept.

There is MUA level forwarding (e.g. "forward" command in most MUAs) which
encapsulates the message with explainatory information.

There is Resending (also "bounce" or "redirect") which is an MUA level
action which adds Resent headers but doesn't alter the message body.

If necessary, we can just define these three concepts in each document to
keep things clear.

Date: Mon, 30 Jun 1997 09:12:08 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: draft-ietf-drums-msg-fmt-02.txt
To: Pete Resnick <[email-masked]>
Cc: MTA Filters <[email-masked]>, Claus =?iso-8859-1?Q?Andr=E9?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?F=E4rber?= <[email-masked]>, Detailed Revision/Update of Message Standards <[email-masked]>
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

There are really 3 different concepts here.

There is MTA level forwarding (e.g. Unix .forward file) which simply
rewrites the SMTP envelope recipient.  Note that MTA level functions
shouldn't alter the headers (other than adding Received).  This can
generate an RFC 1891 notification.  The term "forwarding address" is
well-known and tightly bound to this concept.

There is MUA level forwarding (e.g. "forward" command in most MUAs) which
encapsulates the message with explainatory information.

There is Resending (also "bounce" or "redirect") which is an MUA level
action which adds Resent headers but doesn't alter the message body.

If necessary, we can just define these three concepts in each document to
keep things clear.

Date: Sun, 29 Jun 1997 21:42:42 -0400
To: "Bart Schaefer" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: draft-ietf-drums-msg-fmt-02.txt
Cc: [email-masked], [email-masked] (Claus =?iso-8859-1?Q?Andr=E9?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?F=E4rber?=  ), [email-masked]
Sender: [email-masked]

pr

From: "Bart Schaefer" <[email-masked]>
Date: Sun, 29 Jun 1997 18:12:57 -0700
Comments: In reply to Pete Resnick <[email-masked]> "Re: draft-ietf-drums-msg-fmt-02.txt" (Jun 29,  8:41pm)
To: [email-masked], Pete Resnick <[email-masked]>, [email-masked] (=?iso-8859-1?Q?Claus_Andr=E9_F=E4rber_?=)
Subject: Re: draft-ietf-drums-msg-fmt-02.txt
Cc: [email-masked]
Sender: [email-masked]

Date: Sun, 29 Jun 1997 00:49:33 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: new sieve draft
Sender: [email-masked]

While I wasn't looking, ftp.ietf.org has had the version 01 sieve draft
placed online.  Aparently the URL is 

ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-01.txt

Comments appreciated.  I took poor notes on requested changes; if I missed
something, please let me know.

I tried to fill in some of the sections I'd left blank before.  Please let
me know how these turned out.

-- 
                                           Tim Showalter [email-masked]

Date: Fri, 27 Jun 1997 14:38:54 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: RE: Suggestions
To: Paul Vincent Craven <[email-masked]>
Cc: "ietf-mta-filters@im..." <[email-masked]>, Tim Showalter <[email-masked]>
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Fri, 27 Jun 1997, Paul Vincent Craven wrote:
> I would not want to tell a novice user how to delay mail using a cron job! My
> thought was that a client could add a line to the message such as:
> x-delay-mail: blah blah

I interpret "x-" as meaning "this is a proprietary non-interoperable
extension."  It's very overused.  It's also the wrong layer -- an SMTP
relay isn't supposed to look at RFC 822 headers.

> And the SMTP server would not forward the mail until the specified time was
> reached.

There are a number of serious security issues involved with this which
were discussed on the DRUMS mailing list.  Rough concensus was that it's a
really bad idea on the server -- it belongs in the user agent.

> Outgoing rules could also allow a company could forward a copy all
> messages that employees send to the competitor's domain to the office
> manager, etc.

That has very serious legal implications, so it's probably best done by a
proprietary mechanism (preferably undocumented so people don't get
themselves in legal trouble by accident).

Date: 27 Jun 97 15:39:29 -0500
From: Paul Vincent Craven <[email-masked]>
Subject: RE: Suggestions
To: MTA Filters <[email-masked]>, Tim Showalter <[email-masked]>
Reply-To: Paul Vincent Craven <[email-masked]>
Sender: [email-masked]

On 6/27/97, Tim Showalter wrote:
>On 27 Jun 1997, Paul Vincent Craven wrote:
>> On 6/27/97, Tim Showalter wrote:
>> >> I'd like to see a "redirect" command added to the basic actions list.
>Forward is defined (or will be, in the draft) to do just this, that is, what
>a .forward file does.  Is the other behavior useful in this case?

Ah, I see we have an ambiguity in terminology. Yes, the .foward file in UNIX
does do forwarding in the manner I described as being "redirect". I'm sure other
examples can be found of forward acting the same as redirect commands usually
implemented in clients. Going back to the document, I see you've defined forward to
operate the same as what I consider to be "redirect". Therefore I withdraw the
suggestion.

Date: Fri, 27 Jun 1997 16:22:58 -0400 (EDT)
From: Tim Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: Paul Vincent Craven <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: RE: Suggestions
Sender: [email-masked]

On 27 Jun 1997, Paul Vincent Craven wrote:

> On 6/27/97, Tim Showalter wrote:
> >> I'd like to see a "redirect" command added to the basic actions list.
> >
> >What does redirect do?
> 
> Forwarding mail usually changes the "from:" from the original sender to the
> person who is forwarding the mail. Redirect leaves the line alone. So a user
> receiving redirected mail will see the mail as coming from the original sender, not
> the person who redirected it. A user receiving forwarded mail will always have the
> "from" field show the individual who redirected it. Some mail systems also
> prepend a ">" to each line of a forwarded message, but not redirect mail.

Forward is defined (or will be, in the draft) to do just this, that is, what
a .forward file does.  Is the other behavior useful in this case?

> >> Some method where the extension action can reference the text of the 
> >message.
> >> This would allow an extension action to file a message in a database for 
> >example.
> >
> >I'm not sure what you're suggesting.  Are you looking for a way to deal with
> >the insides of a message?
> 
> No, just pass the entire message (or a reference to it) to an external action
> command. This would greatly enhance what extension-actions are capable of doing.
> I usually think of extension actions as being some type of plug-in architecture.

I don't see them that way.  This is a very dumb scripting language.  The
message just is, and I don't see any reason it needs to be passed around.

> >> I'd also like to see some discussion of rules on outgoing mail...
> >I think this is out of scope of what I'd intended.  I also belive delayed
> >mail is best done with a cron job.  Can you be more specific?
> 
> I would not want to tell a novice user how to delay mail using a cron job! My
> thought was that a client could add a line to the message such as:
> x-delay-mail: blah blah
> And the SMTP server would not forward the mail until the specified time was
> reached. Outgoing rules could also allow a company could forward a copy all
> messages that employees send to the competitor's domain to the office manager, etc.

This is seperate from filtering.  I also don't believe SMTP is the right
place to implement such a delay.  If a novice user really needs delayed
email, it can be implemented with suitable use of the sleep system call on a
reasonable system in something far more user-friendly than cron or at.

-- 
                                           Tim Showalter [email-masked]

Date: 27 Jun 97 15:07:59 -0500
From: Paul Vincent Craven <[email-masked]>
Subject: RE: Suggestions
To: "ietf-mta-filters@im..." <[email-masked]>, Tim Showalter <[email-masked]>
Reply-To: Paul Vincent Craven <[email-masked]>
Sender: [email-masked]

On 6/27/97, Tim Showalter wrote:
>> I'd like to see a "redirect" command added to the basic actions list.
>
>What does redirect do?

Forwarding mail usually changes the "from:" from the original sender to the
person who is forwarding the mail. Redirect leaves the line alone. So a user
receiving redirected mail will see the mail as coming from the original sender, not
the person who redirected it. A user receiving forwarded mail will always have the
"from" field show the individual who redirected it. Some mail systems also
prepend a ">" to each line of a forwarded message, but not redirect mail.

>> Some method where the extension action can reference the text of the 
>message.
>> This would allow an extension action to file a message in a database for 
>example.
>
>I'm not sure what you're suggesting.  Are you looking for a way to deal with
>the insides of a message?

No, just pass the entire message (or a reference to it) to an external action
command. This would greatly enhance what extension-actions are capable of doing.
I usually think of extension actions as being some type of plug-in architecture.

>> I'd also like to see some discussion of rules on outgoing mail...
>I think this is out of scope of what I'd intended.  I also belive delayed
>mail is best done with a cron job.  Can you be more specific?

I would not want to tell a novice user how to delay mail using a cron job! My
thought was that a client could add a line to the message such as:
x-delay-mail: blah blah
And the SMTP server would not forward the mail until the specified time was
reached. Outgoing rules could also allow a company could forward a copy all
messages that employees send to the competitor's domain to the office manager, etc.

Date: Fri, 27 Jun 1997 15:41:59 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: Paul Vincent Craven <[email-masked]>
cc: "ietf-mta-filters@im..." <[email-masked]>
Subject: Re: Suggestions
Sender: [email-masked]

On 26 Jun 1997, Paul Vincent Craven wrote:

> I'd like to see a "redirect" command added to the basic actions list.

What does redirect do?

> A way to pass a parameter to extension-actions
> my_action( header("organization" ))

This is probably true.  The language design needs to be reworked to be more
sane. Just having an ad-hoc grammar will encourage a lot of bad extension
design.  This is probably a specific case of general argument passing.

> Some method where the extension action can reference the text of the message.
> This would allow an extension action to file a message in a database for example.

I'm not sure what you're suggesting.  Are you looking for a way to deal with
the insides of a message?

> I'd also like to see some discussion of rules on outgoing mail. We can do this
> if rule processing is incorporated with the SMTP server. This would allow a
> delayed mail feature. e.g.
> if
>   header("x-delay-until")
> then
>   delay_mail( header("x-delay-until"))
>   toss // the original message

I think this is out of scope of what I'd intended.  I also belive delayed
mail is best done with a cron job.  Can you be more specific?

-- 
                                           Tim Showalter [email-masked]

Date: 26 Jun 97 11:34:48 -0500
From: Paul Vincent Craven <[email-masked]>
Subject: Suggestions
To: "ietf-mta-filters@im..." <[email-masked]>
Reply-To: Paul Vincent Craven <[email-masked]>
Sender: [email-masked]

I'd like to see a "redirect" command added to the basic actions list.

Definition for exists needs to be spelled out in the grammer
e.g. exists = "exists" [WSP] "(" #(condition) [WSP] ")"

A way to pass a parameter to extension-actions
my_action( header("organization" ))

Some method where the extension action can reference the text of the message.
This would allow an extension action to file a message in a database for example.

I'd also like to see some discussion of rules on outgoing mail. We can do this
if rule processing is incorporated with the SMTP server. This would allow a
delayed mail feature. e.g.
if
  header("x-delay-until")
then
  delay_mail( header("x-delay-until"))
  toss // the original message

-------------
Paul Vincent Craven
[email-masked]
Software Engineer, CE Software
http://www.cesoft.com
http://www.raccoon.com/~pcraven