Subject: Re: sieve 13, corrections made during last-call discussion

From: Tim Showalter <[email-masked]>
Date: 02 Nov 2000 14:24:50 -0800

Ken Murchison <[email-masked]> writes:

> Here's another fly in the ointment: What about 'domain-literals'?  Even
> [IMAIL] discourages that they be used.  Should we just define the syntax
> of what sieve should support in its entirety, or am I just being a pain
> in the ass now?  (taking a 4 year-old trick-or-treating will do that to
> you :^)

I really don't want to define the whole syntax.

I have no problem with allowing domain literals, or, in fact, any of the
comment stuff that's in 822.  Those are potentially useful, and while
they're discouraged, there's no real good way around them.

Okay, one more time:

2.4.2.3. Addresses

A number of commands call for email addresses, which are also a subset
of strings.  When these addresses are used in outbound contexts,
addresses must be compliant with [IMAIL], but are further constrained.
Using the symbols defined in [IMAIL], section 6.1, the syntax of an
address is:

.nf
	sieve-address = addr-spec		; simple address
		      / phrase addr-spec	; name & addr-spec
.fi

That is, routes and group syntax are not permitted.  If multiple
addresses are required, use a string list.  Named groups are not used
here.

Implementations MUST ensure that the addresses are syntactically
valid, but need not ensure that they actually identify an email
recipient.

Tim

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Nov 2000 20:51:01 -0500

> valid, but need not ensure that they actually identify an email

Looks good to me.

One last point (I promise :^)  Are you going to use sieve-address in the
formal grammar for redirect/vacation?  I think just saying that
addresses "are also a subset
of strings" leaves room for someone to do:

redirect text:
Nobody
(test user)
<[email-masked]>
.
;

Do we really want to allow this?  This should still parse OK, but it's
pretty ugly.  Maybe stating that addresses are a subset of
quoted-strings would be better?  Or better yet, define: 

addr	= DQUOTE addr-spec DQUOTE		; simple address
	/ QUOTE phrase addr-spec QUOTE		; name & addr-spec

addr-list = "[" addr *("," addr) "]" / addr

And 'addr' and 'addr-list' would be used in the definitions of redirect
and vacation.

Just a thought.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 2 Nov 2000 21:48:02 -0500

Date: Thu, 02 Nov 2000 20:51:01 -0500
   From: Ken Murchison <[email-masked]>

   redirect text:
   Nobody
   (test user)
   <[email-masked]>
   .
   ;

I don't think we should care about ugliness.  It's ugly but it's a legal
address with a single interpretation, so it's fine.

We want the least sane rules, not the prettiest addresses.

Larry

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Nov 2000 22:14:24 -0500 (EST)

> We want the least sane rules, not the prettiest addresses.

Fine.

BTW, I verified that cmu-sieve can handle this.  I was confident that the script 
would be parsed OK, but was pleasently surprised that sendmail was able to 
accept an address with CRLF in it.

Ken

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Nov 2000 11:18:22 -0500

>                       / phrase addr-spec        ; name & addr-spec

Just looked at this one last time.  I don't know if this is an nroff
fart or an oversight, but the grammar should be:

	sieve-address	= addr-spec			; simple address
			/ phrase "<" addr-spec ">"	; name & addr-spec

You might already have the "< >" in your source, but just wanted to make
sure.

Ken

---

From: Tim Showalter <[email-masked]>
Date: 03 Nov 2000 13:25:05 -0800

> We want the least sane rules, not the prettiest addresses.

agreed.

Tim

---

From: "Roland Pope" <[email-masked]>
Date: Thu, 9 Nov 2000 09:45:22 +1300

To quote from the RFC.

<snip>
   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting received
   headers.  If an implementation detects a loop, it causes an error.
<snip>

What sort of error should this cause? Should a message be generated back to
the sender saying that a mail loop was detected? It would appear in the
current Cyrus 1.6.24 implementation, mails are silently deleted on loop
detection. Should there be an explicit definiton of how this sort of error
should be handled Eg. DSN?

Thanks
Roland Pope

---

From: Tim Showalter <[email-masked]>
Date: 08 Nov 2000 14:28:01 -0800

> To quote from the RFC.

What RFC?

> should be handled Eg. DSN?

It's not reasonable to throw the message away; 2.10.6 requires (MUST)
notification and an implicit keep.

I'm not sure what, if anything, needs to be changed, although the loop
text can probably be improved.

Tim