Sam Robertson | 9 Sep 03:11 1999
Picon

MDNs vs. DSNs

I'm probably resurrecting a dead horse here, but let's see.

Generating MDN's in our implementation is not possible at this point,
yet we want to support the reject action.  Aside from all the features
provided by supporting RFC 2298, why is an MDN an absolute requirement?

Is there anyway we might be able to change the wording in 4.1 to read:

   The optional "reject" action refuses delivery of a message by sending

   back an [MDN] or [DSN] to the sender.

   Example:  if header :contains "from" "coyote <at> znic.net" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }

   A reject message SHOULD take the form of a failure MDN but MAY be a
DSN as specified  by
   [MDN] [DSN].

... continued specifics about MDN verbage ...

Regardless of whether we can change the wording at all, the second
sentence in the first paragraph of 4.1 should start with a capital R.

In addition, in defining the action 'redirect' we should define the
behavior without forcing someone to know what a .forward file using
sendmail under UNIX does.  In other words we should define it in
explicit terms???
(Continue reading)

Tim Showalter | 9 Sep 10:09 1999

Re: MDNs vs. DSNs

Sam Robertson <samr <at> Netscape.COM> writes:

> Generating MDN's in our implementation is not possible at this point,
> yet we want to support the reject action.  Aside from all the features
> provided by supporting RFC 2298, why is an MDN an absolute requirement?

We want a standard reply with well-known semantics.  MDN has standard
semantics, but they are weak enough to allow for what a reject action
implies.  Specifically, a "deleted" MDN allows for the ambiguity that
"maybe the recipient deleted your message, or maybe he deleted it and
kept it".

The semantics of a DSN are not defined this way.  There's no wiggle
room for what amounts to lying.

I find it rather strange that you can't generate an MDN.  Why not?
(What am I missing?)

> Is there anyway we might be able to change the wording in 4.1 to read:
> 
>    The optional "reject" action refuses delivery of a message by sending
>    back an [MDN] or [DSN] to the sender.

MDNs and DSNs are not interchangable, so I don't want to make this
change.

> Regardless of whether we can change the wording at all, the second
> sentence in the first paragraph of 4.1 should start with a capital R.

er, actually, I think the word "It" is missing in there.  Thanks.
(Continue reading)

Ned Freed | 12 Sep 07:32 1999

Re: MDNs vs. DSNs

> Sam Robertson <samr <at> Netscape.COM> writes:

> > Generating MDN's in our implementation is not possible at this point,
> > yet we want to support the reject action.  Aside from all the features
> > provided by supporting RFC 2298, why is an MDN an absolute requirement?

> We want a standard reply with well-known semantics.  MDN has standard
> semantics, but they are weak enough to allow for what a reject action
> implies.  Specifically, a "deleted" MDN allows for the ambiguity that
> "maybe the recipient deleted your message, or maybe he deleted it and
> kept it".

There's also another side to this coin -- suppose filtering is implemented in
the MUA (perfectly reasonable), the message had a NOTIFY=SUCCESSES in the
envelope, and the MUA's filters said "reject".  Then it is possible to get a
success DSN followed by a failure MDN. (Also reasonable.) But if a DSN
was generated, you'd have a success DSN followed by a failure DSN. Not
good.

> The semantics of a DSN are not defined this way.  There's no wiggle
> room for what amounts to lying.

> I find it rather strange that you can't generate an MDN.  Why not?
> (What am I missing?)

One case where this would be an issue is if reject was implemented in
an LMTP delivery agent as a return of a failure status. This would
result in a failure DSN and short of implementing a queue in the
LMTP delivery agent there would be no way to avoid this. (And remember
that the point of LMTP is to avoid having a queue.)
(Continue reading)

Internet-Drafts | 17 Sep 14:03 1999
Picon

I-D ACTION:draft-showalter-sieve-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Sieve: A Mail Filtering Language
	Author(s)	: T. Showalter
	Filename	: draft-showalter-sieve-09.txt
	Pages		: 40
	Date		: 16-Sep-99
	
This document describes a language for filtering e-mail messages at
time of final delivery.  It is designed to be implementable on either
a mail client or mail server.  It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
system.  It is suitable for running on a mail server where users may
not be allowed to execute arbitrary programs, such as on black box
IMAP servers, as it has no variables, loops, or ability to shell out
to external programs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-showalter-sieve-09.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-showalter-sieve-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Tim Showalter | 20 Sep 23:33 1999

next-to-last call on sieve base spec

If anyone has any comments, flames, or corrections to the Sieve spec
as published (version 09), please let me know.  I'd like to last call
it shortly, or we'll have to talk about it at the next IETF.

I know the formfeeds got eaten.  My mailer seems to have acquired some 
bad habits.  I'm sorry for the inconvienence.

Tim

Timothy L Martin | 28 Sep 17:42 1999
Picon

sieve protocol

The Cyrus Imapd currently gives two options of where to store users'
sieve scripts. In the user's home directory or within the /usr/sieve
directory on the Cyrus Imapd server. Since Cyrus is a closed system
this presents the problem of how do users get their sieve scripts onto 
the server. We have come up with the protocol listed below and plan to 
release code based on it in the next version of Cyrus. We hope in the
future for users to submit their scripts to an ACAP server but we need 
a solution until that is possible.

Some others have expressed interest in this. Do people think it would be
worthwhile to write this protocol up formally?

Of course any comments or suggestions on the protocol would be greatly 
appreciated.

Thanks,
Tim

----------------------------------------------------------------------
This is a protocol for getting user sieve scripts onto the server. The
requirments for this process are:

-the user must authenticate to gain access
-only valid sieve scripts may be accepted

Additional "features" provided:

-the ability to manage multiple scripts on the server with zero or one
of them being the "active" sieve script

(Continue reading)

Lyndon Nerenberg | 28 Sep 22:51 1999

Re: sieve protocol

>>>>> "Timothy" == Timothy L Martin <tmartin <at> andrew.cmu.edu> writes:

    Timothy> NOOP EOL
    Timothy> No side affects. OK, NO replies

If this doesn't do anything it should be removed from the protocol.

--lyndon


Gmane