curl

curl copied to clipboard

This should be rather complete, as it introduces support in library, cli tool, tests and documentation. Currently marked as experimental.

I've never heard of it. Are there many users?

I wish you'd discussed this with us before you implemented all this. I've not seen a single user ask for this protocol, ever - and we ask users every year and give them the chance to specify which protocols they miss. I'm not convinced it is a suitable protocol for curl.

Please help us understand why curl users want this esoteric protocol supported?

I've never heard of it. Are there many users?

I don't know: however there are many users asking for the feature in mail clients. This is THE protocol allowing a per-user control of mail redirection, auto-replies, spam filtering, server-side filing, etc. There are no other standard for this purpose. As examples, the PigeonHole module of Dovecot implements such a server, the Horde web groupware uses this protocol and there are Thunderbird client addons for it (https://addons.thunderbird.net/en-US/thunderbird/addon/sieve/). Existing client implementations: http://sieve.info/libraries#managesieve_the_transport_protocol_for_script_management

I've not seen a single user ask for this protocol, ever

Not true: it has been reported once or twice in the surveys, and this is where I've seen it mentioned for the first time. I use it regularly on my own mail server since then.

Please help us understand why curl users want this esoteric protocol supported?

First, it is not more esoteric than dict or gopher (nowadays) and much more useful.

• It completes the mail-oriented protocols we already support.
• Sieve scripts are files, although not general files like with ftp, http, etc. but we already support such files (ldap, dict, rtsp).
• Featuring it in curl will promote its use, and thus the target features mentioned above. Probably many potential client developers have been discouraged implementing it because of the narrow count of support library.
• Its availability in the cli tool also allows checking the script syntax by the server via a single line command (curl -X checkscript -T script ...).
• Using sieve scripts allows to do without some well known proprietary server more easily.

I'm not convinced it is a suitable protocol for curl.

I thought you would be happy with this code. Anyway, you can still refuse it. I don't expect this protocol have a high score in the future surveys, but its availability will be much valuable. Did you ever use sieve scripts? You should give them a try! I hope I've been able to convince you.

it has been reported once or twice in the surveys, and this is where I've seen it mentioned for the first time

I stand corrected. I went back and indeed I found a request for it in 2018. (didn't check further back)

First, it is not more esoteric than dict or gopher (nowadays) and much more useful.

1. Don't compare to existing implementations as we might not have accepted those protocols if someone brought them today: https://curl.se/dev/new-protocol.html#dont-compare
2. "more useful" is just an opinion, it's not a fact.

Did you ever use sieve scripts?

Never. I didn't even know what the protocol did before your PR here...

I didn't even know what the protocol did before your PR here

One more thing: sieve is the missing link between an SMTP/IMAP-based server and the proprietary server mentioned above...

Haven't heard of ManageSieve yet, but Sieve is the standard language for creating email-server-side filtering rules. It's quite useful and even though the language is awkward, it's better than proprietary declarative files or nothing at all.

1. Is someone aware of a compilation of email providers / server software supporting ManageSieve?
2. Unless I'm missing something the only way for a secure ManageSieve connection is via STARTTLS upgrade. This is vulnerable to (trivial by a MitM) downgrade attacks. From security/privacy angles, this makes the protocol problematic. Was this perhaps addressed in an RFC update?

...the language is awkward...

It is derived from ACAP: https://www.rfc-editor.org/info/rfc2244.

Is someone aware of a compilation of email providers / server software supporting ManageSieve?

The protocol has been specified by the Cyrus-IMAP designers. I did not find a ManageSieve-avare server list, but https://en.wikipedia.org/wiki/Comparison_of_mail_servers#Feature_comparison mentions those supporting sieve scripts. Hopefully the protocol should go with.

Unless I'm missing something the only way for a secure ManageSieve connection is via STARTTLS upgrade. This is vulnerable to (trivial by a MitM) downgrade attacks. From security/privacy angles, this makes the protocol problematic. Was this perhaps addressed in an RFC update?

There is only https://www.rfc-editor.org/info/rfc7817 addressing TLS, but it only contains server identity checking rules for several mail protocols and does not affect the protocols themselves. I can't find a definition for an implicit SSL enabled service (no sieves scheme).

@monnerat: Thanks for the pointers!

The Sieve table column is definitely useful, though I had ManageSieve support in mind specifically. AFAIU the former doesn't imply the latter. At least the few services I happen to know with Sieve support, do not offer ManageSieve.

As for TLS verification, it's a must indeed, but what if the connection just never gets upgraded to use TLS in the first place? This can happen either because the server response gets manipulated to indicate it isn't supported, or because the client request is manipulated to never make the STARTTLS request. If this happens without the client noticing and a way to abort, the rest of the session will continue in cleartext, including the authentication phase, content of read filters and even the option for the MitM to inject commands to modify them. With the latter e.g. all future incoming email traffic can be forwarded to a mailbox controlled by the MitM.

AFAIU the former doesn't imply the latter.

Yes, but we can logically hope it's not the case.

At least the few services I happen to know with Sieve support, do not offer ManageSieve.

This seems weird: how they allow controlling per-user scripts? Maybe they do feature it, but it's not enabled...

As for TLS verification, it's a must indeed,...

RFC 7817 also targets SMTP, IMAP and POP3. As we support these protocols, If these rules are not applied by our SSL subsystem, then these protocols are also affected. But this is an SSL problem, not a protocol one. In curl, we have options --ssl and --ssl-reqd: the latter should prevent the cases you mention. Use of the former or a clear connection is left at the user's discretion. Note also that Dovecot does not fallback to clear mode if the TLS negotiation fails: it just disconnects; you cannot then expect to fallback to clear mode... but that's jjust a particular case. Dovecot also do not offer cleartext authentication methods until TLS has been negotiated. New capabilities are sent to the cliient after successful STARTTLS, including an updated set of supported SASL mechanisms. Commands dealing with scripts/lists are not recognized until authenticated.

I think the only efficient protection could be made at the authentication level with a new option enabling/disabling cleartext mechanisms when no TLS has been negotiated. But again, that applies to all protocols that can upgrade to TLS, and mainly to the SASL support, but that's another story! For now, --ssl-reqd and/or --login-options should be used.

STARTTLS is just as an issue for already supported email protocols, I agree, but, one difference is that those all support implicit TLS. With ManageSieve there is no secure alternative, even though the managed data is just as sensitive/private. This may be a sign that the protocol isn't actively maintained.

[ The services I know allow editing Sieve filters via their filter configuration web UI. ]

The services I know allow editing Sieve filters via their filter configuration web UI.

This is what Horde groupware module ingo does, but it uses ManagesSieve at the server level to interact with the MDA.

one difference is that those all support implicit TLS. With ManageSieve there is no secure alternative

I don't think --ssl-reqd is less secure than implicit TLS. The only potential problem I found is a REFERRAL response code in the server greeting message, that could be forged by a MitM to redirect requests to its own server. To avoid this situation, I have now slightly changed the code to refuse following a referral if TLS is requested and has not yet been successfully negotiated, even with --location option.

New paper on STARTTLS vulnerabilities: https://nostarttls.secvuln.info/ [paper] [via]

New paper on STARTTLS vulnerabilities: https://nostarttls.secvuln.info/ [paper] [via]

Thanks for the link. Unfortunately the test tool used in this study does not include ManageSieve (targets SMTP/IMAP/POP3 only) and is written in 3 different languages :-( There's no PREAUTH in ManageSieve, thus we won't have this problem. Among the capabilities transferred in the greetings response, only STARTTLS and SASL are handled. In addition, a successful TLS negotiation is followed by a new set of capabilities, effectively redefining supported SASL mechanisms. The REFERRAL problem has already been handled. Client command pipelining is not under our control: this is a server business. However we can check for server response pipelining: this is now done.

As the paper says, STARTTLS is fragile in terms of implementation, but I don't see any vulnerability in the concept.

Anyway in our position, we can only be vigilant in our STARTTLS use, but we can't change a protocol definition.

I did a quick search for server-side ManageSieve support:

Servers supporting ManageSieve:

• Apache James https://james.apache.org/
• Cyrus IMAP https://www.cyrusimap.org/3.4/imap/reference/admin/sieve.html
• Dovecot https://wiki1.dovecot.org/ManageSieve
• Kolab https://docs.kolab.org/installation-guide/preparing-the-system.html#system-firewall
• Archiveopterix https://archiveopteryx.org/sieve/
• Oracle messaging exchange server https://docs.oracle.com/cd/E63708_01/doc.801/e63711/msadm_filter.htm#MSVAG1583
• Perdition https://projects.horms.net/projects/perdition/

Servers supporting sieve, but not mentioning ManageSieve, hence it's very unlikely they support it:

• Axigen
• Courier mail server
• Kerio Connect
• Mailsite
• Zimbra

Citadel used to support ManageSieve until july 2020, but they then even removed sieve support.