1.6. Script Names
Sieve script names may contain any valid UTF8 characters, but ***names
must be at least one character long***. ...
When one reads the draft for the first time it is not clear why you have
It is better to explain that empty name has different semantics when
SETACTIVE is used.
Good point. I'll try to phrase it better.
2.1. AUTHENTICATE Command
The service name specified by this protocol's profile of SASL is
"imap" since implementations are generally tied to an IMAP
I object because the service name is an element used in several SASL
mechanisms (at least KERBEROS_V4, GSSAPI & DIGEST-MD5)
I agree with this objection. Are there any objections to the use of
the service name "sieve"?
[SASL-ANON]. SASL mechanisms which use plaintext passwords
(including the PLAIN mechanism [PLAIN]) MUST NOT be used unless a
security layer is active or backwards compatibility dictates other
I don't see the case of "backward compatibility" for the protocol. The
situation is different from POP3/IMAP4 where PLAIN is widely deployed.
As Tim points out, I was referring to the large number of sites that
refuse to use strong authentication and insist on storing their
plaintext passwords in questionable places.
2.2. STARTTLS Command
How client/server should behave if TLS negotiation fails?
There was some discussions in TLS Mailing List
(<ietf-tls(_at_)lists(_dot_)consensus(_dot_)com>) regarding TLS and SMTP.
I have not been keeping up with that list. If there is a way to deal
with TLS negotiation failing will it be a generic way that all
protocols will be able to inherit or will something protocol specific
need to be written?
2.5. HAVESPACE Command
String - name
Number - size
The HAVESPACE command is used to query the server for available
space. Clients specifiy the name wished to save the script as and
it's size in octets.
Why do you want to pass name to HAVESPACE, i.e. does it make any
difference whether name is the name of an existing script or not?
Yes since it is overwriting the script.
Consider the example where you have a 10K limit and one script "foo"
of size 6K on the server. 'HAVESPACE "bar" 7000' would fail but
'HAVESPACE "foo" 7000' would succeed.
Also, we was discussing HAVESPACE with Lyndon and he pointed out that
there is a race condition in using HAVESPACE (imagine two clients wants
to store script for the same user. There is enough space for any of them
but not for both).
I prefer IMAP approach: use synchronizing literals in PUTSCRIPT. If
server respond '+ ...', then it will accept the script,
otherwise it will return NO.
The grammer is simpler with the HAVESPACE command. PUTSCRIPT still
needs to check quota but a good client should be able to avoid sending
the script data and then getting a quota violation 99% of the time.
What do you think about adding response codes for various failures?
I didn't because I wasn't sure of a good/simple way of adding them?