headers
Tim Showalter | 2 Dec 1997 04:42
Picon

Re: sieve: vacation extension

Someone want to take on the task of writing a DSN document describing a
vacation reply?  I guess it's not a bad idea; having will-return-on-date and
other random contact information would be cool; a very smart client might
pipe such information off to a very smart addressbook program.  The vacation
draft need not reference this, but it could be nice.

SMTP level responses seem unnecessary and not that useful.  (Mail isn't a
good place to have information that seems more pertinent to something like
finger.)

Vacation should reply to the return-path, and will in the next draft.

I believe that the time for repeated messages should not be related to when
the vacation command is used.  For starters, if Sieve scripts are stored in
a filesystem, it's difficult to tell how long the vacation script has been
in effect.

So it may be useful to allow the user to clean out the vacation database on
request.  If a Sieve script is stored in ACAP, there are probably some
really easy ways to do this.

I believe vacation should be forbidden from replying to an address ending in
"-REQUEST", or perhaps "-LIST-REQUEST", but I'm not sure if this is a really
great idea or not.  (Solaris vacation has this feature.)

--

-- 
                                           Tim Showalter tjs <at> andrew.cmu.edu
Permalink | Reply | 0 comments |
headers
Tim Showalter | 3 Dec 1997 02:54
Picon

acap, comparators, and semicolons

So the contains, is, & matches tests use ACAP's comparator registry.  ACAP
defines 3 comparators, i;octet, i;ascii-casemap, and i;ascii-numeric.

Looking at the sieve-00 implementation Rob hacked up ages ago, i;octet is
the default and i;ascii-casemap is what used to be a "-nocase" change to the
keyword.

There are two problems.  The first is that the comparator argument contains
a ; which makes the parser gross.  For the moment, I guess I'm going to
leave the "i;" part out as a hack (which is what the draft says because I
didn't read the ACAP drafts enough).

The easy remedy to this is to just put the comparator in quotes so that
instead of being part of the keyword, it's just an argument to the command.
There are a few other cases where optional arguments need to be used.

Any suggestions?

I'm considering something like

  compare-test-keywords	= "is"/"matches"/"contains"
  comparator-name	= string
  optional-comparator	= "-comparator" WSP comparator-name
  compare-test		= compare-test-keywords WSP [optional-comparator]
  header		= "header" WSP string-list WSP compare-test 
				WSP string-list

So comparator-keywords are moved out of the parser.  (Command parsing should
probably be moved out of the parser too, and resolved like symbols in a real
language.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Newman | 6 Dec 1997 09:07

Re: acap, comparators, and semicolons

On Tue, 2 Dec 1997, Tim Showalter wrote:
> The easy remedy to this is to just put the comparator in quotes so that
> instead of being part of the keyword, it's just an argument to the command.
> There are a few other cases where optional arguments need to be used.
> 
> Any suggestions?

How about just adding a comparator command, which effects all later
searches:

Comparator "fr-ca;iso;strength=3";

This cleans up the grammar and probably does what the user wants.

People interested in the syntax for comparator naming should be at the
LESSOR BOF Monday morning at the IETF.

It's a shame nobody asked for a Sieve BOF, but I suppose a 5 minute plug
for Sieve at the Spam BOF will be good enough.

		- Chris

P.S. I think we should stop using "-" in tokens in Sieve.  An extension
which provided basic math operations would be useful, so "-" should be
reserved for subtraction and negation.
Permalink | Reply | 1 comment |
headers
Tim Showalter | 6 Dec 1997 10:47
Picon

Re: acap, comparators, and semicolons

On Sat, 6 Dec 1997, Chris Newman wrote:

> On Tue, 2 Dec 1997, Tim Showalter wrote:
> > Any suggestions?
> 
> How about just adding a comparator command, which effects all later
> searches:
> 
> Comparator "fr-ca;iso;strength=3";
> 
> This cleans up the grammar and probably does what the user wants.

This isn't too bad, but...

if header "from" contains "tjs" {
	Comparator "i;octet"
} else {
	Comparator "i;ascii-casemap"
}
# foo

By point foo, it's impossible to tell what the comparator is, and I'm not
sure I like this.

I still believe that optional arguments need some coverage in the draft or
they'll be implemented in incompatible ways when someone finally finds
something they can't hack around.

> It's a shame nobody asked for a Sieve BOF, but I suppose a 5 minute plug
> for Sieve at the Spam BOF will be good enough.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gerben Wierda | 23 Dec 1997 16:12
Picon

Sorry, please ignore this post

The traffic on this list is so low that I have been waiting for the first
message a while. I need the first message to put the list into my spamblocker
and then turn the spamblocker on again. I hope this message is sent back
to me by the list, otherwise, I hope someone posts something so I can turn
my spamblocker back on.

Sorry for the inconvenience,

--Gerben Wierda
Permalink | Reply | 0 comments |
headers
Kai Henningsen | 23 Dec 1997 20:40
Picon

Re: bounce, mta, & mua (was Re: sieve draft)

tomas.fasth <at> twinspot.net (Tomas Fasth)  wrote on 19.11.97 in <34730E89.7E2BE79 <at> twinspot.net>:

> Chris Newman wrote:
>
> > 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

RFC 821, of course - this has been true as long as there has been SMTP.  
And here I thought everyone knew _that_ one ...

--- snip ---

            When the receiver-SMTP makes the "final delivery" of a
            message it inserts at the beginning of the mail data a

Postel                                                         [Page 21]


August 1982                                                      RFC 821
Simple Mail Transfer Protocol

            return path line.  The return path line preserves the
(Continue reading)

Permalink | Reply | 3 comments |

Gmane