Subject: Re: List of expected changes for sieve 05 draft - Forward

From: Wilbert de Graaf <[email-masked]>
Date: Wed, 11 Nov 1998 17:45:55 +0100

Tim,

I want to suggest to add a header to the original message on the action 'forward'

: Syntax:    forwadrd <address>
: ... . The "forward" action makes no changes to the message body or headers, and 
: only modifies the envelope recipient.

I suggest this action also inserts the Resent-From: header. This header is specified
in RFC 822:

+++ rfc 822 snippet +++
4.2 Forwarding

    Some  systems permit  mail recipients  to  forward  a  message, 
retaining  the  original  headers  by adding  some new fields. This 
standard  supports such  a service, through the "Resent-" prefix to 
field names.
+++ rfc 822 snippet +++

Some systems might reject to forward mail, since the MTA could see this as a relay 
from the original sender to some remote address. If the Resent-From: <original recipient>
is inserted, this might be suppressed.

Furthermore, I also would like to see a copy-forward action: instead of forwarding, deliver
the message and send a copy to the specified address. We use this mechanism to send a a copy
to sopme system, which notifies the reciver on their mobile system. I do not see another way
how sieve could help me to solve this problem.

- Wilbert

---

From: "Barry Leiba" <[email-masked]>
Date: Wed, 11 Nov 1998 13:27:39 -0500

Wilbert de Graaf says...

> Furthermore, I also would like to see a copy-forward action: instead of 
> forwarding, deliver the message and send a copy to the specified address. 

There's nothing wrong with using "forward" and "fileinto" (or "keep") 
together to accomplish this.  I do that in my sieve script:

} elseif  envelopesender :contains :comparator "i;ascii-casemap" [...]  {
    forward "[email-masked]";
    fileinto "Lists";
} ...

In fact, our implementation will do "keep" in addition to any "forward";
if you want to forward and discard, you must explicitly do it:

} elseif  envelopesender :contains :comparator "i;ascii-casemap" ["xagentft"]  {
  if header ["subject"] :contains :comparator "i;ascii-casemap" ["sent to your workstation"] {
    forward "[email-masked]";
    discard;
  } else {
    keep;
  }
} ...

(BTW, I find it *much* more useful to use "envelopesender" than to use
the document header fields.  Suppose I'm subscribed to the IMAP, ACAP,
IMAPEXT, and MTA-FILTERS mailing lists, and someone posts something to
all of them.  With "envelopesender" I can sort the four copies into their
respective folders.  Without it, there's no way to do that.)

Barry Leiba, Multimedia Messaging   ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: Randall Gellens <[email-masked]>
Date: Wed, 11 Nov 1998 11:43:40 -0800

> if you want to forward and discard, you must explicitly do it:

My implementation does the same thing.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 11 Nov 1998 11:46:58 -0800

At 5:45 PM +0100 11/11/98, Wilbert de Graaf wrote:

> I suggest this action [forward] also inserts the Resent-From: header.

My implementation adds Resent-From, Resent-To, Resent-Date, and 
Resent-Message-ID.  If multiple recipients are specified in the Forward 
action, I say "Resent-To: (undisclosed recipients)" to avoid revealing 
the recipients to each other.

---

From: Tim Showalter <[email-masked]>
Date: 11 Nov 1998 15:37:19 -0500

So should forward add Resent-* information?  Pete Resnick told me a long 
time ago it should, but I forgot to write it down.

I'm under the impression that it should.

> From: "Barry Leiba" <[email-masked]>
> Date: Wed, 11 Nov 1998 13:27:39 -0500

> together to accomplish this.

I agree with Barry.

> respective folders.  Without it, there's no way to do that.)

Not true.

if header ["to", "cc"] :contains ["[email-masked]"] {
	fileinto "INBOX.mta-filters";
}
if header ["to", "cc"] :contains ["[email-masked]"] {
	fileinto "INBOX.imap-list"; 
}
[etc.]

Or am I just completely missing something?

This doesn't work if a mailing list has multiple names.

Simply matching against return-path doesn't work for mailing lists that
do VERPs.  See Dan Bernstein's weekly rant on the subject for more
information, although qmail/ezmlm isn't the only one that does it,
either.  Mostly it works if you do a glob of some kind, I think.

-- 
Tim Showalter <[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 1998 00:10:14 +0300

> time ago it should, but I forgot to write it down.

I think every developer should decide for himself.
(I keep both headers and body of the message in the same file, so I am not
delighted with the idea of copying [potentially large] message on delivery just
to add Resent-* flags).
So I think that adding Resent-* fields should be SHOULD, not MUST.

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team

Epsylon Technologies, Russia
 http://www.taxxi.com

Imap Development Kit (my own product)
http://194.87.43.111/homerus/mail/idk/index.htm

Fax (in San Diego, California): 1 (619) 8393837
------------------------------------------

---

From: "Barry Leiba" <[email-masked]>
Date: Wed, 11 Nov 1998 16:50:22 -0500

Alexey...

> delighted with the idea of copying [potentially large] message on delivery just

You have to add a "received" line anyway, if you do it right.  You can just
write the "resent-*" lines after the "received" line, and then pipe the rest
of the message through.

> So I think that adding Resent-* fields should be SHOULD, not MUST.

In any case, I agree with this.

---

From: "Barry Leiba" <[email-masked]>
Date: Wed, 11 Nov 1998 16:47:55 -0500

Tim...
> Or am I just completely missing something?

Trouble with that is that all four copies of the message match all four
tests.  So I wind up with each folder getting four copies of the message.
And that's assuming my implementation supports multiple fileinto.

But if I use 'envelope ["from"]', then each of the four copies of the
message only matches one, and I get exactly what I want.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 1998 01:01:06 +0300

> write the "resent-*" lines after the "received" line, and then pipe the rest

I add received lines *before* receiving message content. Then I perform some delivery
actions on fully received message.

Don't understand me wrong : I am not arguing that my implementation is the best
(because it isn't :-)). I just concerned about the speed of delivery in my
implementation.

> http://www.research.ibm.com/people/l/leiba

I don't mind to have different "forward" and "resent", as proposed by  Alan Stebbens.

Cheers,
Alexey Melnikov

---

From: Randall Gellens <[email-masked]>
Date: Wed, 11 Nov 1998 14:52:27 -0800

> Or am I just completely missing something?

The message may have all four mailing lists in the address headers, in 
which case all four copies will be filed into the first folder, and 
none into the others.  I had this problem with IETF announcements that 
were cc'd to the working group lists -- I ended up with two copies in 
one folder, and none in the other.  I fixed this by looking at Sender 
and envelope sender.

Also, a message may have been bcc'd to the list.  For example, here at 
work people often send mail to a large internal list, and in order to 
avoid inadvertent reply-to-alls, the list is actually bcc'd.

---

From: Tim Showalter <[email-masked]>
Date: 11 Nov 1998 19:01:11 -0500

> Date: Wed, 11 Nov 1998 14:52:27 -0800
> From: Randall Gellens <[email-masked]>

> none into the others.  [...]

Oh, I see.  But fileinto should not stop processing and all fileintos
should be honored, so you should get four messages in each of four
mailboxes.

(I forgot that under AMS, when I used to do this sort of thing, only one 
message with a given Message-ID could exist in a mailbox, and forgot
that it was going on.)

---

From: Randall Gellens <[email-masked]>
Date: Wed, 11 Nov 1998 17:15:51 -0800

> should be honored, so you should get four messages in each of four

You are right, all fileinto's will be done, so we'd end up with four 
copies of the message in the *last* mailbox, not the first.  In the 
environment in which I first implemented Sieve, "fileinto" changes the 
destination of a message, it does not cause immediate copying.  So 
after Sieve is done with the message, it gets put into whichever folder 
is specified.