Re: sieve: vacation extension

["Paul Falstad" <[e-mail]>]

Ned Freed says:
| Subject: Re: sieve: vacation extension
| > | Subject: Re: sieve: vacation extension
| > | Vacation has to respond to the MAIL FROM address or Return-Path address,
| > | not to the Reply-To/From header.
|
| > Is that specified somewhere?  RFC822 requires that automated replies go
| > to the address in Reply-To:/From:.
|
| This "requirement" of RFC822 has long been understood to be an
| _extremely_ bad idea.

Ok.  It does seem like a bad idea, especially when mailing lists are
taken into consideration.

| and I believe the revised SMTP document makes it clear that
| automatic notices should always be sent to the MAIL FROM address.

I couldn't find that, but maybe I wasn't looking hard enough.

draft-ietf-drums-kre-reply-to-00.txt adds to my confusion by stating:

   One way to avoid the seeming inconsistency of these examples is to
   note that the "use Reply-To instead of From" rule is intended to
   apply only to "automatic replies", and that for replies generated by
   humans, the address choice should generally be left to the human.
   See RFC822 section 4.4.4.

But it appears that that particular draft is just a proposed addition
to another draft..

We had a customer once who yelled at us because our autoreplier (which
was replying to MAIL FROM) wasn't following the RFC's.  So it would be
nice to have this made crystal clear in the standards.

--
Paul Falstad                                 Software.com, Inc.
[e-mail]                    805-957-1790 x520
http://www.ttinet.com/pjf/                   http://www.software.com/



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA08754 for ietf-mta-filters-bks; Mon, 24 Nov 1997 12:05:10 -0800 (PST)
Received: from hanoi.software.com ([207.175.94.227]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA08750 for <[e-mail]>; Mon, 24 Nov 1997 12:05:07 -0800 (PST)
Received: from hanoi.software.com ([127.0.0.0]) by hanoi.software.com (Post.Office MTA v3.199 release 123 ID# 105-123L0S0) with SMTP id AAA937; Mon, 24 Nov 1997 12:03:55 -0800
From: "Paul Falstad" <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 24 Nov 1997 12:03:55 -0800
In-Reply-To: Ned Freed <[e-mail]> "Re: sieve: vacation extension" (Nov 24, 10:13am)
References: <[e-mail]>  <[e-mail]>  <"Re: sieve: vacation extension"@mail.proper.com>  <[e-mail]>
X-Shakespearean-Insult: Thou reeky toad-spotted harpy!
Reply-To: Paul Falstad <[e-mail]>
X-Mailer: Z-Mail (3.2.1 24feb96 Caldera)
To: Ned Freed <[e-mail]>
Subject: Re: sieve: vacation extension
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Ned Freed says:
| Subject: Re: sieve: vacation extension
| > | Subject: Re: sieve: vacation extension
| > | Vacation has to respond to the MAIL FROM address or Return-Path address,
| > | not to the Reply-To/From header.
|
| > Is that specified somewhere?  RFC822 requires that automated replies go
| > to the address in Reply-To:/From:.
|
| This "requirement" of RFC822 has long been understood to be an
| _extremely_ bad idea.

Ok.  It does seem like a bad idea, especially when mailing lists are
taken into consideration.

| and I believe the revised SMTP document makes it clear that
| automatic notices should always be sent to the MAIL FROM address.

I couldn't find that, but maybe I wasn't looking hard enough.

draft-ietf-drums-kre-reply-to-00.txt adds to my confusion by stating:

   One way to avoid the seeming inconsistency of these examples is to
   note that the "use Reply-To instead of From" rule is intended to
   apply only to "automatic replies", and that for replies generated by
   humans, the address choice should generally be left to the human.
   See RFC822 section 4.4.4.

But it appears that that particular draft is just a proposed addition
to another draft..

We had a customer once who yelled at us because our autoreplier (which
was replying to MAIL FROM) wasn't following the RFC's.  So it would be
nice to have this made crystal clear in the standards.

--
Paul Falstad                                 Software.com, Inc.
[e-mail]                    805-957-1790 x520
http://www.ttinet.com/pjf/                   http://www.software.com/



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07129 for ietf-mta-filters-bks; Mon, 24 Nov 1997 10:23:28 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07125 for <[e-mail]>; Mon, 24 Nov 1997 10:23:24 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <[e-mail]> for [e-mail]; Mon, 24 Nov 1997 10:23:57 PST
Date: Mon, 24 Nov 1997 10:13:46 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: sieve: vacation extension
In-reply-to: "Your message dated Sun, 23 Nov 1997 21:54:08 -0800" <[e-mail]>
To: Paul Falstad <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
References: <[e-mail]> <[e-mail]> <"Re: sieve: vacation extension"@mail.proper.com>
Sender: [e-mail]
Precedence: bulk

> | Subject: Re: sieve: vacation extension
> | Vacation has to respond to the MAIL FROM address or Return-Path address,
> | not to the Reply-To/From header.

> Is that specified somewhere?  RFC822 requires that automated replies go
> to the address in Reply-To:/From:. 

This "requirement" of RFC822 has long been understood to be an _extremely_ bad
idea. It came about as a result of thinking of RFC822 in a vacuum, which isn't
how RFC822 is really used.

This statement is specifically overridden by RFC1123 in the case of failure
notifications; RFC1123 should have made it clear that this applies to any form
of automatic notification, but unfortunately did not do so, probably because at
the time the similarities between all forms of automatic responses weren't well
understood. RFC1891-4 make it clear that the MAIL FROM must be used for all
types of notifications, and the only reason vacation notices aren't included in
this set is that the WG could not reach consensus on various other aspects of
them. The need for vacation notices to go to the MAIL FROM address was never in
doubt, however.

In any case, this RFC822 recommendation has been dropped from the revised
version of the specification that the DRUMS WG has produced, and I believe the
revised SMTP document makes it clear that automatic notices should always be
sent to the MAIL FROM address.

> But, the standard vacation program
> replies to the MAIL FROM address, it looks like...

Indeed it does, and this is a Good Thing.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA27123 for ietf-mta-filters-bks; Sun, 23 Nov 1997 21:55:27 -0800 (PST)
Received: from hanoi.software.com (sbsg-226.software.com [207.175.94.226]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA27119 for <[e-mail]>; Sun, 23 Nov 1997 21:55:23 -0800 (PST)
Received: from hanoi.software.com ([127.0.0.0]) by hanoi.software.com (Post.Office MTA v3.199 release 123 ID# 105-123L0S0) with SMTP id AAA8175 for <[e-mail]>; Sun, 23 Nov 1997 21:54:09 -0800
From: "Paul Falstad" <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 23 Nov 1997 21:54:08 -0800
In-Reply-To: Chris Newman <[e-mail]> "Re: sieve: vacation extension" (Nov 20, 10:51pm)
References: <[e-mail]>
X-Shakespearean-Insult: Thou clouted full-gorged mammet!
Reply-To: Paul Falstad <[e-mail]>
X-Mailer: Z-Mail (3.2.1 24feb96 Caldera)
To: [e-mail]
Subject: Re: sieve: vacation extension
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Chris Newman says:
| Subject: Re: sieve: vacation extension
| Vacation has to respond to the MAIL FROM address or Return-Path address,
| not to the Reply-To/From header.

Is that specified somewhere?  RFC822 requires that automated replies go
to the address in Reply-To:/From:.  But, the standard vacation program
replies to the MAIL FROM address, it looks like...


-- 
Paul Falstad                                 Software.com, Inc.
[e-mail]                    805-957-1790 x520
http://www.ttinet.com/pjf/                   http://www.software.com/



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA19686 for ietf-mta-filters-bks; Sun, 23 Nov 1997 07:42:02 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA19682 for <[e-mail]>; Sun, 23 Nov 1997 07:41:57 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id QAA28637 for <[e-mail]>; Sun, 23 Nov 1997 16:42:43 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 23 Nov 1997 16:43:16 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics Operation
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Possible vacation notice approaches (was: Re: sieve: vacation extension)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Chris Bartram wrote:

> Not so far off perhaps... If the vacation notices were wrapped in a standard
> format (like the MDN/DSNs) then software could potentially handle such
> notices automatically. At least, as long as an RFC is being developed for
> vacation messages anyway, why not go ahead and dictate that the vacation
> messages utilize one of the standardized notification formats??

I like your idea, let's see where this can lead us...

I can see at least two approaches to handle incoming messages for
vacated users. One is to delay final delivery at the MTA level and
sending an appropriate "delayed" DSN, the other is to complete the final
delivery and and send an appropriate "dispatched" MDN.

In the case of a delayed final delivery the proposed vacation extension
in Sieve is not useful since Sieve is intended to be applied at the
point of final delivery. When the user have activated the vacation state
on the maildrop, messages will not be finally delivered until end of the
vacation period.
What complications can this imply on the MTA level?
For the user to gain access to the queued messages before end of the
vacation period the vacation state have to be cancelled and possibly
reinstated after having the queued messages delivered to the maildrop.

Looking into the use of DSN for vacation notices raises some questions.
Using Action:delayed seem to most appropriate in such an approach. The
most appropriate status code seem to be 4.2.1 as taken from RFC 1893:
  4.X.X   Persistent Transient Failure
  X.2.X   Mailbox Status
  X.2.1   Mailbox disabled, not accepting messages
There seem to be no code for vacation, do we need to define such?

Then we should try to communicate the duration of the vacation period.
Is it sufficient to use the optional "Will-Retry-Until" header?
Or one might want to use the "Diagnostic-Code" with type "vacation"
(certainly not standard yet :) and a text argument containing meta
information about the vacation. There is also the choice of using
extension headers. Comments?

Regarding the alternative approach of completing the final delivery and
emitting an MDN as vacation notice, the following might do the trick:
  Disposition-action-mode = automatic-action
  Disposition-action-mode = MDN-sent-automatically
  Disposition-type = "dispatched"
  Disposition-modifier = "vacation" (or "x-vacation" until registered)
Resulting in a complete disposition field as:
  Disposition: automatic-action/MDN-sent-automatically ;
               dispatched/x-vacation

Comments?
-- 
Tomas Fasth                  mailto:[e-mail]
EuroNetics Operation         telephone:[phone]
Mjärdevi Science Park        cellular:[phone]
58330 Linköping, Sweden      facsimile:[phone]
TwinSpot Network is a subsidiary of EuroNetics Operation


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA27607 for ietf-mta-filters-bks; Fri, 21 Nov 1997 16:16:28 -0800 (PST)
Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA27602 for <[e-mail]>; Fri, 21 Nov 1997 16:16:24 -0800 (PST)
From: "Chris Bartram" <[e-mail]>
Organization: 3k Associates
Reply-To: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: NetMail/3000 [Version B.06 97/10/28]
MIME-Version: 1.0
Content-Type: Text/Plain
Date: Fri, 21 Nov 1997 19:15:26 -0500
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: sieve: vacation extension
To: [e-mail]
Sender: [e-mail]
Precedence: bulk

 In <[e-mail]> [e-mail] writes:

> > Chris Bartram wrote:
> >
> > > It might be reasonable to suggest that no repeat messages get sent as l> o
> ong
> > > as the "vacation" command/action is in effect. If it is changed/deleted>
> -and-
> > > added-back, then a new log is to be created
> >
> > I tend to agree with Chris B. about oneshot vacation notices. At least
> > it allow side-stepping the issues he described. It seem to me that
> > having a vacation notice repeated at some interval is more a function of
> > the original sender's individual memory refresh rate (which may vary
> > from time to time :) than anything else.
> >
> > Is there any strong arguments for having repeated vacation notices?
> >
> > A nice touch would be if the originator's MUA understood the vacation
> > notice good enough to politely make a reminder during the vacation
> > period each time the sender tries to submit another message. I guess
> > it's only a dream of mine...

Not so far off perhaps... If the vacation notices were wrapped in a standard
format (like the MDN/DSNs) then software could potentially handle such
notices automatically. At least, as long as an RFC is being developed for
vacation messages anyway, why not go ahead and dictate that the vacation
messages utilize one of the standardized notification formats??

              -Chris Bartram



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA27488 for ietf-mta-filters-bks; Fri, 21 Nov 1997 16:06:34 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA27484 for <[e-mail]>; Fri, 21 Nov 1997 16:06:29 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id BAA23592 for <[e-mail]>; Sat, 22 Nov 1997 01:07:31 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 22 Nov 1997 01:07:59 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: sieve: vacation extension
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Chris Bartram wrote:

> It might be reasonable to suggest that no repeat messages get sent as long
> as the "vacation" command/action is in effect. If it is changed/deleted-and-
> added-back, then a new log is to be created

I tend to agree with Chris B. about oneshot vacation notices. At least
it allow side-stepping the issues he described. It seem to me that
having a vacation notice repeated at some interval is more a function of
the original sender's individual memory refresh rate (which may vary
from time to time :) than anything else.

Is there any strong arguments for having repeated vacation notices?

A nice touch would be if the originator's MUA understood the vacation
notice good enough to politely make a reminder during the vacation
period each time the sender tries to submit another message. I guess
it's only a dream of mine...

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA25516 for ietf-mta-filters-bks; Fri, 21 Nov 1997 13:50:43 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA25511 for <[e-mail]>; Fri, 21 Nov 1997 13:50:38 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA27122; Fri, 21 Nov 1997 16:49:51 -0500 (EST)
Date: Fri, 21 Nov 1997 16:49:50 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: Chris Newman <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: sieve: vacation extension
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 20 Nov 1997, Chris Newman wrote:

> I understand the desire to protect users from their own stupidity, but I
> really think this sort of check is better done in Sieve than in the
> vacation extension itself.  If we're assuming the majority of Sieve
> scripts will be configured by MUAs, then the MUAs will probably get this
> right if given proper guidance.

Ok; I guess I'll make the change.  I think it makes sense to ask clients
that write scripts to try and write scripts in the following way:

if header "from" matches ("[e-mail]" "tjs+*@andrew.cmu.edu") {
	vacation;
}

I guess I'm blurring vacation with some of the more defective
autoresponders.  With the changes you've suggested I guess even occasonial
misfires will be okay.

I might as well ask.  I looked at the man page for Solaris vacation.  Are
there any others that I should check out, or is it really the same across
Unix versions?

Thanks...

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA18824 for ietf-mta-filters-bks; Fri, 21 Nov 1997 07:42:17 -0800 (PST)
Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA18813 for <[e-mail]>; Fri, 21 Nov 1997 07:42:09 -0800 (PST)
From: "Chris Bartram" <[e-mail]>
Organization: 3k Associates
Reply-To: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: NetMail/3000 [Version B.06 97/10/28]
MIME-Version: 1.0
Content-Type: Text/Plain
Date: Fri, 21 Nov 1997 10:41:55 -0500
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: sieve: vacation extension
To: [e-mail]
Sender: [e-mail]
Precedence: bulk

 In <[e-mail]> [e-mail] writes:

> On Thu, 20 Nov 1997, Chris Newman wrote:
>
> > You probably need a way to specify the delay between repeat notifications
> > if it's not the default one week.  I'm not sure how important this is.
>
> I'm going to have to add a general way of doing optional arguments to
> commands, I think, so it's easier for extensions.  There are a couple
> commands in the draft that could benefit from this.

It might be reasonable to suggest that no repeat messages get sent as long
as the "vacation" command/action is in effect. If it is changed/deleted-and-
added-back, then a new log is to be created

After all, a good vacation message should report the time period you're
not available for, and one of these per recipient should be plenty. I.e.
if the vacation message reports;

 "I'll be on safari from November 1,1997 til May 12, 1998"

I don't need to get a reminder of that once a week.

As a side note; perhaps a "recommendation" in the spec that implementors
"suggest" to users that they at LEAST provide a time period that they will
be unavailable in every vacation message. Kind of a "Note to implementors".
A "Sorry, I'm out of the office" message doesn't do much to help anyone.

> > I suggest you drop the recipient check, but instead use Sieve to do the
> > recipient check in examples.  The Sieve interpreter may not know all the
> > address forms for the script owner.
>
> I don't agree with this.  I'm afraid if users try to configure vacation,
> they'll blow it more times than they get it right.

I don't think there's a need to worry about the recipient check; if the
log ensures that ONLY ONE reply will ever be sent to a given return address,
at most you'll get one looped message to each of your various address
variations. It's probably alot easier just to deal with this than to worry
about rules for figuring out if you're really on a recip list... That's
never been doable in a reliable means anyway.

As long as only one reply goes to any sender, you won't have loops, and
that's the biggest problem you want to avoid with vacation programs (with
the mailing list reply's being second, and you've addressed that one). Even
on mail lists though, if you only ever send ONE reply, noone (usually) gets
too upset... it's the bums that send vacation responses back to EVERY list
posting that REALLY upset people! ;-)

                  -Chris Bartram



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA09141 for ietf-mta-filters-bks; Thu, 20 Nov 1997 23:09:15 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA09136 for <[e-mail]>; Thu, 20 Nov 1997 23:09:11 -0800 (PST)
Received: from eleanor.innosoft.com ("port 50607"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Thu, 20 Nov 1997 23:09:05 PST
Date: Thu, 20 Nov 1997 23:11:19 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: sieve: vacation extension
In-reply-to: <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [e-mail]
Precedence: bulk

On Fri, 21 Nov 1997, Tim Showalter wrote:
> > I suggest you drop the recipient check, but instead use Sieve to do the
> > recipient check in examples.  The Sieve interpreter may not know all the
> > address forms for the script owner.
> 
> I don't agree with this.  I'm afraid if users try to configure vacation,
> they'll blow it more times than they get it right.

The alternative is to allow a way to configure a list of addresses which
refer to the user running the script.  As an example, my set is:
<[e-mail]>
<chris+*@innosoft.com>
<[e-mail]>
<chris.newman+*@innosoft.com>

I understand the desire to protect users from their own stupidity, but I
really think this sort of check is better done in Sieve than in the
vacation extension itself.  If we're assuming the majority of Sieve
scripts will be configured by MUAs, then the MUAs will probably get this
right if given proper guidance.

		- Chris



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA08911 for ietf-mta-filters-bks; Thu, 20 Nov 1997 22:54:44 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA08907 for <[e-mail]>; Thu, 20 Nov 1997 22:54:41 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id BAA19993; Fri, 21 Nov 1997 01:55:33 -0500 (EST)
Date: Fri, 21 Nov 1997 01:55:33 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: Chris Newman <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: sieve: vacation extension
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 20 Nov 1997, Chris Newman wrote:

> Vacation has to respond to the MAIL FROM address or Return-Path address,
> not to the Reply-To/From header.

Ok, will change this.

> You probably need a way to specify the delay between repeat notifications
> if it's not the default one week.  I'm not sure how important this is.

I'm going to have to add a general way of doing optional arguments to
commands, I think, so it's easier for extensions.  There are a couple
commands in the draft that could benefit from this.

> I suggest you drop the recipient check, but instead use Sieve to do the
> recipient check in examples.  The Sieve interpreter may not know all the
> address forms for the script owner.

I don't agree with this.  I'm afraid if users try to configure vacation,
they'll blow it more times than they get it right.

> The man page on vacation does a good job explaining the services it
> provides.  It's fairly complete and well designed.

Guess I need to stare at it some more ...  thanks.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA08823 for ietf-mta-filters-bks; Thu, 20 Nov 1997 22:49:00 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA08819 for <[e-mail]>; Thu, 20 Nov 1997 22:48:56 -0800 (PST)
Received: from eleanor.innosoft.com ("port 50592"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Thu, 20 Nov 1997 22:48:50 PST
Date: Thu, 20 Nov 1997 22:51:05 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: sieve: vacation extension
In-reply-to: <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: MTA Filters <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [e-mail]
Precedence: bulk

Vacation has to respond to the MAIL FROM address or Return-Path address,
not to the Reply-To/From header.

You probably need a way to specify the delay between repeat notifications
if it's not the default one week.  I'm not sure how important this is.

I suggest you drop the recipient check, but instead use Sieve to do the
recipient check in examples.  The Sieve interpreter may not know all the
address forms for the script owner.

The man page on vacation does a good job explaining the services it
provides.  It's fairly complete and well designed.

		- Chris



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA04688 for ietf-mta-filters-bks; Thu, 20 Nov 1997 17:55:36 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA04683 for <[e-mail]>; Thu, 20 Nov 1997 17:55:31 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id UAA11034 for <[e-mail]>; Thu, 20 Nov 1997 20:56:25 -0500 (EST)
Date: Thu, 20 Nov 1997 20:56:22 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: sieve: vacation extension
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I was asked to put together a vacation extension.  I'm attaching it
here since some didn't like the last draft I posted as base64-encoded
MIME enclosure.

I'll put a copy at http://www.club.cc.cmu.edu/~tjs/sieve-vacation.txt
as well in case a mailer mangles it.  It's six pages, but I wanted to
try and get all the weird cases not to mail correct.

This hasn't been submitted to the Internet-Drafts repository because
I'm not sure it's quite right; I'll probably do it tomorrow after the
first round of nits.

Hope this helps -- thanks...

-- 
                                           Tim Showalter [e-mail]






Network Working Group                                       T. Showalter
Internet Draft: Sieve Vacation                           Carnegie Mellon
Document: draft-showalter-sieve-vacation-00beta.txt        November 1997
Expire in six months (31 May 1998)


                      Sieve -- Vacation Extension


Status of this memo

   This document is an Internet-Draft.  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 learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   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

   This document describes an extension to the Sieve mail filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command.  The extension is offered in the hopes of making frequently
   used commands availible (and discouraging users from implementing it
   themselves).












Showalter                 Expires 31-May-1997                   [Page 1]

Internet DRAFT             Sieve -- Vacation           November 20, 1997


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

   This draft is intended to be compared with the Sieve mail filtering
   language, an internet-draft being discussed on the MTA Filters
   mailing list at <[e-mail]>.  Subscription requests
   can be sent to <[e-mail]> (send an email
   message with the word "subscribe" in the body).  More information on
   the mailing list along with a WWW archive of back messages is
   available at <http://www.imc.org/ietf-mta-filters>.

1. Introduction

   This is an extension to the Sieve language defined by [SIEVE] for
   notification that messages will not be immediately answered.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].

2. Capability identifier

   Sieve implementations that implement vacation have an identifier of
   "VACATION" for use with the capability mechanism (i.e., "support").

3. Vacation Action


   Syntax:   vacation <reason-string>

   The "vacation" action implements a vacation autoresponder similar to
   the one availible under many versions of UNIX.  Its purpose is to
   provide correspondants with notification that the user is away for an
   extended period of time and that they should not expect quick
   responses.

   Vacation is similar to reply as defined in [SIEVE].  There are a few
   differences:

   First, "vacation" SHOULD NOT respond to a message sent from the
   user's address.  Therefore, the Sieve implementation should know what
   the user's address is.  If the user has more than one address for a
   given site, all addresses should also not get a reply message.

   Second, "vacation" MUST NOT reply to mail from "postmaster" or any



Showalter                 Expires 31-May-1997                   [Page 4]

Internet DRAFT             Sieve -- Vacation           November 20, 1997


   other address where the left-hand side ends in "-request" (that is, a
   mailing list administrative address).

   Third, "vacation" MUST NOT reply to a message that does not list the
   users' address in the "To:" or "Cc:" header.  The intention is that
   mail to a mailing list that the user is subscribed to should never
   get a "vacation" response.

   Finally, "vacation" MUST keep track of all of the addresses that it
   has responded to in the past seven (7) days and MUST NOT respond to
   them a second time within this period.  The "vacation" action may
   send out notifications less frequently, but should not send them out
   more frequently.

   The simplest way to use vacation is just this:

   Example:  vacation "I'm away until Octber 19.  If it's an emergency,
             call 911, I guess." ;

   By mingling vacation with other rules, users can do something more
   selective.

   Example:  if header "from" contains "[e-mail]" {
                forward "[e-mail]";
             } else {
                vacation "Sorry, I'm away, I'll read your message when I
                get around to it.";
             }

4. Formal Grammar

   The grammar used in this section is the same as the ABNF described in
   [ABNF].

   action =/ vacation         ;; "vacation" is now a legal action

   vacation = vacation WSP string

5. Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]





Showalter                 Expires 31-May-1997                   [Page 5]

Internet DRAFT             Sieve -- Vacation           November 20, 1997


Appendices

Appendix A.  References

   [ABNF] Crocker, D.,  "Augmented BNF for Syntax Specifications: ABNF",
   Internet Mail Consortium, RFC 2234, November, 1997.

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [SIEVE] Showalter, T.  "Sieve: A Mail Filtering Language",  Carenegie
   Mellon, Work in Progress.







































Showalter                 Expires 31-May-1997                   [Page 6]




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01883 for ietf-mta-filters-bks; Thu, 20 Nov 1997 14:46:45 -0800 (PST)
Received: from deptvamc2-bh.va.gov (deptvachi-bh.va.gov [205.183.31.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id OAA01877 for <[e-mail]>; Thu, 20 Nov 1997 14:46:41 -0800 (PST)
Received: (from uucp@localhost) by deptvamc2-bh.va.gov (8.6.12/8.6.11) id KAA16729 for <[e-mail]>; Thu, 20 Nov 1997 10:37:56 -0600
Received: from 152.129.1.6 by deptvamc2-bh.va.gov via smap (3.2) id xmab15577; Thu, 20 Nov 97 10:36:29 -0600
Received: by vhaishhbexc1.med.va.gov with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Thu, 20 Nov 1997 10:40:46 -0600
Message-ID: <c=US%a=_%p=VA%l=[e-mail]>
From: "Woodhouse, Gregory J." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Tomas Fasth'" <[e-mail]>
Subject: RE: bounce, mta, & mua (was Re: sieve draft)
Date: Wed, 19 Nov 1997 12:47:15 -0600
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk

Actually, RFC 822 (at least) never says "Return-Path" is required, but=20
the revised document being developed by DRUMS reads:
When the delivery SMTP server makes the "final delivery" of a message,=20
it inserts a return-path line at the beginning of the mail data.  This=20
use of return-path is required; mail systems MUST support it.  The=20
return-path line preserves the information in the <reverse-path> from=20
the MAIL command.  Here, final delivery means the message has left the=20
SMTP world.  Normally, this would mean it had been delivered to the=20
destination user or an associated mail drop, but in some cases it may=20
be further processed and transmitted by another mail system.
=3D=3D=3D
Gregory Woodhouse
San Francisco CIO Field Office - Infrastructure
[e-mail]
[phone]  /  May the dromedary be with you

----------
From:  Tomas Fasth [SMTP:[e-mail]]
Sent:  Wednesday, November 19, 1997 8:07 AM
To:  [e-mail]
Subject:  Re: bounce, mta, & mua (was Re: sieve draft)

Chris Newman wrote:
> This is incorrect.  UAs will have access to the "MAIL FROM" address=20
unless
> an upstream system violated Internet standards.  The final delivery=20
agent
> is REQUIRED to copy the "MAIL FROM" address into the "Return-Path"
> header.  Anything which doesn't is broken.

Chris, can you give us the exact location in an RFC that backs up your=20
assertion? I'm not sure it is required and I'm not sure you can ever=20
rely on it's existence once the message have moved into the domain of=20
the MUA.
If you're right, my FreeBSD "out-of-the-box" installation is certainly=20
broken. The "P" flag required to generate the Return-Path header is=20
_not_ set for the local mailer by default. I don't know why, but the=20
very existence of this discrepency (the fact that it's optional) is=20
enough for me to maintain that this header might not always be=20
available. Period.

[...]
--
H=E4lsningar/Regards
Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]=20
EuroNetics Operation, Mj=E4rdevi Science Park, 58330 Link=F6ping, Sweden =

(TwinSpot Network is a subsidiary of EuroNetics Operation)



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA01151 for ietf-mta-filters-bks; Thu, 20 Nov 1997 14:05:19 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA01146 for <[e-mail]>; Thu, 20 Nov 1997 14:05:15 -0800 (PST)
Received: from eleanor.innosoft.com ("port 47163"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Thu, 20 Nov 1997 14:05:03 PST
Date: Thu, 20 Nov 1997 14:07:17 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: Why bounce/reject is necessary
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [e-mail]
Precedence: bulk

On Wed, 19 Nov 1997, Tomas Fasth wrote:
> Chris Newman wrote:
> > (1) Change of address.
> Hmm. This is certainly a service we have wanted in MTAs for a long time.
> What I don't understand is why this would be solved within the domain of
> message filtering?

Suppose I'm a sales representative and some of my customers are reassigned
to a new sales representative, but my old address remains the same for
other correspondence.

Any action which might be conditional on the from/sender is fair game for
Sieve.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA22631 for ietf-mta-filters-bks; Thu, 20 Nov 1997 04:33:48 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA22627 for <[e-mail]>; Thu, 20 Nov 1997 04:33:44 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id NAA19743 for <[e-mail]>; Thu, 20 Nov 1997 13:34:44 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 1997 13:35:08 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> Sure.  What would be more appropriate?  If you're going to refuse messages,
> then you're really going to refuse messages.  If you don't want to refuse
> messages, don't refuse messages.  What's the problem?

You're right, I'll take that back.

> What you're saying is that if A sends B a mesasge, and B sets up his mailer
> to reject A's messages, and A sets up his mailer to reject B's rejects, that
> A is likely to keep sending mail to B in the hopes that his mailer will
> somehow change its behavior.  I think this is absurd.

It is. I'm sorry, it has been a bad day. I redraw.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA22393 for ietf-mta-filters-bks; Thu, 20 Nov 1997 04:13:01 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA22388 for <[e-mail]>; Thu, 20 Nov 1997 04:12:55 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id NAA19721 for <[e-mail]>; Thu, 20 Nov 1997 13:13:55 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 1997 13:14:18 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Paul Hethmon wrote:

> RFC 1123 Section 5.2.8:
> 
>          When the receiver-SMTP makes "final delivery" of a message,
>          then it MUST pass the MAIL FROM: address from the SMTP envelope
>          with the message, for use if an error notification message must
>          be sent later (see Section 5.3.3).  There is an analogous
>          requirement when gatewaying from the Internet into a different
>          mail environment; see Section 5.3.7.

Thanks. I redraw my objection.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA11202 for ietf-mta-filters-bks; Wed, 19 Nov 1997 12:43:57 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA11198 for <[e-mail]>; Wed, 19 Nov 1997 12:43:52 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA00420 for <[e-mail]>; Wed, 19 Nov 1997 15:44:41 -0500 (EST)
Date: Wed, 19 Nov 1997 15:44:41 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 19 Nov 1997, Tomas Fasth wrote:

> > >  * even those that do will have to know to ignore (obviously) empty
> > >    MAIL FROM addresses - so do implementations that support this action
> > >    need exception handlers to deal with an invalid return address? Or
> > >    simply silently disregard them?
> > 
> > This is already defined in the standards.  DSNs are not sent if there is
> > an empty "MAIL FROM" address, so "reject" would be equivlent to "discard"
> > in this case.
> 
> Ouch. Are you suggesting that the transfer from reject to discard would
> be
> done silently without giving a chance to the scripter to do something
> else?

Sure.  What would be more appropriate?  If you're going to refuse messages,
then you're really going to refuse messages.  If you don't want to refuse
messages, don't refuse messages.  What's the problem?

> > Agreed.  But Sieve is designed for much more than just
> > UCE/UBE/SPAM/whatever. See my previous message for why a "bounce/reject"
> > action provides vital functionality.
> 
> Don't you think an automatic repetitive reject (whatever cause) can be
> regarded as a kind of spam?

No, it's not spam in any sense of the word -- it's not unsolicited.

> What guarantee do you have that the receiver
> of the delivery rejection notification know how to handle such a message?

What do you intend by this?  How can someone not be ready to handle a bounce
message?

> If the traffic is fluent, s/he might instead (wrongly but possibly)
> decide
> to order his filtering device to reject such stream of junk mail which,
> as
> you decribed above, might result in a silent discard because the lack of
> an originator address.

Good.

> We now have a stream of messages taking up network resources and with no
> other purpose than using brute force (using automating tools) to
> convince
> a fellow netizen to stop sending messages. Some might regard that as
> spamming as well.

They would be wrong for all of the reasons described above.

What you're saying is that if A sends B a mesasge, and B sets up his mailer
to reject A's messages, and A sets up his mailer to reject B's rejects, that
A is likely to keep sending mail to B in the hopes that his mailer will
somehow change its behavior.  I think this is absurd.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA09772 for ietf-mta-filters-bks; Wed, 19 Nov 1997 11:09:53 -0800 (PST)
Received: from mail.hethmon.com (mail.hethmon.com [208.147.156.6]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA09768 for <[e-mail]>; Wed, 19 Nov 1997 11:09:49 -0800 (PST)
Received: from sambo.ag.utk.edu ( [128.169.14.43] ) by mail.hethmon.com (Hethmon Brothers Smtpd) ; Wed, 19 Nov 1997 14:10:51 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0)
Date: Wed, 19 Nov 1997 14:11:04 -0500
From: Paul Hethmon <[e-mail]>
Reply-To: Paul Hethmon <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
Sender: [e-mail]
Precedence: bulk

** Reply to note from Tomas Fasth <[e-mail]> Wed, 19 Nov 19=
97 17:06:33 +0100


> > This is incorrect.  UAs will have access to the "MAIL FROM" address unl=
ess 
> > an upstream system violated Internet standards.  The final delivery age=
nt 
> > is REQUIRED to copy the "MAIL FROM" address into the "Return-Path" 
> > header.  Anything which doesn't is broken. 
>  
> Chris, can you give us the exact location in an RFC that backs up your 
> assertion? I'm not sure it is required and I'm not sure you can ever 
> rely 
> on it's existence once the message have moved into the domain of the 
> MUA. 
>  
> If you're right, my FreeBSD "out-of-the-box" installation is certainly 
> broken. The "P" flag required to generate the Return-Path header is 
> _not_ 
> set for the local mailer by default. I don't know why, but the very 
> existence of this discrepency (the fact that it's optional) is enough 
> for 
> me to maintain that this header might not always be available. Period.

RFC 1123 Section 5.2.8:

         When the receiver-SMTP makes "final delivery" of a message,
         then it MUST pass the MAIL FROM: address from the SMTP envelope
         with the message, for use if an error notification message must
         be sent later (see Section 5.3.3).  There is an analogous
         requirement when gatewaying from the Internet into a different
         mail environment; see Section 5.3.7.

         DISCUSSION:
              Note that the final reply to the DATA command depends only
              upon the successful transfer and storage of the message.
              Any problem with the destination address(es) must either
              (1) have been reported in an SMTP error reply to the RCPT
              command(s), or (2) be reported in a later error message
              mailed to the originator.

         IMPLEMENTATION:
              The MAIL FROM: information may be passed as a parameter or
              in a Return-Path: line inserted at the beginning of the
              message.


Paul



-------------------------------------------------------------------------
Position Announcement: Needed hardworking person with organizational
skills, devotion to OS/2, plenty of spare time. No pay, no benefits.
Apply by self-nomination :-)
-------------------------------------------------------------------------
Paul Hethmon                                         [e-mail]
Inet.Mail Internet Mail Server                     http://www.hethmon.com
-------------------------------------------------------------------------
Author "Illustrated Guide to HTTP" http://www.browsebooks.com/Hethmon?882
-------------------------------------------------------------------------
Warpstock    --    Tune In! & Warp Out!    --    http://www.warpstock.org



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA09611 for ietf-mta-filters-bks; Wed, 19 Nov 1997 10:55:44 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA09606 for <[e-mail]>; Wed, 19 Nov 1997 10:55:40 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id NAA23807 for <[e-mail]>; Wed, 19 Nov 1997 13:56:26 -0500 (EST)
Date: Wed, 19 Nov 1997 13:56:25 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: Example extension action
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 19 Nov 1997, Tomas Fasth wrote:

> Tim Showalter wrote:
> 
> > The only problem I can see is that in IMAP messages are essentially
> > immutable so that once the delivery agent had written to the message
> > store, it's never gonna change.
> 
> I don't regard this as a problem but a feature.
> If you want to change the content of a message, including it's headers,
> you have to make a copy, making your changes in that copy and store it
> in the same place, probably also deleting the original message.
> By being forced to do it this way, you are not breaking any cached
> messages in MUAs running in disconnected mode (have those creatures
> been invented yet by the way?).

Ok; it was the only worry I had about modifying headers in the filtering
agent.  I withdraw it.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA07358 for ietf-mta-filters-bks; Wed, 19 Nov 1997 08:32:12 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA07353 for <[e-mail]>; Wed, 19 Nov 1997 08:32:08 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id RAA18363 for <[e-mail]>; Wed, 19 Nov 1997 17:33:08 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 1997 17:33:31 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: ietf-mta-filters <[e-mail]>
Subject: Why not notify instead?
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Instead of using bounce/reject, which could be seen as one among
several notifications, you could instead define a notify command in
Sieve. The notify command would then encapsulate all notifications
including address change, denial of delivery and such.

Like this:
if header "from" contains "enemy"
{ notify-originator delivery-denied "Keep your messages to yourself!"; }

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA07045 for ietf-mta-filters-bks; Wed, 19 Nov 1997 08:13:46 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA07039 for <[e-mail]>; Wed, 19 Nov 1997 08:13:41 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id RAA18231 for <[e-mail]>; Wed, 19 Nov 1997 17:14:41 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 1997 17:15:04 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: MTA Filters <[e-mail]>
Subject: Re: Example extension action
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> The only problem I can see is that in IMAP messages are essentially
> immutable so that once the delivery agent had written to the message
> store, it's never gonna change.

I don't regard this as a problem but a feature.
If you want to change the content of a message, including it's headers,
you have to make a copy, making your changes in that copy and store it
in the same place, probably also deleting the original message.
By being forced to do it this way, you are not breaking any cached
messages in MUAs running in disconnected mode (have those creatures
been invented yet by the way?).

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA06922 for ietf-mta-filters-bks; Wed, 19 Nov 1997 08:05:14 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA06918 for <[e-mail]>; Wed, 19 Nov 1997 08:05:10 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id RAA18186 for <[e-mail]>; Wed, 19 Nov 1997 17:06:11 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 1997 17:06:33 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Chris Newman wrote:

> This is incorrect.  UAs will have access to the "MAIL FROM" address unless
> an upstream system violated Internet standards.  The final delivery agent
> is REQUIRED to copy the "MAIL FROM" address into the "Return-Path"
> header.  Anything which doesn't is broken.

Chris, can you give us the exact location in an RFC that backs up your
assertion? I'm not sure it is required and I'm not sure you can ever
rely
on it's existence once the message have moved into the domain of the
MUA.

If you're right, my FreeBSD "out-of-the-box" installation is certainly
broken. The "P" flag required to generate the Return-Path header is
_not_
set for the local mailer by default. I don't know why, but the very
existence of this discrepency (the fact that it's optional) is enough
for
me to maintain that this header might not always be available. Period.

> >  * even those that do will have to know to ignore (obviously) empty
> >    MAIL FROM addresses - so do implementations that support this action
> >    need exception handlers to deal with an invalid return address? Or
> >    simply silently disregard them?
> 
> This is already defined in the standards.  DSNs are not sent if there is
> an empty "MAIL FROM" address, so "reject" would be equivlent to "discard"
> in this case.

Ouch. Are you suggesting that the transfer from reject to discard would
be
done silently without giving a chance to the scripter to do something
else?

> Agreed.  But Sieve is designed for much more than just
> UCE/UBE/SPAM/whatever. See my previous message for why a "bounce/reject"
> action provides vital functionality.

Don't you think an automatic repetitive reject (whatever cause) can be
regarded as a kind of spam? What guarantee do you have that the receiver
of
the delivery rejection notification know how to handle such a message?
If the traffic is fluent, s/he might instead (wrongly but possibly)
decide
to order his filtering device to reject such stream of junk mail which,
as
you decribed above, might result in a silent discard because the lack of
an originator address.
We now have a stream of messages taking up network resources and with no
other purpose than using brute force (using automating tools) to
convince
a fellow netizen to stop sending messages. Some might regard that as
spamming as well.

My point is; when demanding new and powerful functionality in a tool
that
will become available to average end users, you should at least consider
the side (and less wanted) effects and consequences before having it
implemented. Just because it seem like a cool feature, it does not
necessary
equal to a useful one. Especially if you mix features from different
problem
domains in the same implementation entity. That is only going to cause
trouble.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA06156 for ietf-mta-filters-bks; Wed, 19 Nov 1997 07:15:18 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA06150 for <[e-mail]>; Wed, 19 Nov 1997 07:15:10 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id QAA18053 for <[e-mail]>; Wed, 19 Nov 1997 16:16:06 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 1997 16:16:29 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Example extension action
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Chris Newman wrote:

> If the message has a "Disposition-Notification-To" header which matches
> the envelope sender, then this will send an "automatic-ation",
> "MDN-sent-automatically", "denied" MDN notification and remove the
> "Disposition-Notification-To" header from the message.

Nice thinking, Chris.
However, it seem to me quite counter-productive to do a thing like that.
When we finally can see MUAs arriving on the market that supports MDN
(we
aren't there quite yet) you start providing not only tools that
nullifies
those developments, but also automates MDN submission on behalf of the
user
for each message containing the D-N-T header?

Also, as I mentioned in another letter, I am leaning towards the
position
that MTAs should keep hands off MDNs and leave such handling to the MUA.
If your MUA is not supporting MDNs, then why not just ignore such
requests?

A question: Should MTA and MUA responsibilities be mixed up in a single
tool
like a Sieve interpreter?

> The interesting question is: are Sieve scripts allowed to edit the headers
> of a message?

I hope not. Otherwise, you will easily end up with a situation similar
to
sendmail installations, where you easily loose control over what headers
are
rewritten (or deleted, help me ***) and why.

Frankly, I don't understand why a filtering language should be able to
rewrite message headers at all?

Morphing filtering tools into censoring tools have bad vibrations.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA05223 for ietf-mta-filters-bks; Wed, 19 Nov 1997 06:04:56 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA05219 for <[e-mail]>; Wed, 19 Nov 1997 06:04:51 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id PAA17972 for <[e-mail]>; Wed, 19 Nov 1997 15:05:49 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 19 Nov 1997 15:06:11 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Why bounce/reject is necessary
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Chris Newman wrote:
> 
> The crucial difference between bounce/reject and reply is that the
> envelope sender is used.  There are two cases where it is very important
> to use that rather than the reply-to/from header:
> 
> (1) Change of address.

Hmm. This is certainly a service we have wanted in MTAs for a long time.
What I don't understand is why this would be solved within the domain of
message filtering?
In a sense the mail account might not exist anymore, therefore the need
to notify about an address change in the first place. It might not be
appropriate to apply a filter at all, because the maildrop have ceased
to exist.
Therefore I do not consider the need to notify a change of address as a
valid argument for making reject mandatory.

> (2) Rejecting a mailing list which won't unsubscribe you.

Great. Just because most MUAs don't give the user a choice of sending
replies to the MAIL FROM address, you now mandate an automatic junk
duplicator. I am maintaining my position that automation of junk mail
rejection (== traffic duplicator) is not a good solution to that kind
of a problem. Discard isn't either, but not as bad.

> In either of these cases a "reply" function is actually the wrong thing to
> do, as it would go to the author of the message rather than the mailing
> list owner.

I agree.

> So I think bounce/reject is critical functionality in Sieve and is
> important independent of reply.

I think not. It should at least not be mandatory.

> I also think it should use DSN syntax.  I'm looking forward to the day
> when MUAs can automatically associate DSNs and MDNs with the messages that
> generated them.

I can agree with that. Thinking about it, MDNs have properties that are
better suited to be integrated in the MUA overall funtionality, not in a
filtering language.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
Tel: [phone] Cel: [phone] Fax: [phone]
EuroNetics Operation, Mjärdevi Science Park, 58330 Linköping, Sweden
(TwinSpot Network is a subsidiary of EuroNetics Operation)


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA22133 for ietf-mta-filters-bks; Tue, 18 Nov 1997 12:58:54 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA22129 for <[e-mail]>; Tue, 18 Nov 1997 12:58:50 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA11529; Tue, 18 Nov 1997 15:59:12 -0500 (EST)
Date: Tue, 18 Nov 1997 15:59:12 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: Chris Newman <[e-mail]>
cc: [e-mail]
Subject: Re: Why bounce/reject is necessary
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Mon, 17 Nov 1997, Chris Newman wrote:

> I also think it should use DSN syntax.  I'm looking forward to the day
> when MUAs can automatically associate DSNs and MDNs with the messages that
> generated them.

Ok, the draft says DSN syntax.  I'll try to release another draft in the
next day or two, mostly so that the expiration date is correct.

Should it say SHOULD or MUST?


-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA22116 for ietf-mta-filters-bks; Tue, 18 Nov 1997 12:57:43 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA22109 for <[e-mail]>; Tue, 18 Nov 1997 12:57:24 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA11456 for <[e-mail]>; Tue, 18 Nov 1997 15:58:09 -0500 (EST)
Date: Tue, 18 Nov 1997 15:58:08 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: Example extension action
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Mon, 17 Nov 1997, Chris Newman wrote:

> Here's an example extension action that raises an interesting question:
> 
> The action is called "denyMDN".  Based on: draft-ietf-receipt-mdn-06.txt
> 
> If the message has a "Disposition-Notification-To" header which matches
> the envelope sender, then this will send an "automatic-ation",
> "MDN-sent-automatically", "denied" MDN notification and remove the
> "Disposition-Notification-To" header from the message.
> 
> The interesting question is: are Sieve scripts allowed to edit the headers
> of a message?

Sure, why not?

The only problem I can see is that in IMAP messages are essentially
immutable so that once the delivery agent had written to the message store,
it's never gonna change.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA05360 for ietf-mta-filters-bks; Mon, 17 Nov 1997 14:35:06 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA05353 for <[e-mail]>; Mon, 17 Nov 1997 14:34:59 -0800 (PST)
Received: from eleanor.innosoft.com ("port 50216"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Mon, 17 Nov 1997 14:34:39 PST
Date: Mon, 17 Nov 1997 14:36:52 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Re: Re[2]: bounce, mta, & mua (was Re: sieve draft)
In-reply-to: <[e-mail]>
To: Chris Bartram <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [e-mail]
Precedence: bulk

On Wed, 5 Nov 1997, Chris Bartram wrote:
>  * most UAs will not have access to the SMTP "MAIL FROM" address anyway,
>   which is where DSNs are *supposed* to go

This is incorrect.  UAs will have access to the "MAIL FROM" address unless
an upstream system violated Internet standards.  The final delivery agent
is REQUIRED to copy the "MAIL FROM" address into the "Return-Path" 
header.  Anything which doesn't is broken. 

>  * even those that do will have to know to ignore (obviously) empty
>    MAIL FROM addresses - so do implementations that support this action
>    need exception handlers to deal with an invalid return address? Or
>    simply silently disregard them?

This is already defined in the standards.  DSNs are not sent if there is
an empty "MAIL FROM" address, so "reject" would be equivlent to "discard"
in this case.

>  * using this action in response to a UCE/SPAM message will almost NEVER
>   be useful, and in most cases will make the problem/impact worse

Agreed.  But Sieve is designed for much more than just
UCE/UBE/SPAM/whatever. See my previous message for why a "bounce/reject"
action provides vital functionality.

		- Chris




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA05225 for ietf-mta-filters-bks; Mon, 17 Nov 1997 14:23:59 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA05221 for <[e-mail]>; Mon, 17 Nov 1997 14:23:43 -0800 (PST)
Received: from eleanor.innosoft.com ("port 50165"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Mon, 17 Nov 1997 14:23:55 PST
Date: Mon, 17 Nov 1997 14:26:08 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Example extension action
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [e-mail]
Precedence: bulk

Here's an example extension action that raises an interesting question:

The action is called "denyMDN".  Based on: draft-ietf-receipt-mdn-06.txt

If the message has a "Disposition-Notification-To" header which matches
the envelope sender, then this will send an "automatic-ation",
"MDN-sent-automatically", "denied" MDN notification and remove the
"Disposition-Notification-To" header from the message.

The interesting question is: are Sieve scripts allowed to edit the headers
of a message?

		- Chris





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA05033 for ietf-mta-filters-bks; Mon, 17 Nov 1997 14:09:15 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA05025 for <[e-mail]>; Mon, 17 Nov 1997 14:09:07 -0800 (PST)
Received: from eleanor.innosoft.com ("port 50164"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <[e-mail]> for [e-mail]; Mon, 17 Nov 1997 14:09:33 PST
Date: Mon, 17 Nov 1997 14:11:46 -0800 (PST)
From: Chris Newman <[e-mail]>
Subject: Why bounce/reject is necessary
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [e-mail]
Precedence: bulk

The crucial difference between bounce/reject and reply is that the
envelope sender is used.  There are two cases where it is very important
to use that rather than the reply-to/from header:

(1) Change of address.
(2) Rejecting a mailing list which won't unsubscribe you.

In either of these cases a "reply" function is actually the wrong thing to
do, as it would go to the author of the message rather than the mailing
list owner.

So I think bounce/reject is critical functionality in Sieve and is
important independent of reply.

I also think it should use DSN syntax.  I'm looking forward to the day
when MUAs can automatically associate DSNs and MDNs with the messages that
generated them.

		- Chris

P.S. I think it's pointless to argue at what point Sieve is executed.  As
long as we know what objects it operates on, its function is well defined.



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA25153 for ietf-mta-filters-bks; Thu, 6 Nov 1997 09:20:08 -0800 (PST)
Received: from po10.andrew.cmu.edu (PO10.ANDREW.CMU.EDU [128.2.10.110]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA25149 for <[e-mail]>; Thu, 6 Nov 1997 09:20:02 -0800 (PST)
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.5/8.8.2) id MAA01393 for [e-mail]; Thu, 6 Nov 1997 12:20:03 -0500 (EST)
Received: via switchmail; Thu,  6 Nov 1997 12:20:03 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.0oMTkN200WC700ZUE0>; Thu,  6 Nov 1997 12:19:21 -0500 (EST)
Received: from loiosh.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr17/rob/.Outgoing/QF.0oMTkF200WC7080qI0>; Thu,  6 Nov 1997 12:19:13 -0500 (EST)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.loiosh.andrew.cmu.edu.HP9000.715 via MS.5.6.loiosh.andrew.cmu.edu.hp700; Thu,  6 Nov 1997 12:19:03 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu,  6 Nov 1997 12:19:03 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: {} in if/else
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Face: ,IWr.&S`]#R'C+7U:UE~"}g?Zq|OE%6.\}jCwGUO)]|?34%u!8RT_@0"_qA\@g8N:'pK!bM tSE)?S,#@MK1$o(69wQT2L'j)8tP5QfHdYlh`k}:tA"%dG?9z~>
Beak: Is Not
Organization: cmu
X-URL: http://www.contrib.andrew.cmu.edu/~rob
Sender: [e-mail]
Precedence: bulk

Tim Showalter <[e-mail]> writes:
> What happens in this script --
> 
> if false keep; else if false fileinto "foo"; else trash

  trash.  You only run into ambiguities if you can write things like

    if false if false fileinto "foo"; else trash

  where it's not clear which "if" the else belongs to.

  (The problem is that if-then-else is hard to specify unambiguously
in a context-free grammar (although it's certainly possible).  In
practice, though, it tends to work fine - yacc, for instance, will
complain about the shift/reduce conflict, but will default to shifting
the else token, which is exactly what should happen.)

  )Rob


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15384 for ietf-mta-filters-bks; Wed, 5 Nov 1997 22:29:29 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA15378 for <[e-mail]>; Wed, 5 Nov 1997 22:29:25 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id BAA21715; Thu, 6 Nov 1997 01:29:13 -0500 (EST)
Date: Thu, 6 Nov 1997 01:29:12 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: Chris Bartram <[e-mail]>
cc: [e-mail]
Subject: Re: {} in if/else
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 5 Nov 1997, Chris Bartram wrote:

>  In <[e-mail]> [e-mail] writes:
> 
> > So can I change the grammar to require the braces around commands in an
> > if/else?
> >
> > That is,
> >         if true keep;
> >
> > wouldn't be legal; you'd need
> >         if true { keep; }
> 
> Why???

Because it's slightly easier to parse.

Actually, I need to deal with an ambiguity in the grammar with regards to
this.  What happens in this script --

if false keep; else if false fileinto "foo"; else trash


Also, there are two similar looking lists -- a list of tests, which is
comma-seperated like "(true, false)" and a list of strings, which looks like
("a string" "another string" "yet another string").  I had been told to get
rid of one of them.  Any opinions on this?

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12816 for ietf-mta-filters-bks; Wed, 5 Nov 1997 18:37:44 -0800 (PST)
Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.7/8.7.3) with SMTP id SAA12812 for <[e-mail]>; Wed, 5 Nov 1997 18:37:41 -0800 (PST)
From: "Chris Bartram" <[e-mail]>
Organization: 3k Associates
Reply-To: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: NetMail/3000 [Version B.06 97/10/28]
MIME-Version: 1.0
Content-Type: Text/Plain
Date: Wed,  5 Nov 1997 21:37:24 -0500
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re[2]: bounce, mta, & mua (was Re: sieve draft)
To: [e-mail]
Sender: [e-mail]
Precedence: bulk

 In <[e-mail]> [e-mail] writes:

Warning; long, rambling response follows:    ;-)

> > > My desire would be that filtering could be inserted at almost any stage.
> > > If the result of the filter is that the message is going to be rejected
> > > or rerouted, then better to catch it as early as possible before the bits
> > > have crossed the wires.
> > >
> > > However, it is true that the farther you get from the recipient MUA, the
> > > less likely the user is to get control over the disposition of messages.
> >
> > Is it reasonable to believe that this could be done in a robust and safe
> > way? I fear such a dream can easily turn into a nightmare if not
> > carefully
> > analysed before implemented.
>
> Procmail has done a fairly decent job and presents roughly the same dangers,
> and I think it has even more potential to shoot users in the feet.  But I
> haven't used it, and haven't even looked at the documentation much...

We have implemented filtering in our mail system, both at the MTA (SMTP)
level (i.e. global filter rules that can *truly* bounce messages based on
invalid return[from/reply-to/sender] addresses and a few other rules) as
well as the MTA/UA level (i.e. individuals can define rulesets that apply to
messages which have been deposited in their "mailbox" -though before the
messages are viewable by the UA). User-invoked rules can file/forward/
delete/various other actions, and are based on a syntax similar to what has
been proposed; though our rules are entered into our system via a GUI that
prevents the entry of actions we don't support (therefore my earlier object-
ions to the necessity of parsing/storing rules or actions that our system
does not support). As a side note, I still don't see a use for requiring
us to preserve actions/rules that our system will not process *unless* there
is also some standard extension (say for POP or IMAP) where clients can
download their "stored" rulesets from the server upon connection... I don't
see that happening here.

The "MTA"(SMTP) level filtering refuses to accept messages, i.e. we actually
return a 5xx error in response to the "DATA" smtp command, forcing the sending
system to deal with the "bounce". Messages bounced this way never make it as
far as an individual's mailbox. In turn, the filters at this level must be
"global" since the MTA is operating on "the" instance of the message (before
it is split and delivered to the -perhaps many- individuals designated as
the recipients). This kind of bounce forces the overhead/problems of bad
-or forged- return addresses onto the sending machine -- as opposed to the
local system having to queue a *new* message attempting to deliver a notice
to (the reported) sender of the original message.

A note; as one that deals intimately with alot of SPAM, more and more of these
"people" are using the (legal and difficult to filter otherwise):
  MAIL FROM:<>
(i.e. empty return address) to foil normal DSNs and bounces. A UA (even one
that has managed to find out/preserve the SMTP "MAIL FROM" address is often
going to encounter this on exactly the type of messages a user would most
often want to refuse. Queueing a new message to deliver a DSN using this
address won't work.

  I don't object (too much) to a "reject" action as a special form of a
"reply" action (which as I mentioned, *will* cause alot of problems to mail
administrators, though nonetheless is a potentially useful function) but don't
try to fool yourselves (or potential users invoking this action) into thinking
that this action is at all useful in reference to any UCE/SPAM. And there
will certainly need to be implementation notes describing some of the draw-
backs;
 * most UAs will not have access to the SMTP "MAIL FROM" address anyway,
  which is where DSNs are *supposed* to go
 * even those that do will have to know to ignore (obviously) empty
   MAIL FROM addresses - so do implementations that support this action
   need exception handlers to deal with an invalid return address? Or
   simply silently disregard them?
 * using this action in response to a UCE/SPAM message will almost NEVER
  be useful, and in most cases will make the problem/impact worse

Even a reply action is gonna need to be able to handle exceptions; even non-
SPAM messages sometimes have invalid reply addresses, and if your "auto-
responder" (action using reply) can't complete because of an invalid address
(i.e. a bogus domain or something) then there should be an option that the
rules could do something else... Final word; if it's gonna be done, do it
right. :-)

             -Chris Bartram



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12328 for ietf-mta-filters-bks; Wed, 5 Nov 1997 18:03:09 -0800 (PST)
Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.7/8.7.3) with SMTP id SAA12323 for <[e-mail]>; Wed, 5 Nov 1997 18:03:05 -0800 (PST)
From: "Chris Bartram" <[e-mail]>
Organization: 3k Associates
Reply-To: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: NetMail/3000 [Version B.06 97/10/28]
MIME-Version: 1.0
Content-Type: Text/Plain
Date: Wed,  5 Nov 1997 21:02:26 -0500
X-Hpdesk-Priority: 3 (Normal Priority)
Subject: Re: {} in if/else
To: [e-mail]
Sender: [e-mail]
Precedence: bulk

 In <[e-mail]> [e-mail] writes:

> So can I change the grammar to require the braces around commands in an
> if/else?
>
> That is,
>         if true keep;
>
> wouldn't be legal; you'd need
>         if true { keep; }

Why???

      -Chris Bartram
       3k Associates, Inc.



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA06974 for ietf-mta-filters-bks; Wed, 5 Nov 1997 13:04:08 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA06970 for <[e-mail]>; Wed, 5 Nov 1997 13:04:02 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA29251 for <[e-mail]>; Wed, 5 Nov 1997 16:03:55 -0500 (EST)
Date: Wed, 5 Nov 1997 16:03:55 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: {} in if/else
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

So can I change the grammar to require the braces around commands in an
if/else?

That is,
	if true keep;

wouldn't be legal; you'd need
	if true { keep; }

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA02065 for ietf-mta-filters-bks; Wed, 5 Nov 1997 09:13:14 -0800 (PST)
Received: from deptvamc2-bh.va.gov (deptvachi-bh.va.gov [205.183.31.66]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA02060 for <[e-mail]>; Wed, 5 Nov 1997 09:13:10 -0800 (PST)
Received: (from uucp@localhost) by deptvamc2-bh.va.gov (8.6.12/8.6.11) id LAA25796 for <[e-mail]>; Wed, 5 Nov 1997 11:13:08 -0600
Received: from 152.129.1.6 by deptvamc2-bh.va.gov via smap (3.2) id xmab25616; Wed, 5 Nov 97 11:13:05 -0600
Received: by vhaishhbexc1.med.va.gov with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <[e-mail]>; Wed, 5 Nov 1997 11:17:19 -0600
Message-ID: <c=US%a=_%p=VA%l=[e-mail]>
From: "Woodhouse, Gregory J." <[e-mail]>
To: "'Tomas Fasth'" <[e-mail]>, "'Tim Showalter'" <[e-mail]>
Cc: "'MTA Filters'" <[e-mail]>
Subject: RE: bounce, mta, & mua (was Re: sieve draft)
Date: Wed, 5 Nov 1997 11:17:25 -0600
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Indeed. I'm a big fan of procmail, but I always warn people (maybe to 
excess) to be very careful when first setting up procmail and to get 
someone to help them through the process if at all possible. I don't 
know if mail filtering with any sort of rewrite capability can be made 
"safe" in this sense. (Sorry, if I miss the point here - I've been 
unable to study sieve in detail just yet because of other fires). 
Perhaps an informational RFC listing caveats for implementing mail 
filtering would be in order.

===
Gregory Woodhouse
San Francisco CIO Field Office - Infrastructure
[e-mail]
[phone]


----------
From:  Tim Showalter [SMTP:[e-mail]]
Sent:  Wednesday, November 05, 1997 1:03 AM
To:  Tomas Fasth
Cc:  MTA Filters
Subject:  Re: bounce, mta, & mua (was Re: sieve draft)


[...]

Procmail has done a fairly decent job and presents roughly the same 
dangers,
and I think it has even more potential to shoot users in the feet. 
 But I
haven't used it, and haven't even looked at the documentation much...

[...]




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA22766 for ietf-mta-filters-bks; Wed, 5 Nov 1997 01:03:18 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA22761 for <[e-mail]>; Wed, 5 Nov 1997 01:03:14 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id EAA03362; Wed, 5 Nov 1997 04:03:07 -0500 (EST)
Date: Wed, 5 Nov 1997 04:03:05 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: Tomas Fasth <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 5 Nov 1997, Tomas Fasth wrote:

> > My desire would be that filtering could be inserted at almost any stage.
> > If the result of the filter is that the message is going to be rejected
> > or rerouted, then better to catch it as early as possible before the bits
> > have crossed the wires.
> > 
> > However, it is true that the farther you get from the recipient MUA, the
> > less likely the user is to get control over the disposition of messages.
> 
> Is it reasonable to believe that this could be done in a robust and safe
> way? I fear such a dream can easily turn into a nightmare if not
> carefully
> analysed before implemented.

Procmail has done a fairly decent job and presents roughly the same dangers,
and I think it has even more potential to shoot users in the feet.  But I
haven't used it, and haven't even looked at the documentation much...

> > } On Sun, 3 Nov 1996, Tomas Fasth wrote:
> > }
> > } Rationale: I don't understand the difference between MTA and MUA filtering.
> 
> Just for the record: I (Tomas Fasth) did not made the qouted statement
> above or any of the consecutive qouted statements. I think it was Tim
> that made those statements.

I made this statement.

I think bounce (or reject) has utility, although I'd like to hear more
concrete examples.  Bart Schaefer's examples seem valid enough, but I'm
wavering a bit.  I'm inclined to make it optional.

-- 
                                           Tim Showalter [e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA22605 for ietf-mta-filters-bks; Wed, 5 Nov 1997 00:52:12 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA22599 for <[e-mail]>; Wed, 5 Nov 1997 00:52:08 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id DAA03180 for <[e-mail]>; Wed, 5 Nov 1997 03:52:03 -0500 (EST)
Date: Wed, 5 Nov 1997 03:52:03 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: bounce -> reject
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 5 Nov 1997, Tomas Fasth wrote:

> Tim Showalter wrote:
> > 
> > I have no problem with renaming "bounce" to something more descriptive;
> > "bounce" is already used for other commands anyway ("bounce" in pine, for
> > instance).
> > 
> > Would "reject" be okay?
> 
> Yes, I think that's more descriptive than "bounce".
> Are you going to make DSN the mandatory format for a reject?

I'm not sure.  Should I?  (didn't I?)

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA22579 for ietf-mta-filters-bks; Wed, 5 Nov 1997 00:51:22 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA22573 for <[e-mail]>; Wed, 5 Nov 1997 00:51:18 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id DAA03146; Wed, 5 Nov 1997 03:51:09 -0500 (EST)
Date: Wed, 5 Nov 1997 03:51:09 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: Tomas Fasth <[e-mail]>
cc: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Wed, 5 Nov 1997, Tomas Fasth wrote:

> > Why shouldn't they?  They have all the envelope information they need.
> > If a message can't be given to the user but was delivered to the mail store,
> > the POP client is probably the only program that knows why.
> 
> Tim, I understand that, with the exception that Return-Path: might
> not be available and you may therefore not be able to conform to the
> following quote from RFC 1894 chapter 2 page 7 2nd paragraph:
> "
>    The DSN MUST be addressed (in both the message header and the
>    transport envelope) to the return address from the transport envelope
>    which accompanied the original message for which the DSN was
>    generated.  (For a message that arrived via SMTP, the envelope return
>    address appears in the MAIL FROM command.)
> "

821 says MTAs write the MAIL FROM address into the Return-Path header.
While I can imagine an MTA that violated this, it's unlikely that a site
would want filtering and be unwilling to upgrade to a slightly more
compliant MTA.

> Anyway, a POP client generating DSN's does not make much sense to me.
> The message has already reached it's destination, nothing can be done
> to prevent a delivery.

But in what context has it hit its destination?

> > No, I don't.  Prohibitions against configuring your mailer to do something
> > dumb are not typically part of protocol documentation.
> 
> Hmm. You might not want to prohibit.
> But you might want to discourage inappropriate usage.

How?  The only thing I can think of is something that suggests users try
avoiding doing dumb things, and that's rather difficult.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA16456 for ietf-mta-filters-bks; Tue, 4 Nov 1997 16:15:28 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA16452 for <[e-mail]>; Tue, 4 Nov 1997 16:15:23 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id BAA07800 for <[e-mail]>; Wed, 5 Nov 1997 01:15:42 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 1997 01:15:53 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: MTA Filters <[e-mail]>
Subject: Re: bounce -> reject
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:
> 
> I have no problem with renaming "bounce" to something more descriptive;
> "bounce" is already used for other commands anyway ("bounce" in pine, for
> instance).
> 
> Would "reject" be okay?

Yes, I think that's more descriptive than "bounce".
Are you going to make DSN the mandatory format for a reject?

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA16414 for ietf-mta-filters-bks; Tue, 4 Nov 1997 16:12:44 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA16410 for <[e-mail]>; Tue, 4 Nov 1997 16:12:39 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id BAA07788 for <[e-mail]>; Wed, 5 Nov 1997 01:12:49 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 1997 01:12:59 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> } Would making "bounce" optional help?
> 
> I don't think so.  One could still construct and send a DSN using other
> seive tools, so making it optional just makes it more difficult to do
> the action, not impossible.

I would suggest to do exactly that. Even make it an extension.
(Oh, I think I already stated that in another mail)
It would give the result you describe above, which I would like
to see happen. Then it might be concieved as a not so normal action,
and might not be as frequently abused by mistake as it might be
otherwise.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA15934 for ietf-mta-filters-bks; Tue, 4 Nov 1997 15:38:43 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA15930 for <[e-mail]>; Tue, 4 Nov 1997 15:38:37 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id AAA07750 for <[e-mail]>; Wed, 5 Nov 1997 00:38:57 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 1997 00:39:07 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:
> 
> I believe the model that other IETF groups are aiming for is more like
> 
>         [Sender MUA] -> [Submission Agent] ->
>             [chain of zero or more Transport Agents] ->
>                 [Delivery Agent] -> [Recipient MUA]
> 
> There is active work on separating message relay (as happens in the chain
> of transport agents) from message submission.
> 
> However, I think both the Submission and Delivery agents are legitimately
> considered part of the transport system.

Thanks Bart for the clarification. I can accept that model. It seem to
me that [Delivery Agent] is more or less equal to a [Message Store], if
one equals [Recipient MUA] with an IMAP client.

> My desire would be that filtering could be inserted at almost any stage.
> If the result of the filter is that the message is going to be rejected
> or rerouted, then better to catch it as early as possible before the bits
> have crossed the wires.
> 
> However, it is true that the farther you get from the recipient MUA, the
> less likely the user is to get control over the disposition of messages.

Is it reasonable to believe that this could be done in a robust and safe
way? I fear such a dream can easily turn into a nightmare if not
carefully
analysed before implemented.

> } On Sun, 3 Nov 1996, Tomas Fasth wrote:
> }
> } Rationale: I don't understand the difference between MTA and MUA filtering.

Just for the record: I (Tomas Fasth) did not made the qouted statement
above or any of the consecutive qouted statements. I think it was Tim
that made those statements.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA15671 for ietf-mta-filters-bks; Tue, 4 Nov 1997 15:17:09 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA15667 for <[e-mail]>; Tue, 4 Nov 1997 15:17:04 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id AAA07725 for <[e-mail]>; Wed, 5 Nov 1997 00:17:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 05 Nov 1997 00:17:26 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> Sieve is designed to filter a message at time of "final delivery", a
> deliberately open-ended term concocted to make it clear that it's supposed
> to happen just before the message hits the message store, and only happen
> once.  I think this is enough.

Okay. I won't argue about that.

> > An interesting question: are POP clients supposed to be able to
> > generate DSN's? That might put some arguments on it's head. :-)
> 
> Why shouldn't they?  They have all the envelope information they need.
> If a message can't be given to the user but was delivered to the mail store,
> the POP client is probably the only program that knows why.

Tim, I understand that, with the exception that Return-Path: might
not be available and you may therefore not be able to conform to the
following quote from RFC 1894 chapter 2 page 7 2nd paragraph:
"
   The DSN MUST be addressed (in both the message header and the
   transport envelope) to the return address from the transport envelope
   which accompanied the original message for which the DSN was
   generated.  (For a message that arrived via SMTP, the envelope return
   address appears in the MAIL FROM command.)
"

Anyway, a POP client generating DSN's does not make much sense to me.
The message has already reached it's destination, nothing can be done
to prevent a delivery.

> No, I don't.  Prohibitions against configuring your mailer to do something
> dumb are not typically part of protocol documentation.

Hmm. You might not want to prohibit.
But you might want to discourage inappropriate usage.

> Sieve scripts should be portable, and I know of no case where this isn't
> true (other than the lack of non-INBOX-like mailboxes if a Sieve script is
> run on a POP server).

Okay, I take that back.
I think I ment broken in the sense of doing undesirable actions.

> Sieve was designed to be run on the server when the message is delivered as
> part of the MTA.  My definition of MTA is broader than yours; I think the
> MTA writes to the mail store, you think the mail store takes the message
> from the MTA.

So, we have to live with that. I won't push it any further.

> Bounce can be implemented easily by any program that can connect to an SMTP
> server given an RFC822 message, to the best of my knowledge.

Right. Writing a program is one thing. Giving end users the power of
bouncing is another. This is something that have a potential of
becoming available to millions of users.

And I still don't understand why an end user would want to cause an
automatic bounce. Why is this a desirable action? Your argument seem
to be that it can be technically done, therefore it have to be
provided.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA14354 for ietf-mta-filters-bks; Tue, 4 Nov 1997 14:13:01 -0800 (PST)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA14338 for <[e-mail]>; Tue, 4 Nov 1997 14:12:55 -0800 (PST)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id OAA16025 for [e-mail]; Tue, 4 Nov 1997 14:12:46 -0800
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 4 Nov 1997 14:12:46 -0800
In-Reply-To: <[e-mail]>
Comments: In reply to Tim Showalter <[e-mail]> "Re: bounce, mta, & mua (was Re: sieve draft)" (Nov  4,  3:37pm)
References: <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

On Nov 4,  3:37pm, Tim Showalter wrote:
> Subject: Re: bounce, mta, & mua (was Re: sieve draft)
> On Tue, 4 Nov 1997, Bart Schaefer wrote:
> 
> > In the real world, POP3 drops
> > are sometimes overloaded to deliver messages to an entire domain, e.g.
> > as a "replacement" for UUCP.
> 
> How do sites like this handle mailing lists, BCCs, and the like?

Very poorly, if at all.  Some implementations of delivery agents insert
extra information in the message headers, which is then hopefully stripped
out by the POP3 client on the other end.  Eric Raymond, the author of
fetchmail, was asking about this on another ietf list recently; and I
believe Dan Bernstein, author of the qmail-mta, said his MTA already uses
a custom header-field protocol for passing envelope information across
POP3.


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA13374 for ietf-mta-filters-bks; Tue, 4 Nov 1997 13:23:04 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA13370 for <[e-mail]>; Tue, 4 Nov 1997 13:23:00 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id QAA06191 for <[e-mail]>; Tue, 4 Nov 1997 16:22:51 -0500 (EST)
Date: Tue, 4 Nov 1997 16:22:50 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 4 Nov 1997, Tim Showalter wrote:

> On Tue, 4 Nov 1997, Bart Schaefer wrote:
> Ok; I never considered SMTP-level filtering seriously.  Which is why there's
> an implicit assumption that the agent has the entire message.

Er, this is misleading; I'm sorry.  I didn't consider it at all.  Nor do I
wish to dismiss it.  The draft doesn't handle it.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12768 for ietf-mta-filters-bks; Tue, 4 Nov 1997 12:37:54 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA12764 for <[e-mail]>; Tue, 4 Nov 1997 12:37:50 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA03480 for <[e-mail]>; Tue, 4 Nov 1997 15:37:44 -0500 (EST)
Date: Tue, 4 Nov 1997 15:37:43 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 4 Nov 1997, Bart Schaefer wrote:

> } On Sun, 3 Nov 1996, Tomas Fasth wrote:
> } 
> } Rationale: I don't understand the difference between MTA and MUA filtering.
> 
> I see two differences:
> 
> 1.  An MTA may not have access to all the UA's mailboxes.
> 
> 2.  An MUA can't reject/reroute at the transport protocol level.

Ok; I never considered SMTP-level filtering seriously.  Which is why there's
an implicit assumption that the agent has the entire message.

> The significant difference is that, even if the envelope sender in the
> Return-Path is correct, the POP3 client has no access to the envelope
> *recipients*.  In an ideal world, that makes little difference, because
> every recipient has his own POP3 maildrop.  In the real world, POP3 drops
> are sometimes overloaded to delivery messages to an entire domain, e.g.
> as a "replacement" for UUCP.
> 
> Of course, there's little the Seive language can do about that, except
> to make it easier for the ISP in such situations to provide server-side
> filtering.

How do sites like this handle mailing lists, BCCs, and the like?

Should Sieve handle this?  (I don't want to, but should it?)

> } Would making "bounce" optional help?
> 
> I don't think so.  One could still construct and send a DSN using other
> seive tools, so making it optional just makes it more difficult to do
> the action, not impossible.

OK; I was suggesting this as a policy choice as much as a technichal choice.

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12646 for ietf-mta-filters-bks; Tue, 4 Nov 1997 12:32:47 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA12641 for <[e-mail]>; Tue, 4 Nov 1997 12:32:43 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA03209 for <[e-mail]>; Tue, 4 Nov 1997 15:32:37 -0500 (EST)
Date: Tue, 4 Nov 1997 15:32:36 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: bounce -> reject
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I have no problem with renaming "bounce" to something more descriptive;
"bounce" is already used for other commands anyway ("bounce" in pine, for
instance).

Would "reject" be okay?

(Tomas: sorry for missing this earlier.)

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12627 for ietf-mta-filters-bks; Tue, 4 Nov 1997 12:31:46 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA12615 for <[e-mail]>; Tue, 4 Nov 1997 12:31:38 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id PAA03152; Tue, 4 Nov 1997 15:31:21 -0500 (EST)
Date: Tue, 4 Nov 1997 15:31:21 -0500 (EST)
From: Tim Showalter <[e-mail]>
To: Tomas Fasth <[e-mail]>, MTA Filters <[e-mail]>
Subject: Re: Comment on draft-showalter-sieve-02.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Tue, 4 Nov 1997, Jack De Winter wrote:

> in the context that you have described, I would agree.  however,
> in other contexts, I can see how it would be a hinderance rather
> than a help.

At best, it's possible to look up syntax errors well before running the
script.  At worst, it's possible to look at errors just milliseconds before
running the script.  All implementations should do this, as getting halfway
into a script and realizing that there's no } on that if is a bad thing.

(This is my problem with require, which effectively mandates an extra
interpretation step to find requires.)

-- 
                                           Tim Showalter [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08544 for ietf-mta-filters-bks; Tue, 4 Nov 1997 08:43:27 -0800 (PST)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA08539 for <[e-mail]>; Tue, 4 Nov 1997 08:43:21 -0800 (PST)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id IAA14918 for [e-mail]; Tue, 4 Nov 1997 08:43:08 -0800
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 4 Nov 1997 08:43:07 -0800
In-Reply-To: <[e-mail]>
Comments: In reply to Tim Showalter <[e-mail]> "bounce, mta, & mua (was Re: sieve draft)" (Nov  3,  5:05pm)
References: <[e-mail]>
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

On Nov 3,  5:05pm, Tim Showalter wrote:
} Subject: bounce, mta, & mua (was Re: sieve draft)
}
} So that is, for most users.
} 	[a message in Sender MUA]->[Sender MTA]->
} 		[Receiver MTA]->[{something}]->[Receiver MUA]

I believe the model that other IETF groups are aiming for is more like

	[Sender MUA] -> [Submission Agent] ->
	    [chain of zero or more Transport Agents] ->
		[Delivery Agent] -> [Recipient MUA]

There is active work on separating message relay (as happens in the chain
of transport agents) from message submission.

However, I think both the Submission and Delivery agents are legitimately
considered part of the transport system.

} I consider the "something" to be part of the MTA because it is transferring
} the message.  But I really don't care.  My desire is that somewhere in
} "something" is a filtering agent.

My desire would be that filtering could be inserted at almost any stage.
If the result of the filter is that the message is going to be rejected
or rerouted, then better to catch it as early as possible before the bits
have crossed the wires.

However, it is true that the farther you get from the recipient MUA, the
less likely the user is to get control over the disposition of messages.
 
} On Sun, 3 Nov 1996, Tomas Fasth wrote:
} 
} Rationale: I don't understand the difference between MTA and MUA filtering.

I see two differences:

1.  An MTA may not have access to all the UA's mailboxes.

2.  An MUA can't reject/reroute at the transport protocol level.

} I believe the difference between MTA and MUA filtering, where the filtering
} agent has the entire message, is more or less meaningless.

The Seive draft is written with the assumption that filtering happens at
delivery time, so that it's already too late for (2).  But (1) remains a
problem:

} In a POP3 system where filtering has to be done where remote folders
} are stored, filtering is done by the client.  Both are equally capable
} of sorting mail into folders, generating a reply and submitting it to
} an SMTP server, of throwing the message away, and of generating a DSN.

The significant difference is that, even if the envelope sender in the
Return-Path is correct, the POP3 client has no access to the envelope
*recipients*.  In an ideal world, that makes little difference, because
every recipient has his own POP3 maildrop.  In the real world, POP3 drops
are sometimes overloaded to delivery messages to an entire domain, e.g.
as a "replacement" for UUCP.

Of course, there's little the Seive language can do about that, except
to make it easier for the ISP in such situations to provide server-side
filtering.

} Would making "bounce" optional help?

I don't think so.  One could still construct and send a DSN using other
seive tools, so making it optional just makes it more difficult to do
the action, not impossible.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08502 for ietf-mta-filters-bks; Tue, 4 Nov 1997 08:41:07 -0800 (PST)
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 IAA08497 for <[e-mail]>; Tue, 4 Nov 1997 08:40:55 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 4 Nov 1997 11:36:33 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 4 Nov 1997 11:36:32 -0500
Message-Id: <[e-mail]>
X-Sender: "Unverified" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Nov 1997 11:42:50 -0500
To: Tomas Fasth <[e-mail]>, Bart Schaefer <[e-mail]>
From: "Jack De Winter" <[e-mail]>
Subject: Re: sieve draft
Cc: Tim Showalter <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:32 PM 11/2/96 +0100, Tomas Fasth wrote:
>Bart Schaefer wrote:
>
>> It's certainly possible to handle it that way.  However, note that there
>> are nonzero costs associated with accepting delivery.  If the typical
>> message to my hypothetical support service contains a many-megabyte
>> coredump (and I have direct experience with users who mail such things
>> to support addresses), I'd much rather refuse delivery altogether than
>> have to consume the bandwidth to accept the message and then discard it.
>
>I can see your point.
>
>But in order to avoid consuming bandwidth you need to apply the
>filtering rules as part of SMTP negotiation. The information
>available at that point will limit your filtering rules to operate
>on the addresses of the originator and the recipients as negotiated
>by MAIL and RCPT, and possibly some peer information.

well, if I remember one of the discussion at the conference in
Memphis right, the problem occured if mail was send to A and B,
where A and B had different sets of filtering rules.  you would
have to accept both of them, and then apply another filtering
after the message duplication had occured.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/jacks/



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08479 for ietf-mta-filters-bks; Tue, 4 Nov 1997 08:40:21 -0800 (PST)
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 IAA08468 for <[e-mail]>; Tue, 4 Nov 1997 08:40:10 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 4 Nov 1997 11:34:19 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 4 Nov 1997 11:34:18 -0500
Message-Id: <[e-mail]>
X-Sender: "Unverified" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Nov 1997 11:40:36 -0500
To: "Bart Schaefer" <[e-mail]>, Tomas Fasth <[e-mail]>, [e-mail] (Tim Showalter)
From: "Jack De Winter" <[e-mail]>
Subject: Re: sieve draft
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 09:35 PM 10/31/97 -0800, Bart Schaefer wrote:
>On Nov 1,  3:02am, Tomas Fasth wrote:
>}
>} What other than spam would be a subject for delivery refusal?
>
>Some examples:
>
>I run an email customer support service.  Customers with paid support can
>legitimately send mail to [e-mail].  All other messages
>sent to that address are bounced, with the suggestion that they pay up.
>(No, I don't really run such a service.  These are examples.)

another example is anyone who owns a mailing list.  I would love to
be able to set up a sieve script that handled legitimate users and
bounce users that are not on the lists.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/jacks/



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA08449 for ietf-mta-filters-bks; Tue, 4 Nov 1997 08:39:08 -0800 (PST)
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 IAA08445 for <[e-mail]>; Tue, 4 Nov 1997 08:38:59 -0800 (PST)
Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 4 Nov 1997 11:33:03 -0500
Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 4 Nov 1997 11:33:01 -0500
Message-Id: <[e-mail]>
X-Sender: "Unverified" <[e-mail]>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 04 Nov 1997 11:39:19 -0500
To: Tomas Fasth <[e-mail]>
From: "Jack De Winter" <[e-mail]>
Subject: Re: Comment on draft-showalter-sieve-02.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>My personal view is that syntax errors should be caught before the
>script is put to work. I am not willing to equal this particular
>situation with avarage execution of command shell scripts.
>These scripts are about to execute in batch mode as part of a
>delivery process.
>An good example is aliases as used by sendmail. The aliases file
>have to be processed before being put into the message dispatch
>process. Syntax errors are reported to the operator. The alias
>lookup mechanism in sendmail does not have to deal with
>syntactical errors.
>Why not apply a similar requirement on filtering?

in the context that you have described, I would agree.  however,
in other contexts, I can see how it would be a hinderance rather
than a help.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
[phone]		http://www.wildbear.on.ca/jacks/



Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA27789 for ietf-mta-filters-bks; Mon, 3 Nov 1997 19:24:15 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA27784 for <[e-mail]>; Mon, 3 Nov 1997 19:24:11 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id WAA26900 for <[e-mail]>; Mon, 3 Nov 1997 22:24:02 -0500 (EST)
Date: Mon, 3 Nov 1997 22:24:02 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Please don't CC me on list messages.  I'm subscribed to the list, and it's a
little annoying.

On Tue, 4 Nov 1997, Tomas Fasth wrote:

> Tim Showalter wrote:
> 
> > Nailing it down limits the applicability of the draft. What does it change?
> 
> Hmm, would rather say that it makes the applicability clearer for
> the implementors. But it depends on how specialized or generic you
> want Sieve to be. I think Sieve is enough special to deserve an
> explaination in what circumstances it is intended to be used.

I really don't agree with this.  Systems that say, "Don't use this unless
you're in this position" don't get used.  It seems silly.

The major places where this could be used would be an IMAP server, a POP
client, or a Unix system using whatever local mail facilities are availible
(something more sophisticated than, say, Berkley mailspools).

> > Rationale: I don't understand the difference between MTA and MUA filtering.
> 
> I admit, it _is_ confusing.

I'd argue that it doesn't exist.  I see no difference between pre-delivery
filtering and post-delivery filtering because I can't see the perceptible,
on-the-wire difference between a filter running at SMTP level as a part of
the SMTP agent and a filter running on the end of a pipe from sendmail.  One
is SMTP, the other just happens to convey the same information and take an
RFC822 format message.

Sieve is designed to filter a message at time of "final delivery", a
deliberately open-ended term concocted to make it clear that it's supposed
to happen just before the message hits the message store, and only happen
once.  I think this is enough.

> An interesting question: are POP clients supposed to be able to
> generate DSN's? That might put some arguments on it's head. :-)

Why shouldn't they?  They have all the envelope information they need.
If a message can't be given to the user but was delivered to the mail store,
the POP client is probably the only program that knows why.

> > So don't do that.  (This would be a major configuration error.)
>
> Ah, but then, wouldn't it be a good thing to make a clarification
> on when a set of rules is considered a major configuration error
> and when not?

No, I don't.  Prohibitions against configuring your mailer to do something
dumb are not typically part of protocol documentation.

> What bothers me is that this spec is about to become a base for
> several different implementations. I would recommend to design
> Sieve in such a way that it will not become broken when shifting
> from one implementation to another.

Sieve scripts should be portable, and I know of no case where this isn't
true (other than the lack of non-INBOX-like mailboxes if a Sieve script is 
run on a POP server).

> In this particular case, I asked for a clarification in what
> contexts Sieve is to be designed for. If the context is not
> clear, we might end up with a language causing more trouble
> than joy.

Please provide an example.  Bounce isn't it; it's not hard to generate a DSN
given an RFC822 message, which you have anyway.

Sieve was designed to be run on the server when the message is delivered as
part of the MTA.  My definition of MTA is broader than yours; I think the
MTA writes to the mail store, you think the mail store takes the message
from the MTA.

That said, I do not believe that "bounce" represents an ambiguity in Sieve's
role.  MTA, MUA, and other X.400-derived terms are useful for labeling parts
of an Internet mail system, but are not authoritive, or even rigerously
defined, or in the case of many specifications, defined (or used) at all.

Bounce can be implemented easily by any program that can connect to an SMTP
server given an RFC822 message, to the best of my knowledge.

-- 
                                           Tim Showalter [e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA27661 for ietf-mta-filters-bks; Mon, 3 Nov 1997 19:17:15 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA27656 for <[e-mail]>; Mon, 3 Nov 1997 19:17:11 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id EAA06597; Tue, 4 Nov 1997 04:17:25 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 1997 04:17:32 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> I have made mistakes with the bounce command.  At the very least, would
> changing bounce so that
> 
>         * only one bounce per message
>         * performing a bounce restricts all other actions
> 
> make things better?

I think that if bounce stays in the spec, it should be a terminal
action. That is, no further action allowed on the current message.
Otherwise, you will easily end up in all sorts of more or less
confusing situations. There are considerations to be done when
you want to be conformant to the DSN spec.

> Would making "bounce" optional help?

Yes, that would help a lot. I even want it to be an extension.
By doing that, the ambiguity in it's operation is no longer part
of the base spec.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA27522 for ietf-mta-filters-bks; Mon, 3 Nov 1997 19:07:52 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA27515 for <[e-mail]>; Mon, 3 Nov 1997 19:07:47 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id EAA06586; Tue, 4 Nov 1997 04:08:02 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 1997 04:08:09 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> > In the case of sendmail, the final delivery is actually done by a
> > separate program (mail, rmail, mail.local). I would not include
> > that program in the domain of an MTA.
> 
> Why not?  It's certainly moving an RFC-822 compliant* message from one point
> to another, even if it's not via SMTP.
> 
> (* More or less, anyway.)

Hmm. It's not really about who has monopoly on moving messages around.
It's about what domains of responsibility the message is passing
through.
My view is that an MTA is not responsible of doing final delivery on
the local machine. Only to identify that the destination of the message
is local and then pass the message to the message store, (possibly using
a delivery agent ;-)

> > And in the end, what all my rioting in this thread have been
> > leading up to is my assertion that Sieve is actually executing
> > in the context of the message store, beyond the point where a
> > message have been delivered by the MTA but before the point were
> > it has been filed. Therefore a message cannot be bounced, only
> > handled by performing a drop, reply or store.
> 
> Why?  What's the difference?  There is no prohibition of sending message
> status notifications from outside SMTP.

The difference is in how I define pre- and post-delivery processing.
Pre- is doing accept-reject decisions, post- is doing management
tasks. But that might be considered academical hair-splitting by
some.

> > Even if you allow to execute Sieve in a context where it is
> > possible to reject a delivery, you still have a problem when the
> > same set of rules are about to run on the MUA-level.
> 
> So don't do that.  (This would be a major configuration error.)

Ah, but then, wouldn't it be a good thing to make a clarification
on when a set of rules is considered a major configuration error
and when not? Or maybe you suggest this to be addressed by the
implementation documentation. Which might be a better place
after all... Hmm.

What bothers me is that this spec is about to become a base for
several different implementations. I would recommend to design
Sieve in such a way that it will not become broken when shifting
from one implementation to another.

In this particular case, I asked for a clarification in what
contexts Sieve is to be designed for. If the context is not
clear, we might end up with a language causing more trouble
than joy.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA26998 for ietf-mta-filters-bks; Mon, 3 Nov 1997 18:22:09 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA26993 for <[e-mail]>; Mon, 3 Nov 1997 18:22:05 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id DAA06537; Tue, 4 Nov 1997 03:22:20 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 1997 03:22:28 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:

> Nailing it down limits the applicability of the draft. What does it change?

Hmm, would rather say that it makes the applicability clearer for
the implementors. But it depends on how specialized or generic you
want Sieve to be. I think Sieve is enough special to deserve an
explaination in what circumstances it is intended to be used.

> Rationale: I don't understand the difference between MTA and MUA filtering.

I admit, it _is_ confusing.
I have been asserting that there are a difference, of which I have
tried to explain my view on what the differences are. But that does
not mean that I am the one to be right. Therefore, this discussion
helps a lot to put things in perspective.

When you bring up Cyrus as an example of MTA filtering you should
note that although the filtering is typically done by using the
.forward mechanism calling something like procmail, it could just
as well have been done by the deliver(8) program, which is
distributed as part of the cyrus package, which I essentially
regard as a system for message storage.

Personally I regard the POP3 protocol as a a maildrop forwarding
protocol. The end user are therefore restricted to perform post-
delivery filtering only when the maildrop have been forwarded to
where the message store is situated and where access to personal
folders is possible. In the case of a POP client, this is the
same as the local PC (or equivalent).

An interesting question: are POP clients supposed to be able to
generate DSN's? That might put some arguments on it's head. :-)

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA26618 for ietf-mta-filters-bks; Mon, 3 Nov 1997 17:41:27 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA26614 for <[e-mail]>; Mon, 3 Nov 1997 17:41:22 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id CAA06494; Tue, 4 Nov 1997 02:41:33 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 1997 02:41:40 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: MTA Filters <[e-mail]>
Subject: Re: bounce, mta, & mua (was Re: sieve draft)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Tim Showalter wrote:
> 
> MTA is a misleading term.  If the only part of the MTA is the SMTP server,
> what happens between MTAs and MUAs?  There's stuff there, even if it's just
> a program that appends to a file.  You say it's not part of the MTA.  It's
> clearly not part of the MUA.  But it is a part of the SMTP model; it is as
> important as the MUA and the MTA, but it's not getting the recognition it
> deserves.

Yes, I think you're right, it definitely deserves a better recognition.
Not the least these days when the requirements is much higher on the
internet messaging model then it was in the earlier days. Everybody
would gain from having a more accurate model to work with.

> So that is, for most users.
>         [a message in Sender MUA]->[Sender MTA]->
>                 [Receiver MTA]->[{something}]->[Receiver MUA]

I would like to call the "something" a message store.
Although it's a term borrowed from the OSI model, it makes sense.
Someone suggested delivery agent, but I would regard that as the
mediator between the message transfer agent and the message store.

The presence of a message store is easier to understand today when
we have IMAP to play with. In particular, IMAP's capability to move
around messages between multiple mailboxes on the server side.
It seem not appropriate to say that the MTA is involved in such
post-delivery tasks. IMAP can be said to be the access protocol
to the message store.

> I consider the "something" to be part of the MTA because it is transferring
> the message.  But I really don't care.  My desire is that somewhere in
> "something" is a filtering agent.

Eventually it all comes down to how we define things. My view on an
nternet messaging system is most probably not the correct one. But
I do think the exercise of trying to find the least incorrect one
might pay off in a cleaner design of it's components such as Sieve.

I think filtering agent is a good term for an entity responsible
to perform rule-based filtering. Agent because it does the filtering
on behalf of someone, presumably the end user.

If I would choose a place for filtering agents to reside in, it
would be the message store. The reason is because this is the only
place where you have access to the end user's mail folders.

I was opposing a bounce action as part of a filtering rule primarily
because I thought it to be performed as a post-delivery event. My
view of filtering was as a service for the end user to organize the
flow of incoming messages to his/her maildrop.

The more I spend time on this issue, the more I get a feeling that
most of the words spent sofar have it's origin from one or more
misunderstanding. Early on there was a discussion on whether a
bounce was a kind of a reply or not. Their similarity might not
be important after all. From my point of view they seem to be in
contexts that are mutually exclusive to each other. So, were a
bounce is a valid action, reply is not. And vice versa.

It might be good to recognize in the draft that Sieve might be
put in use in either pre-delivery or post-delivery processing.

In the case of pre-delivery processing, it's all about to decide
whether the delivery will succeed or not. A bounce action will
generate a DSN as described in the draft. As a matter of fact,
after re-reading the DSN spec (RFC 1894) it might be an idea to
rename that action to fail or failed to better match the
intended use of DSN. This seem to be a task for the MTA.
(Or may be the message delivery agent, MDA ;-)

In the case of post-delivery processing, the task is to help
the end user to organize incoming messages in a configurable
way, including moving messages to different mail folders.

I would suggest to identify the transfer point between pre- and
post-delivery to be the maildrop. Before the message have reached
the maildrop, an end user can only accept or reject a message.
After the message have reached the maildrop, the message have
been successfully delivered and can therefore not be rejected.
What's left is for the end user to decide how to handle the
message.

I would suggest to not allow a bounce action in post-delivery
processing of incoming messages, only reply action.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA22287 for ietf-mta-filters-bks; Mon, 3 Nov 1997 14:05:42 -0800 (PST)
Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA22278 for <[e-mail]>; Mon, 3 Nov 1997 14:05:36 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id RAA12720 for <[e-mail]>; Mon, 3 Nov 1997 17:05:24 -0500 (EST)
Date: Mon, 3 Nov 1997 17:05:23 -0500 (EST)
From: Tim Showalter <[e-mail]>
Reply-To: Tim Showalter <[e-mail]>
To: MTA Filters <[e-mail]>
Subject: bounce, mta, & mua (was Re: sieve draft)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I've trimmed the CC line because I don't need multiple copies of messages.
If there are a number of followers of the thread who aren't subscribed, I'm
sorry.


If you find a good definition of MTA and MUA, please let me know.  The
definitions in 1123, if I recall correctly, are because people were using
them; they're very vague.

MTA is a misleading term.  If the only part of the MTA is the SMTP server,
what happens between MTAs and MUAs?  There's stuff there, even if it's just
a program that appends to a file.  You say it's not part of the MTA.  It's 
clearly not part of the MUA.  But it is a part of the SMTP model; it is as
important as the MUA and the MTA, but it's not getting the recognition it
deserves.

So that is, for most users.
	[a message in Sender MUA]->[Sender MTA]->
		[Receiver MTA]->[{something}]->[Receiver MUA]

I consider the "something" to be part of the MTA because it is transferring
the message.  But I really don't care.  My desire is that somewhere in
"something" is a filtering agent.

On Sun, 3 Nov 1996, Tomas Fasth wrote:

> Still, I thought it to have been unclear when this MTA-level
> filtering was about to take place. [...]

Nailing it down limits the applicability of the draft.  What does it change?

Rationale: I don't understand the difference between MTA and MUA filtering.
In some systems (say, Cyrus) things will be done essentially by the MTA
(before the message ever hits a user-accessible mailbox).  In a POP3 system
where filtering has to be done where remote folders are stored, filtering is
done by the client.  Both are equally capable of sorting mail into folders,
generating a reply and submitting it to an SMTP server, of throwing the
message away, and of generating a DSN.

> In the case of sendmail, the final delivery is actually done by a
> separate program (mail, rmail, mail.local). I would not include
> that program in the domain of an MTA. 

Why not?  It's certainly moving an RFC-822 compliant* message from one point
to another, even if it's not via SMTP.

(* More or less, anyway.)

> And in the end, what all my rioting in this thread have been
> leading up to is my assertion that Sieve is actually executing
> in the context of the message store, beyond the point where a
> message have been delivered by the MTA but before the point were
> it has been filed. Therefore a message cannot be bounced, only
> handled by performing a drop, reply or store.

Why?  What's the difference?  There is no prohibition of sending message
status notifications from outside SMTP.

> Even if you allow to execute Sieve in a context where it is
> possible to reject a delivery, you still have a problem when the
> same set of rules are about to run on the MUA-level.

So don't do that.  (This would be a major configuration error.)

> It is not mandatory to keep the address to the SMTP originator
> beyond the point of delivery, so it might not be available when
> you are about to initiate a bounce.

Actually, the Return-Path line is for that purpose.

> Therefore, in the case of mailing list exploders, you may not
> know by what address the message was delivered to you, which
> makes a bounce pointless, because you may not have access to
> the return-path nor the recipient address (which may be needed
> to fix the cause of rejection).

You mail the mailing list exploder which has written its address into the
Return-Path line.

> Was Sieve really intended to do SMTP-level filtering as well?
> Or was this only a wild idea raised in the heat of the debate?

I hadn't put enough thought into this.  You can't filter a message until you
have a copy of the message (mostly).  So my intention was that the message
would have to leave SMTP before being checked with a Sieve script.

I believe the difference between MTA and MUA filtering, where the filtering
agent has the entire message, is more or less meaningless.


I have made mistakes with the bounce command.  At the very least, would
changing bounce so that

	* only one bounce per message
	* performing a bounce restricts all other actions

make things better?

Would making "bounce" optional help?

-- 
                                           Tim Showalter [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA14310 for ietf-mta-filters-bks; Mon, 3 Nov 1997 05:32:21 -0800 (PST)
Received: from gatekeeper.cca.rockwell.com ([e-mail] [205.175.225.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA14304 for <[e-mail]>; Mon, 3 Nov 1997 05:32:16 -0800 (PST)
Received: by gatekeeper.cca.rockwell.com; id HAA22051; Mon, 3 Nov 1997 07:31:48 -0600
Received: from crnotes.cca.rockwell.com(131.198.213.32) by gatekeeper.cca.rockwell.com via smap (3.2) id xma022044; Mon, 3 Nov 97 07:31:23 -0600
Received: by crnotes.cca.rockwell.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997))  id 86256544.005955B9 ; Mon, 3 Nov 1997 07:31:09 -0600
X-Lotus-FromDomain: ROCKWELL
From: "Richard J Holland"<[e-mail]>
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 1 Nov 1997 11:47:02 -0600
Subject: Re: sieve draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

On 10/31/97 at 11:35pm, Bart Schaefer ([e-mail]) wrote:

>} Actually, can you give examples of any other filtering tools that
>} allow a bounce action that is distinguishable from a reply action?
>
> A reply action is typically directed to addresses taken from the
> RFC822 header of the message, e.g. the "From" or "Reply-To" fields.
> A bounce is typically directed to the envelope sender, e.g. the SMTP
> "MAIL FROM" address.  There presently aren't many (if any) tools that >
are able to make that distinction, because there are few MTA-level
> filtering tools; almost all must run "post-delivery" without access
> to the SMTP envelope.  One purpose of the sieve language, as I
> understand it, is to enable the user to intervene *before* the MTA
> delivers the message, thus making it *possible* to have distinguished >
"bounce" and "reply" actions.
Actually, the only difference between a bounce and a reply is the address
you're sending to.  For example, if my MTA (e.g. sendmail) gives the
message to my delivery agent, it passes the envelope information to the
delivery agent in most cases.  What the delivery agent does with it is
totally arbitrary.

If a delivery agent wants to "bounce" the message, it should reply to the
ENVELOPE sender address.  It could also reply to the Errors-To: header
address, but that's generally there for backward compatibility with older
systems these days.

If the delivery agent wants to "reply" to the message, it should look first
at the Reply-To: header, and if it's not there, it should look at the
Sender: header, and if it's not there, it should look at the From: header,
and if all of these are absent, THEN it should fall back on the ENVELOPE
sender address, as a last resort.

This is a fairly subtle distinction, and a "bounce" usually happens at the
MTA level (i.e. sendmail says "I don't know about this user" and returns a
"550 - User unknown..." over the socket, so that the sender's MTA generates
a local "bounce" message.  But there's nothing that says you can't generate
a "bounce" from you local delivery agent, instead of at the MTA level.
This puts the work of generating the message back on your MTA however, and
is something to consider at large sites.

Regarding Tom's original query looking for examples of other filtering
tools that allow a bounce action instead of a reply action, I've got one
that I wrote here as a mail delivery agent in perl5.  It's used for
"bouncing" plain-english explanatory messages to senders when a recipient
username is changed.  We do it at the MDA level instead of the MTA level
because in most cases, we want to forward the message on to the recipient's
new address, but we want to let the sender know it changed, so we forward
the message and "bounce" (or "reply" -- it's now an
administrator-configurable option) a copy of the message back to the sender
with a nice explanation of what's happening...

Rich Holland
Rockwell Collins, Inc.




Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA06348 for ietf-mta-filters-bks; Sun, 2 Nov 1997 17:14:22 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA06344 for <[e-mail]>; Sun, 2 Nov 1997 17:14:17 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id CAA05011; Mon, 3 Nov 1997 02:14:26 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 03 Nov 1996 02:14:32 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> } My point is that if we use this description as a model, message
> } delivery is just about to find the correct maildrop. That makes
> } the task of the MTA much less complicated.
> 
> The name of this mailing list *is* ietf-mta-filters.  Have we all decided
> that we're not talking about MTA-level filtering any more?

Good point. I have been questioning the overall concept of
MTA-level filtering. Which might not be a very good idea on a
list dedicated to the task of doing exactly that. If I have been
out of line here I appologize for that.

Still, I thought it to have been unclear when this MTA-level
filtering was about to take place. Reading one of my earlier
postings in this thread, I recognize my own confusion, mixing it
up with MUA-level filtering. My eager to argue, and therefore
showering this list with several postings on the same subject,
comes partly from my assumption that Sieve was going to be used
in the context of UA-level filtering.

But I seem to have been partly wrong. The Sieve draft states:
"
   Implementations of the language are expected to take place at time of
   final delivery, when the message is finally moved to the user-
   accessible mailbox.  In systems where the MTA does final delivery,
   such as and traditional UNIX mail, is reasonable to sort when the MTA
   deposits mail into the user's mailbox.  If the MTA does not do final
   delivery, or lacks the power to sort into separate mailboxes, as is
   the case under POP3, the MUA must do filtering into local-disk
   folders.
"

It seem to me that the text about an MTA doing a final delivery
is misleading. It might be the case that a monolithically designed
program is performing several tasks, among them SMTP handshake,
message routing, and local delivery. But this is not the same as
saying that the MTA is doing this and that.
In the case of sendmail, the final delivery is actually done by a
separate program (mail, rmail, mail.local). I would not include
that program in the domain of an MTA. 
On Unix systems it's sometimes not very easy to recognize the
borders between different components within the mail subsystem.
Still, I would like categorize the mail.local, pop and imap
programs as part of the message store, not the message transport
agent.

You might think I am one of those idealistic OSI guys, but I
ensure you, I'm not. I just like to have some order in the
terminology we are using here.

And in the end, what all my rioting in this thread have been
leading up to is my assertion that Sieve is actually executing
in the context of the message store, beyond the point where a
message have been delivered by the MTA but before the point were
it has been filed. Therefore a message cannot be bounced, only
handled by performing a drop, reply or store.

Even if you allow to execute Sieve in a context where it is
possible to reject a delivery, you still have a problem when the
same set of rules are about to run on the MUA-level.
It is not mandatory to keep the address to the SMTP originator
beyond the point of delivery, so it might not be available when
you are about to initiate a bounce.
Therefore, in the case of mailing list exploders, you may not
know by what address the message was delivered to you, which
makes a bounce pointless, because you may not have access to
the return-path nor the recipient address (which may be needed
to fix the cause of rejection).

If something good have come out of this thread, it might be the
distiction between SMTP-level filtering, MTA-level filtering and
MUA-level filtering.
The SMTP-level for processing filtering rules prior message
transfer. The MTA-level for processing after message transfer
but before local delivery (or possibly further relaying). The
MUA-level for post-delivery processing.

Was Sieve really intended to do SMTP-level filtering as well?
Or was this only a wild idea raised in the heat of the debate?

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA05624 for ietf-mta-filters-bks; Sun, 2 Nov 1997 15:11:34 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA05620 for <[e-mail]>; Sun, 2 Nov 1997 15:11:30 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id AAA04762; Mon, 3 Nov 1997 00:09:58 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 03 Nov 1996 00:10:04 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> I don't think there's any disagreement on the terms, merely on when it is
> appropriate to refuse.  And those are matters of opinion, not definition.

If you are about to design a message filtering language, it seem
essential to determine in what context the filtering is actually
taking place. Depending on the context, some operations, or actions,
may or may not be appropriate.

Therefore, it might be important to define those contexts, which
then might give us technical reasons for whether an action is
appropriate or not. Refuse is one such action in question.

I regard Sieve as a language to be used for a very specific
purpose, and is therefore not a generic language by definition.
We should therefore be very careful not to give it characteristics
that fall outside it's scope of use.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA05446 for ietf-mta-filters-bks; Sun, 2 Nov 1997 14:58:35 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA05441 for <[e-mail]>; Sun, 2 Nov 1997 14:58:31 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id XAA04744; Sun, 2 Nov 1997 23:58:38 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 02 Nov 1996 23:58:44 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> } Hmm. In this case I think your approach is unfriendly.
> 
> Note that I'm assuming that repeated polite requests have failed.  However,
> again it's not up to the language designers to decide what is or is not
> "friendly."

I can agree that language designers are not in a position to impose
any policies on the end user.

The question still lingers: Does this list have interest in pointing
out certain aspects of the Sieve draft that might not be appropriate
to have included, because of the possibility of being abused, or being
without practical use and therefore leading to confusion?

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA05148 for ietf-mta-filters-bks; Sun, 2 Nov 1997 14:10:19 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA05144 for <[e-mail]>; Sun, 2 Nov 1997 14:10:13 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id XAA04704; Sun, 2 Nov 1997 23:10:25 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 02 Nov 1996 23:10:32 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> Why would it be any harder to administer/maintain than a collection of
> individual services?  Especially if there is simply a seive script to be
> associated with each such address.

I did express a feeling more than a fact, I admit that.
And I was relying on my own sense of modular design, which is not
guaranteed to suite any other than myself ;-)

Still, while you can provide a mechanism to allow pre-delivery
filtering to be applied on individual addresses, it seem to me that
this is a very different problem domain compared to when providing
means for a user agent to apply filtering rules on the inbox messages.

Especially when you're applying rules as part of SMTP recipient
negotiation, as you described earlier. In such a context, using Sieve
seem to be a big overkill. Or at least, most of the capabilities in
Sieve seem to be non-applicable.

The probability of applying broken rules as part of MTA operation
seem to be much higher in that context, if you persist in using a
language spec identical to the current draft of Sieve. In that case,
yes, I'm pretty sure it will add a burden to the admin task.

Compare this to a post-delivery senario, where the responsibility
for filtering has shifted from the transport domain to the user
domain. The transport is complete, delivery is successful. The
postmaster don't have to bother about MTA malfunction because of
some obscure set of filtering rules injected by a user. Or the
other way around, he don't have to spend time proof-reading every
set of rules the users want him to inject into the MTA operation.

All this have significance, particularly in larger installations.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA04907 for ietf-mta-filters-bks; Sun, 2 Nov 1997 13:37:05 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA04902 for <[e-mail]>; Sun, 2 Nov 1997 13:37:01 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id WAA04667; Sun, 2 Nov 1997 22:37:10 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 02 Nov 1996 22:37:16 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> Hmm; having written that, I see that as presently written the sieve draft
> assumes that the message has already been "accepted" and that the bounce
> action merely resends it via a DSN.  In that case I agree that "bouncing"
> the message is much less interesting as a separate action.  However, I'm
> not convinced that there aren't valid reasons to want to use a DSN rather
> than an MDN to describe what has occurred.

My opinion is that once the message have been delivered, sending a
DSN would not make sense anymore. Not the least since communication
beyond the point of delivery should be regarded as end-to-end,
between end-users (or their agents). From that perspective, using
MDN seem more appropriate if you want to do any "out-of-band"
communication to the other end.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA04870 for ietf-mta-filters-bks; Sun, 2 Nov 1997 13:33:07 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA04866 for <[e-mail]>; Sun, 2 Nov 1997 13:33:03 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id WAA04658; Sun, 2 Nov 1997 22:32:46 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 02 Nov 1996 22:32:52 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]>  <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:

> It's certainly possible to handle it that way.  However, note that there
> are nonzero costs associated with accepting delivery.  If the typical
> message to my hypothetical support service contains a many-megabyte
> coredump (and I have direct experience with users who mail such things
> to support addresses), I'd much rather refuse delivery altogether than
> have to consume the bandwidth to accept the message and then discard it.

I can see your point.

But in order to avoid consuming bandwidth you need to apply the
filtering rules as part of SMTP negotiation. The information
available at that point will limit your filtering rules to operate
on the addresses of the originator and the recipients as negotiated
by MAIL and RCPT, and possibly some peer information.

I presume that you want to apply one set of rules for each recipient,
after first resolving the address for local delivery, but before
the point where the SMTP server have given a response to the RCPT
command. Am I correct?

If this is the case, a rule that resolve into an action other than
a simple "550 command rejected for policy reasons", has to be
postponed until the SMTP session has been completed, including a
"bounce" in the more reply-like fashion, since you need the complete
message or at least the message header section to complete the action.

I can sense an implementation obstacle here.
On the other hand, I have never tried to implement a complete MTA.
So who am I to write on people's noses how to do things? ;-)

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]
TwinSpot is a subsidiary of EuroNetics Operation in Sweden


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA25900 for ietf-mta-filters-bks; Sat, 1 Nov 1997 20:20:45 -0800 (PST)
Received: from candle.brasslantern.com ([e-mail] [206.155.48.241]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA25895 for <[e-mail]>; Sat, 1 Nov 1997 20:20:38 -0800 (PST)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id UAA03067; Sat, 1 Nov 1997 20:19:42 -0800
From: "Bart Schaefer" <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 1 Nov 1997 20:19:41 -0800
In-Reply-To: <[e-mail]>
Comments: In reply to Tomas Fasth <[e-mail]> "Re: sieve draft" (Nov  1, 11:07pm)
References: <[e-mail]>  <[e-mail]>  <[e-mail]>
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: Tomas Fasth <[e-mail]>
Subject: Re: sieve draft
Cc: Tim Showalter <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

On Nov 1, 11:07pm, Tomas Fasth wrote:
} Subject: Re: sieve draft
}
} Bart Schaefer wrote:
} > 
} > ... an email customer support service.  Customers with paid support can
} > legitimately send mail to [e-mail].  All other messages
} > sent to that address are bounced, with the suggestion that they pay up.
} 
} IMO, your example above is not a subject for delivery refusal.  [...]
} I suggest that a good design would be, from the MTA's point of view,
} to regard the message as being successfully delivered to the maildrop,
} which happens to have a service associated to it, a service which then
} decides by it's own access control whether to accept the service request
} or not.

It's certainly possible to handle it that way.  However, note that there
are nonzero costs associated with accepting delivery.  If the typical
message to my hypothetical support service contains a many-megabyte
coredump (and I have direct experience with users who mail such things
to support addresses), I'd much rather refuse delivery altogether than
have to consume the bandwidth to accept the message and then discard it.

My point is not that this is the best or only way to manage such a system,
merely that the bounce capability provides a useful alternative.  Whether
to permit it should be an administrative decision of the MTA maintainer,
not a decision of the language design -- unless there are other technical
reasons to omit it from the language.

Hmm; having written that, I see that as presently written the sieve draft
assumes that the message has already been "accepted" and that the bounce
action merely resends it via a DSN.  In that case I agree that "bouncing"
the message is much less interesting as a separate action.  However, I'm
not convinced that there aren't valid reasons to want to use a DSN rather
than an MDN to describe what has occurred.

} I would not recommend to make that kind of handling a business of the
} MTA. It would only be confusing and even hard to administer and
} maintain.

Why would it be any harder to administer/maintain than a collection of
individual services?  Especially if there is simply a seive script to be
associated with each such address.

} > I subscribed to the [e-mail] mailing list, but now I don't
} > want it any more.  I've sent a dozen unsubscribe requests, but nobody
} > is managing the list and it keeps coming to me.  I want to bounce the
} > messages back to the (admittedly unresponsive) list admin address and
} > to the [e-mail] in hopes of getting their attention.
} 
} Hmm. In this case I think your approach is unfriendly.

Note that I'm assuming that repeated polite requests have failed.  However,
again it's not up to the language designers to decide what is or is not
"friendly."

} I do not consider that a good use of filtering.

That is not a technical reason to leave the capability out of the language.

} I suggest we begin by distinguish between message delivery and
} message acceptance. By doing this we might be able to reach some
} kind of consensus on what we are trying to achieve here.

I don't think there's any disagreement on the terms, merely on when it is
appropriate to refuse.  And those are matters of opinion, not definition.

} My point is that if we use this description as a model, message
} delivery is just about to find the correct maildrop. That makes
} the task of the MTA much less complicated.

The name of this mailing list *is* ietf-mta-filters.  Have we all decided
that we're not talking about MTA-level filtering any more?

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA23525 for ietf-mta-filters-bks; Sat, 1 Nov 1997 14:07:17 -0800 (PST)
Received: from waxbill.twinspot.net (euronetics-001.euronetics.com [193.45.213.245] (may be forged)) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA23521 for <[e-mail]>; Sat, 1 Nov 1997 14:07:12 -0800 (PST)
Received: from twinspot.net (bishop.twinspot.net [193.45.213.241]) by waxbill.twinspot.net (8.8.5/8.8.5) with ESMTP id XAA03470; Sat, 1 Nov 1997 23:07:06 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 01 Nov 1996 23:07:09 +0100
From: Tomas Fasth <[e-mail]>
Organization: EuroNetics
X-Mailer: Mozilla 4.02 [en] (WinNT; I)
MIME-Version: 1.0
To: Bart Schaefer <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: sieve draft
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

Bart Schaefer wrote:
> 
> On Nov 1,  3:02am, Tomas Fasth wrote:
> }
> } What other than spam would be a subject for delivery refusal?
> 
> Some examples:
> 
> I run an email customer support service.  Customers with paid support can
> legitimately send mail to [e-mail].  All other messages
> sent to that address are bounced, with the suggestion that they pay up.
> (No, I don't really run such a service.  These are examples.)

IMO, your example above is not a subject for delivery refusal.
I regard it as a denial of service associated with a particular
maildrop.
I can easily imagine many kinds of commercial services similar to the
example above. Each having different access control mechanisms on the
same message store/maildrop site.
The question is, regarding that each automated maildrop service might
have it's own access control, where are all this best handled?
I suggest that a good design would be, from the MTA's point of view,
to regard the message as being successfully delivered to the maildrop,
which happens to have a service associated to it, a service which then
decides by it's own access control whether to accept the service request
or not.
I would not recommend to make that kind of handling a business of the
MTA. It would only be confusing and even hard to administer and
maintain.

> I subscribed to the [e-mail] mailing list, but now I don't
> want it any more.  I've sent a dozen unsubscribe requests, but nobody
> is managing the list and it keeps coming to me.  I want to bounce the
> messages back to the (admittedly unresponsive) list admin address and
> to the [e-mail] in hopes of getting their attention.  But
> that doesn't mean that everyone at my site thinks the fud-list is spam.

Hmm. In this case I think your approach is unfriendly.
Instead of taking the small annoyance of finding out the address of the
admin and the postmaster, and send them a polite request of removal,
you decide to bounce each and every message originating from that
particular list. I do not consider that a good use of filtering.

I do recognize a need of list management on the client side, but that
is hardly done by using filtering technics alone.

> I could come up with more, but they're mostly variations on one of those
> two themes:  (1) Only messages matching some criteria should be delivered,
> and all others should get a bounce explaining why they were not; (2) some
> source of mail not normally considered to be spam is for whatever reason
> abusing a mailbox, and a bounce should be generated to notify the sender
> of this unintentional abuse.

I suggest we begin by distinguish between message delivery and
message acceptance. By doing this we might be able to reach some
kind of consensus on what we are trying to achieve here.

My opinion is that a message ought to be regarded as delivered if
the message have successfully reached the maildrop. Note that a
maildrop can be more than just a simple file or a slot in a database.
A maildrop can be the entry to another subsystem which might control
the access to further processing or final storage.

My point is that if we use this description as a model, message
delivery is just about to find the correct maildrop. That makes
the task of the MTA much less complicated.
By delegating maildrop specific processing, for example message
acceptance, to the subsystem beyond final delivery, you have,
in my opinion, achieved a better modular approach to the messaging
infrastructure.

> Not true.  For example, there may be a valid reason for some mailboxes
> to reject all messages that do not have a digital signature, or that are
> not encrypted using a particular public key.  But the protocol doesn't
> reveal whether the data is digitally signed or encrypted.

Yes, there are reasons for rejecting certain messages depending on
what context they are in. Yes, the protocol handler should not bother
about digital signatures and such.
But then, I regard neither of those things to be among a message
transport agent's responsibilities.

> A reply action is typically directed to addresses taken from the RFC822
> header of the message, e.g. the "From" or "Reply-To" fields.  A bounce
> is typically directed to the envelope sender, e.g. the SMTP "MAIL FROM"
> address.

I see. My interpretation of current internet standards in this area,
is that the SMTP "MAIL FROM" address, also called the originator
address or return-path, is recommended to only be used by the MTA for
resolving non-deliveries and mail system failures. There are also RFC
documents describing how such a "bounce" should be formatted.

There seem to be a slight confusion between the SMTP type of bounce and
your type of bounce. But then, I am asserting that your type of bounce
is not really a bounce, but rather something that is in practice the
same as a reply. There are even draft documents describing something
called message disposition notifications. I think those can be used
in such similar situations that have been described here and earlier.

Further, I do not regard your use of return-path as conformant with
current internet messaging practice. 

> There presently aren't many (if any) tools that are able to
> make that distinction, because there are few MTA-level filtering tools;
> almost all must run "post-delivery" without access to the SMTP envelope.

Which is my point. There are reasons for running the filtering tools
as "post-delivery". One is that since the filtering rules originates
from an end user and therefore have unpredictable results, it's not
a good idea to let those rules control the pre-delivery process.

You can always argue that there is need for filtering rules that
are centrally administred by the postmaster. But then, I assert that
this might be a dangerous approach. Do you really want to do this?
Slightest mistake in one of the rules will potentially affect all
the maildrops on the site.
Isn't it bad enough to have the sendmail.cf to worry about? ;-)

> One purpose of the sieve language, as I understand it, is to enable the
> user to intervene *before* the MTA delivers the message, thus making it
> *possible* to have distinguished "bounce" and "reply" actions.

The very idea of having individual users to dictate the behavior of
the MTA is revolting to me. It even sounds outright dangerous.

But then, I am sure that your cause is absolutely sincere.
I only ask you to consider another approach of solving your problem.
And there are many good uses for a filtering language like Sieve,
although I disagree with your particular type of use.

-- 
Hälsningar/Regards

Tomas Fasth <[e-mail]>
tel: [phone] cel: [phone] fax: [phone]