Subject: does vacation need to define what an address looks like?

From: Tim Showalter <[email-masked]>
Date: 11 Aug 2000 16:24:06 -0700

Hi.  Ken Murchison pointed out that vacation doesn't define what an
address is supposed to look like beyond a string.

I am inclined to forbid comments, and define that an address is supposed
to be only the stuff between the <>s.  I would like to add verbage to
the draft and state that this is all that's allowed.  Ken thought the
phrase part might be interesting for GUIs, and I'm not sure how to
handle that.

Should address allow for a phrase part, or worse, comments?  If so, I
believe only the useful parts (i.e., user@domain) should be significant.

Ot's probably necessary to allow just user (i.e., no @domain) for
OSes/MTAs that have concepts of local mail.  I will probably make this a
SHOULD since it might not be appropriate for some implementations.

If an address is syntactically or semantically bogus, I think the right
thing to do is to just ignore it, and we probably need text that says
that, too.

I'm looking for a second opinion, especially on the question as to
whether phrases should be allowed/forbidden.

Incidentially, I said in Pittsburgh that I had sent in sieve-12 and
vacation-04.  I was wrong; I had sent sieve-12 to myself, and didn't
realize it until way too late.  I may have maligned the I-D editor, but
they were doing a great job as usual.  sieve-12 and vacation-04 are now
in an I-D repository near you.

Tim

---

From: Ken Murchison <[email-masked]>
Date: Fri, 11 Aug 2000 22:16:21 -0400

> address is supposed to look like beyond a string.

More specifically, section 2.4.2.3 of [SIEVE] states that addresses must
be compliant with RFC822, but doesn't state what part(s) of RFC822
addresses are accepted (ie, 'address', 'mailbox', 'addr-spec', etc)

BTW, I think this same discussion applies to redirect addresses. 
Hopefully we can decide on a syntax that is consistent for both.

> phrase part might be interesting for GUIs, and I'm not sure how to

My point on this was that some user-friendly script creation tool might
simply pull addresses out of an addressbook (LDAP, MySQL, proprietary,
etc) which most likely would contain a phrase (ie, "Sieve Mailing List
<[email-masked]>").  Since this is what most modern MUAs do, I
don't think we want to prohibit this in scripts.

> Should address allow for a phrase part, or worse, comments?

IMHO, Yes.

> If so, I

For determining vacation behavior, I agree.

> SHOULD since it might not be appropriate for some implementations.

I agree.

> thing to do is to just ignore it, and we probably need text that says

In the context of vacation, this might be a good thing.  But for
redirect, I think the script should be kicked out so that the user knows
that mail can't/won't be redirected to the address(es) in question.  The
problem with two different semantics however is that when parsing a
script we would have to determine address validity based on context.  So
I'd like to use the same semantics for both, if possible.

> whether phrases should be allowed/forbidden.

FWIW, here's what cmu-sieve currently does based on preliminary
discussions Tim and I had before IETF.

-  The grammar for addresses allowed in vacation and redirect is the
following:

sieve-address	= addr-spec
		/ phrase "<" addr-spec ">"

where addr-spec and phrase are as defined in 822.  Note that like 822,
this grammar does NOT prohibit comments.  For those without 822 handy,
this removes the groups and routes.

-  The syntax of the these addresses are checked at parse-time, and if
incorrect, causes the sieve engine to stop processing just like any
other syntax error.

-  When determining whether a message was addressed directly to the
recipient, only the addr-spec part of the :addresses are compared
against the To, Cc, and Bcc headers.

If we want to allow for local addresses as Tim mentions, I would simply
augment the grammar above as follows:

addr-spec	/= local-part

Personally, I think the CMU implementation (shameless plug) provides for
the most flexibility with the least amount of insanity.  This being
said, I'm willing to concede any and all points :^)

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: Tim Showalter <[email-masked]>
Date: 22 Aug 2000 14:37:55 -0700

After some conversation, Ken and I have agreed on the following format
for addresses:

All of RFC822 must be parsed; supirous comments are mandatory; phrases
must be specified in Esperanto; all ASCII text must be in ROT-13, and
all non-ASCII text must be in modified UTF-7 with all the letters
printed in the reverse order that they are expected to be displayed in.

I hope this isn't a problem for anyone.

The following is not a troll:

I thought about the format for addresses at some time and I believe that
we should allow full RFC822 addresses because Sieve implementations are
required to parse RFC822 addresses anyway.  Anyone who has implmented or
considered implenting otherwise, please speak up now.  I don't
particularly care about error handling in this case; anyone who has an
opinion, please speak up now.

Tim

---

From: Ken Murchison <[email-masked]>
Date: Tue, 22 Aug 2000 20:56:31 -0400

> opinion, please speak up now.

So are you saying that you want to allow the FULL RFC822 'address' which
includes 'group' and 'route', or the modified version that we talked
about earlier and I posted previously in this thread?  I ask because
when we visited this before IETF you explicitly didn't want to allow
groups.

I personally don't care either way, since all I have to do is just
change the start state in the cmu-sieve yacc grammar for addresses :)

What about local addresses like "tjs" or "ken"?  Is this going to be a
MAY?

Are we going to use the same format for both vacation and redirect?

Ken

---

From: Tim Showalter <[email-masked]>
Date: 22 Aug 2000 19:08:45 -0700

> when we visited this before IETF you explicitly didn't want to allow

Uh, let's forbid group and route, and limit it to a single address.  I
don't remember how to say it in RFC822.  I don't want a single string
containing multiple addresses.

We ignored groups for address (I think) and I believe that's the right
way to go here.

> What about local addresses like "tjs" or "ken"?  Is this going to be a

It probably should be.  I will try and come up with wording real soon.

> Are we going to use the same format for both vacation and redirect?

I've submitted the Sieve spec for last call; I suppose I can take this
as a comment on the draft, and fix the vacation draft to point to it.

Tim

---

From: Ken Murchison <[email-masked]>
Date: Wed, 23 Aug 2000 09:23:37 -0400

Tim Showalter wrote:
> don't remember how to say it in RFC822.

Here's what I came up with and is currently used in Cyrus:

where addr-spec and phrase are as defined in RFC822.

Since I posted this earlier with no comment from anyone, its either
complete shit, nobody read it or nobody has any objections.  Let's
assume the latter :)

> It probably should be.  I will try and come up with wording real soon.

If you want to throw a grammar element at it, it might be something
like:

addr-spec       /= local-part

Ken

---

From: Chris Newman <[email-masked]>
Date: Mon, 28 Aug 2000 16:08:48 -0700

> It probably should be.  I will try and come up with wording real soon.

Actually, I'd say MUST NOT (but could live with SHOULD NOT).  Every time 
I've seen "local" addresses used anywhere it caused problems down the road.

What happens when the MTA is upgraded to support multiple virtual domains? 
What about vanity domains?

Suppose I have the addresses <[email-masked]> and <[email-masked]> 
which share the same Sieve script?  Does the resolution of a "local" 
address act differently depending upon which address the message being 
filtered was sent to?

		- Chris

---

From: Tim Showalter <[email-masked]>
Date: 28 Aug 2000 16:29:28 -0700

Chris Newman <[email-masked]> writes:

> Suppose I have the addresses <[email-masked]> and <[email-masked]> which
> share the same Sieve script?  Does the resolution of a "local" address act
> differently depending upon which address the message being filtered was sent
> to?

I don't understand what those addresses indicate in either redirect or
vacation.  vacation doesn't currently specify that addresses are
supposed to be wildcards, and that wasn't my intent when I wrote it.

In some implementations, I can unfortunately imagine the local-part
being the only information available.

Suppose we consider "local" to mean domain of "", with the @ left out
since there's no domain.  I don't want vacation to trigger because I was
bcc'ed on a message also to [email-masked].  If
I instruct vacation that "tjs" is an alias for me, I want it to trigger
only when the mail is to <tjs>,
i.e., no domain at all.

I don't think virtual domains are a problem; however, vanity domains may
be.

Tim

---

From: Chris Newman <[email-masked]>
Date: Mon, 28 Aug 2000 17:16:50 -0700

> supposed to be wildcards, and that wasn't my intent when I wrote it.

I was using shorthand.  I was suggesting a scenario where <[email-masked]> 
goes to my mailbox, as does any message with a domain part of 
"cnewman.isp.com" (regardless of the local part).

> since there's no domain.

That means the address can't be resolved, because there could be 200 
different mailboxes which receive mail addressed to the local part 
"cnewman" in the same mailstore.  In short, the concept of "local" is 
meaningless to me.  The only concept that might have meaning is "same 
domain as in RCPT TO being processed", but for a given sieve script, that 
might have many different values.

> I don't want vacation to trigger because I was

It sounds like you need a distinguished syntax for "any recipient address 
associated with this sieve script".  So add that (perhaps "<>" would work 
for that).  Then supporting subaddresses, vanity domains and their ilk 
becomes an implementation detail rather than a scripting nightmare.

> I don't think virtual domains are a problem; however, vanity domains may

If [email-masked] and [email-masked] are two different users, then which 
one does "tjs" refer to?

		- Chris

---

From: Tim Showalter <[email-masked]>
Date: 28 Aug 2000 17:52:16 -0700

> "cnewman.isp.com" (regardless of the local part).

I'm sorry; I got a bit confused there.

> different mailboxes which receive mail addressed to the local part "cnewman"
> in the same mailstore.  In short, the concept of "local" is meaningless to
> me.  The only concept that might have meaning is "same domain as in RCPT TO
> being processed", but for a given sieve script, that might have many
> different values.

I'm not advocating MUST or SHOULD here.  It's got to be optional, and
will clearly be useless for enlightened implementations that always use
FQDNs.  Unfortunately there's an installed base that might find local
addresses useful.

> becomes an implementation detail rather than a scripting nightmare.

"Any recipient address associated with this script" is built-in and
already there.

> If [email-masked] and [email-masked] are two different users, then which

I would expect that "tjs" would refer to the tjs in the SMTP server's
canonical hostname.  If the server is called mail.domain1.com, it refers
to the former; if the server is called vdom.isp.com, "tjs" refers to
neither address.  If the box doesn't have a canonical hostname, or the
box doesn't ever support local email addresses, the script can be
rejected, or the address can be ignored (one of these behaviors should
be specified, and it should be the latter).

If virtual domains are involved, then it is unlikely that anyone can
refer to me as local user "tjs" anyway.

Tim

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 28 Aug 2000 22:38:56 -0400

Cc: Ken Murchison <[email-masked]>, [email-masked]
   From: Tim Showalter <[email-masked]>
   Date: 28 Aug 2000 17:52:16 -0700

   > in the same mailstore.  In short, the concept of "local" is
   > meaningless to me.  The only concept that might have meaning is
   > "same domain as in RCPT TO being processed", but for a given
   > sieve script, that might have many different values.

As a server implementor, I'd love to tell clients to not throw this
unqualified names at me.  I'd like to stick this work with the client
and I think the client is more than capable of doing this.  I'd rather
not guess what the client is going to do.

I'm not sure what functionality is added by the extension---clients
should be able to throw a domain on the RHS.

Larry

---

From: Ken Murchison <[email-masked]>
Date: Mon, 28 Aug 2000 23:59:33 -0400

> I've seen "local" addresses used anywhere it caused problems down the road.

I wasn't advocating local addresses.  I'd rather see FQDNs.  Tim had
mentioned this before, and I was just clarifying what he was thinking so
I can make the appropriate (if any) changes in cmu-sieve.

Actually, since there had been literally no traffic on this topic, I
thought Tim and I were having a private discussion :^)

Ken

---

From: Tim Showalter <[email-masked]>
Date: 28 Aug 2000 21:30:12 -0700

> I can make the appropriate (if any) changes in cmu-sieve.

okay, okay, let's just drop 'em.  :-)

Tim

---

From: Chris Newman <[email-masked]>
Date: Tue, 29 Aug 2000 11:59:51 -0700

> FQDNs.  Unfortunately there's an installed base that might find local

There's an installed base that finds localized 8-bit character sets in 
headers useful.  That doesn't mean it interoperates or should be blessed in 
any way by a standard.

Unqualified local parts are not legal by 821 or 822.  They should always be 
treated as a Sieve syntax error.  Perhaps the protocol used to upload a 
Sieve script could provide a domain which clients may choose to append to 
unqualified local parts.

		- Chris

---

From: Ken Murchison <[email-masked]>
Date: Tue, 29 Aug 2000 15:50:07 -0400

> headers useful.  That doesn't mean it interoperates or should be blessed in

I agree, but for sake of argument, lets assume that Sieve is being used
with an internal MTA which is setup to handle local addresses (no
domain).  If someone can send intraoffice mail to "ken", then I need to
be able to put "ken" in the ":addresses" option of my vacation rule. 
Likewise, I should be able to do a redirect to "tjs" in this
environment.

I wouldn't setup my environment this way, but I think what Tim is saying
is that Sieve might be used in such an environment and should be locally
adaptable.

I don't see where there is an interoperability problem because this
would be a local configuration decision, and the local addresses are
only going to be useful if the corresponding MTA can handle them. 
Obviously, these addresses would never see the public network.

Ken

---

From: Chris Newman <[email-masked]>
Date: Tue, 29 Aug 2000 13:28:17 -0700

--On Tuesday, August 29, 2000 15:50 -0400 Ken Murchison <[email-masked]> 
wrote:
>> headers useful.  That doesn't mean it interoperates or should be blessed
>> in any way by a standard.
>

I fully understand the scenario, and it's almost identical to the 8-bit 
header scenario I mentioned.

> is that Sieve might be used in such an environment and should be locally

We certainly can't stop anyone from doing that if they wish, but neither 
should it be standards-compliant syntax.

> Obviously, these addresses would never see the public network.

Here's the interop problem:

Suppose I make a client to compose and upload Sieve scripts.  Either it 
refuses to allow unqualified local parts, in which case it interoperates 
with everything, except your "local" server.  Or it permits them, in which 
case whether (and how) it interoperates with a given server is 
unpredictable when an unqualified local part is used.

Indeed I think it would be quite useful to have a sieve client which can 
test the script locally by running messages through the script.  But such a 
client couldn't perform a deterministic test unless unqualified local parts 
were banned or it had a 100% reliable way to discover what the server would 
do with unqualified local parts.

		- Chris

---

From: Phil Pennock <[email-masked]>
Date: Wed, 30 Aug 2000 15:59:41 +0200

(First post - I've been lurking)

> unpredictable when an unqualified local part is used.

require "domainless";

> do with unqualified local parts.

If the server accepts them, and you see them, it's passed them to you.
:^)  The server may or may not have chosen to qualify them with a
default; if it doesn't, the installation should allow "domainless".
If this is SHOULD NOT, then there's no need to even code the support for
it.  If someone wants a horrendously broken system, they can hack the
extension in themselves.

So the question is what _you_ do with the messages, because you've
received them.  Specify that ``require "domainless";'' changes the
syntax of addr-spec to not require ``"@" domain'', and note some of the
problems which could arise from simply changing the grammar.

Make it scary enough, and admin will hopefully get a clue, and as part
of their upgrade to support sieve they'll choose to qualify local
addresses automatically in the MTA.

If the MUA doesn't use the MTA for local addresses (???) then the
messages will never reach a sieve filter.

$0.02,
-- 
Phil Pennock                        <[email-masked]> <[email-masked]>
Demon Internet Nederland -- Network Operations Centre -- Systems Administrator
Libertes philosophica.
Sales: +31 20 422 20 00                                Support: 0800 33 6666 8