Subject: Minutes from the Prague IETF meeting

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Apr 2007 12:54:28 +0100

And at the very last moment Alexey submits minutes...
Enjoy!
===========
Thank you to Dave Cridland for being the Jabber scribe this time.

Alexey was the only co-chair present this time. He briefly talked about
status of different documents (see slides). About half WG docs are in 
RFC ed queue.
Collation document got published as RFC 4790, thanks to Arnt.
Base spec was submitted for IESG review.

Philip promised to update Sieve body one more time before sending it to 
IESG for publication.
Editheader - need to resolve handling of mail loops.
Alexey/Cyrus think that notify extension is basically ready, but needs 
reviews and feedback on changes.
Mailto notification is in WGLC, has some open issues, but not much feedback.
Refuse/Reject: Alexey has been too busy recently for an update.

The WG briefly talked about Editheader interaction with redirect/reject. 
Philip replied
in jabber that the new text doesn't affect reject, which still requires 
to return the original
headers, as per another paragraph in the document. And he basically 
agrees with other comments
and will do another revision of the draft before sending it to IESG.

Alexey talked about recent changes to Notify. No comments or objections 
were received,
so Alexey & Barry think that the document is done.

TODO: Dave Cridland & Randy Gellens to do a full review of notify.

Barry has presented the Mailto notification draft. He talked about open 
issues:

1. URI Parameter conflicts with other notify parameters: Do notify 
parameter Override the URI parameters,
   is it an Error or something else?

 Barry likes "Error".
 Alexey & Michael prefer Override. Alexey is thinking of external URIs 
being pulled in (perhaps from IMAP METADATA).
 Barry thinks that Ned might have useful opinion.

 Philip: I suppose a script can code itself defensively to test the URI 
before it uses it. Possible, but ugly.
 Later he added that there were no practical way to test the contents of 
a URI using just ":matches",
 one needed regexps to break them down.

 TODO: Ask Ned for opinion. Unless more people say there opinion, the 
Override option will prevail.

2. Undesirable URI params: what do we do if a URI specifies unsafe headers?

 Barry slightly prefer ignoring bad headers.
 Ted saying the mailto scheme RFC is pretty limited on these points, so 
Sieve advice and mailto RFC advice
 would probably be different.

3. Message origin: does the notification message come from the original 
"RCPT TO", or from the notification system?

 Alexey pointed out a suggestion to make it an option.
 Pete asked what the From is for and whether we were going to reply to 
these messages.

 Philip: if the notification system can autoprocess bounces, then it 
belongs in the envelope MAIL FROM
 Maybe always is better, to block the loop possibility.

 Dave Cridland: not clear why worry about "from" for notifications: are 
they to send msgs *to* a user, not necessarily
 be *from* anyone in particular.

 Philip/Pete: The important 'from' here is the envelope from. IMHO, the 
env-from should *never* be the original.

 No clear consensus on this issue in the room.

4. Body excerpts: "is Barry being silly" for wanting this?

 Alexey commented that the Sieve Notify used to have body extraction 
action, which was removed.
 But it will move to MIME-loops, so he thinks that this is still useful.
 Dave Crocker said that there was a long history of an excerpt being 
useful. But it's tricky to get it perfect.
 Randy was discussing whether the spec ought to say more than "this is a 
good idea", or should we stipulate
 down to the last octet.
 Barry likes the idea of vague specification, with a view that 
mime-loops and body extraction to a variable
 would provide a strictly specified method for doing this.
 Randy: I'm concerned that if we try and standardize it we end up with a 
sprintf format for how the script
 specifies how much of the body to use and how it appears. Since that 
prospect is so scary I urge us to
 instead say "engine may do this if it wants, it is helpful"
 Barry commented that this automatic vague excerpt could be the default.

 TODO: verify consensus for "vague description of body excerpts" in the 
document.

Tony has presented the updated MIME loops document:

Open issues:

1. Should enclose throw away modifications?

 Philip: I think enclose should honor changes. Anyone using enclose to 
create bounces should be shot.
 Aaron: why would we *not* want to honor changes?
 Ted says we can always get unmodified behavior by structuring the 
script carefully (As in not doing
 any modifications).

 Consensus to use the modified version.

2. Should we synthesize Date and From headers to reflect the current 
user and time?

 Philip: Is there text that can be stolen from the submission spec? It's 
kinda like a submission,
 the creation of a full message from a partial one...

 Alexey prefer synthesized: the original are still in the enclosed part. 
Sometimes it is useful
 to see when the message was created and when it was enclosed.

 Note from the room about synthesizing new message id.

 Kjetil and Tony were discussing syntax for extracting key/value pairs 
from variables). Everybody
 else except Philip don't have a clue about the discussion, because 
people haven't read the most recent
 message from Kjetil on the mailing list.

 Philip: Kjetil's idea is cute, but they're not much better than simply 
using a comma separated list,
 partly because there's no way to quote the value properly when adding it.
 You can put quotes around it, but that won't handle embedded quotes or 
backslashes
 Regexps would be as good (or better), but you can't do the extraction 
with just :matches.
 Time for that SQL access extension.

General comment from Alexey (as a co-chair): the list of open issues 
that Tony presented
differs from the one from the latest San Diego IETF, and the issues were 
not addressed.
Tony agrees to review the San Diego list.

Alexey: Assuming all issues are resolved, MIME loops will be last called 
in a couple of weeks.

Alexey briefly talked about Ned's individual Date-Index Draft.
The document has no major issues now, Alexey to shepherd to IESG.

Alexey has briefly talked about Ned's Environment & Notary (DSN) extension.
Barry/Alexey: the two extensions don't belong to the same document.
TODO: Ask Ned to split the draft into 2.

Next Alexey presented his draft on "Accessing IMAP per-mailbox 
annotations from Sieve".
Alexey described features of the extension:
1). Ability to test for mailbox existence
2). Ability to create mailbox on fileinto. Without the new :create tag 
fileinto creates mailboxes
    in some implementations, but doesn't in others.

    Some short discussion about Sendmail implementation: it still treats 
:create as an optional request,
    which is arguably a bug. Sendmail implements Sieve in SMTP server, 
so fileinto turns into
    +detail email address, thus the mailbox creation request might not 
be honored.

Alexey talked about an example: an annotation can be used to turn 
vacation autoreply on or off.

Open issues:

1). Do we want access to server annotations? - Alexey thinks "yes"

 Chris pointed out that testing server annotations and testing 
environment are basically the same thing.
 Barry agreed. Barry commented that there is no namespace-like thing in 
Environment that might support this.

 TODO: Talk to Ned about namespaces in Environment.

2). Do we want access to LIST-EXTENDED data? ACLs? - Alexey thinks 
"maybe" on LIST-EXTENDED data.

 Philip threatened to lose the breakfast he just ate.

Alexey presented a new (not yet written) draft on "Externally stored lists".
The basic idea is to be able to store lists of users or email addresses 
in SQL/LDAP/ACAP/...
Such lists can be updated externally, without the need to update Sieve 
script.
The proposal is to extend redirect action and header/envelope tests to 
reference externally
stored lists.

 Barry showed his Sieve script. It has many email addresses hardcoded, 
so he would like
 to have such an extension.

 Randy said that maybe an external list reference should be via URLs. 
(The proposal as described
 had list labels as opaque UTF-8 strings, e.g. "blacklist")
 Philip agrees.
 Philip: hmm, how about using imap: URLs to access annotations/metadata 
in IMAP?

 Aaron: so, :list "string" is probably a bad name because its confusable 
with :param ["string", "list"].
 And, this would be cool together with variable namespaces: ${external:name}

 Kjetil suggests that this probably doesn't scale too well, for example 
if the list contains
 ten thousands of addresses (like an enterprise address book). Kjetil 
suggests a comparator which
 takes a URI on one side.
 Alexey: Sure, testing membership in big lists can be optimized (e.g. 
use LDAP search).
 This is an implementation detail.

 Randy pointed out that we needed to handle updates, and the LDAP server 
going down.

 Pete says there are email clients which already have addressbook 
interaction in filtering.

 Aaron: I'm in favor of some kind of managesieve extension to maintain 
the external lists.

 Randy said that the extension should also cover management of mailing 
lists.
 (Alexey didn't like the idea)
 Randy: It's a generalization of Eudora's 'intersects address book' 
test, and
 'add to address book entry' action.
 Aaron: Automatically adding inbound/outbound addresses to the address book?

 Kjetil: with "include" in Sieve, it wouldn't be that much of a 
difference to
 upload a new list using ManageSieve. But I want it to use your *real* 
address
 book which is already stored in LDAP or whatever. Also, duplicating 
lists is not good.

 A huge discussion started on whether the identifier for a list has to 
be an opaque string or
 an URI:
  Alexey: I don't like URIs in this case. I don't want to force users to 
write LDAP URIs,
  they are just too complex. The whole point of the extension is to make 
this easier for users.
  In LDAP case users don't need to know the base DN for search, search 
criteria (e.g. which object
  classes), etc.

  Philip: who says the user will be writing the URI? won't the MUA be 
generating the URI to match
  the URI it uses for the address book?

  Pete suggested that the "mylist" can be a relative reference, so the 
script engine uses
  a base URI to resolve it to an absolute URI.

  Alexey thinks that this would not work with LDAP, for example.

  Barry likes the notion of a magical URI for "Your data".

  Kurt thinks it's all too complex.

  Pete says "Thou shalt support URIs", but "Thou may support arbitrary 
tokens".

  Philip: one catch with URIs is that they all have distinct quoting 
requirements for various fields.
  Given an arbitrary string, generating an LDAP URI that searches for 
entries that have a particular
  attribute with that value is non-trivial.
  Randy agrees.
  Philip: have to apply both the LDAP filter escaping *and* the URL 
escaping, in that order.

And finally Alexey talked about ManageSIEVE draft.
One update since last IETF, mostly bugfixes. NOTIFY capability text 
moved here.

Open Issues:

1. Reference implementation doesn't implement non synchronizing literals.

So the spec will be updated to match the real world.

2.  Suggestion from Arnt: Remove anonymous script verification mode.

 Any objections?

 Kjetil: Means the UA doesn't have to store the password for syntax 
checking.
 Alexey: But clients already cache passwords, at least while they are 
running.

 Aaron notes that different users can have different capabilities granted to
 them, so it is important to authenticate properly.

 TODO: Consensus to remove the text.

3. IANA registry for response codes

 Dave Cridland: Could reuse 
http://www.iana.org/assignments/acap-registrations for response codes.

Alexey talked about WG milestones. There was a proposal to update them, 
but the WG is already
1 month behind on the updated ones.

Other business: Alexey wants to talk about Sieve interop on Tuesday or 
Wednesday.
Alexey instructs WG members to drink Czech beer.
The meeting has ended.

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 23 Apr 2007 18:13:09 +0100

> The basic idea is to be able to store lists of users or email addresses in 
> SQL/LDAP/ACAP/...

FYI we support it this kind of way:

if header :is "From" "${Whitelist}" {...}

Where "Whitelist" is an externally configured list of email addresses.  Were 
I to re-implement, then I'd put "Whitelist" in a namespace.  I consider it 
along the lines of accessing server configuration, for which we've already 
discussed adding a namespace.

The idea of IO bound operations from a sieve script such as LDAP/RBL lookups 
makes me twitchy about performance, but these concerns are of course 
solvable using multiple threads/processes.  I think it's the first time 
we've suggested doing this kind of thing, so may be a knock to the 
architecture of a few implementations and therefore make it difficult for 
them to implement.

Nigel

---

From: "Aaron Stone" <[email-masked]>
Date: Mon, 23 Apr 2007 18:46:15 -0000

> discussed adding a namespace.

I would like to see a namespace or function space of some kind. A few
people pointed out that it might be good to specify an LDAP URI inside the
list description, so we're really talking about functions, imho.

> architecture of a few implementations and therefore make it difficult for 

By using strict evaluation of variables, we set ourselves up for a
performance problem because we may be asking the interpreter to first
expand the full external list and then pass that into the test. Variables
says that implementations should be able to pass unexpanded material into
a test, but we still have keep the syntax of list expansions in mind so
that we don't force everyone into nasty interpreter hacks.

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 24 Apr 2007 23:13:02 +0200

> > discussed adding a namespace.

yes, definitely put it in a namespace, IMO it's needed to conform to
"variables".

intuitively, I don't like the use of ":is" here, but it may be down to
wording.  if you said "externally configured search" instead of "list",
I don't think I would get the wrong association to Sieve lists.

there are some issues, what does "${whitelist} foo" mean?  stuff like
that needs to be specified.

> list description, so we're really talking about functions, imho.

I would like to stay away from functions if possible.  how complex do we
need to be to handle the use cases people are thinking of?  consider:

        if address "From" "${addressbook.mailaddress}" ...
        if header "From" "${addressbook.fullname}" ...
        if header "From" "${addressbook.lastname}" ...

could be translated into an LDAP search for attributes "mail", "cn" or
"sn" respectively.  OR and AND can be done at the Sieve level.

the hypothetical addressbook extension could also support

    set "addressbook.baseuri" "ldap://ldap.uio.no/cn=mail,dc=uio,dc=no";

but this quickly gets difficult to get interoperable since there is
little standardisation wrt which LDAP schema to use, and of course LDAP
isn't the only game in town.

HOWEVER: why use variables syntax -- this is similarily expressive:

        if addressbook :fullname "From" ...

and we could even do

        require "variables";
        if address :domain :matches "From" "*" {
                if addressbook :mailaddress :value :matches "*@${1}" ...

although it would probably better to make two tests, one for explicit
lookup value and one for lookup value fetched from headers.

yet another option is to use tagged arguments:

        if envelope :addressbook :matches "From" "*"
        if address :addressbook "From" :matches "[email-masked]" ...

it may be more natural to have only one mandatory argument and leave out
the "*", but I don't think we can change the syntax that way.  instead
the above test could FIRST do a normal match, and THEN a list lookup.

(there is no way to do a search on surname or full name without
variables, however, since ADDRESS-PART doesn't include the tagged
arguments to extract those elements.)

I think I favour this approach as it is more general -- the tag can be
reused for "address", "header", "envelope" and "string".  it's all a
hypothetical example, but I hope it illustrates some options.  sorry for
rambling on :-)

> > architecture of a few implementations and therefore make it difficult for 

indeed.  defered delivery is not uncommon in e-mail systems, but the
Sieve base document does not offer that as an error mode.  is that
implicitly allowed?  I think not, and wonder if we could/should add
wording which says something about temporary errors, e.g. that there
MUST be an upper time limit to defered delivery caused by problems
during execution before the default fallback action (ie., keep) is done
instead.

> that we don't force everyone into nasty interpreter hacks.

agreed.  the idea is that variables without a namespace can always be
expanded.  variables with a namespace may have magic associated with
them so whether to expand them before calling the action or test should
be determined per namespace.

-- 
Kjetil T.

---

From: Dilyan Palauzov <[email-masked]>
Date: Wed, 25 Apr 2007 14:43:16 +0200

Hello,

   In the minutes is mentioned "Sendmail implementation". Is there any?

   Below is the extract from the minutes that talks about the notify  
from: issue.
   I do not see a reason to have different logic when sending a  
notification to the recipient, and when sending an out-of-office  
message to the sender. Namely:
   - if from: is applied, use its value
   - if a mail is send (envelopely) to the address [email-masked], use  
this as notify from:
   - mailbox name and message headers do not count
   - if a mail is sent (in the same envelope) to the same maibox (and  
therefore user), mentioning more than one of her/his addresses in the  
envelope, then which of them to use in the notify? e.g.
   Mail from: peter
   Rcpt to: [email-masked]
   Rcpt to: [email-masked]

and postmaster and webmaster are the same mailbox.

   Well, I don't know if in this case one or two notifications shall be send.

   And I don't want if in similar case an autoresponder shall answer,  
if he has to send one or two vacation messages.

   Със здраве,
     Дилян

> they to send msgs *to* a user, not necessarily be *from* anyone in  
> particular.
>