Re: [Dovecot] Dovecot SASL Client support?
Charles Marcus skrev den 2013-01-08 21:39: I would just like to be able tell postfix to use dovecot-sasl for client side auth as well as server side, so I don't have to maintain cyrus-sasl just for the client side part. http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL it have worked since dovecot 1.x, it does not need to fly with dovecot 2.x yet :=) note that you still need cyrus-sasl api libs for both postfix and dovecot
Re: [Dovecot] Dovecot SASL Client support?
On 8.1.2013, at 15.40, Charles Marcus cmar...@media-brokers.com wrote: I seem to recall mention of SASL client support either being added, but can't remember for sure. The wiki says nothing about Client support (now, or in the future)... http://wiki2.dovecot.org/Sasl So - is there support for it now? If not, is it planned for anytime soon? There are a few uses for client-side SASL in Dovecot: * Proxying to IMAP/POP3 backend server * imapc/pop3c backends connecting to remote IMAP/POP3 server * doveadm connecting to doveadm-server * doveadm command to verify/debug that SASL authentication Dovecot already implements client-side PLAIN SASL mechanism for the first three cases. Each one implements it separately, but since that doesn't really matter since the code is so simple. I guess at some point that code could be moved to a library and other mechanisms implemented for them, although that makes the code more complex since other mechanisms can require multiple roundtrips to server instead of just one like PLAIN. Also people have been happy enough with only PLAIN authentication for these cases for now. Then there's the whole other question of whether that client side SASL code could be exported to a separate library, possibly even API compatible with Cyrus SASL. I think that's unlikely to happen, especially because the code most likely would require libdovecot.so, which isn't really meant to be linked against non-Dovecot software. Probably an easier way to get rid of Cyrus SASL client code would be to move to GNU SASL.
Re: [Dovecot] Dovecot SASL Client support?
* Timo Sirainen dovecot@dovecot.org: Then there's the whole other question of whether that client side SASL code could be exported to a separate library, possibly even API compatible with Cyrus SASL. I think that's unlikely to happen, especially because the code most likely would require libdovecot.so, which isn't really meant to be linked against non-Dovecot software. Probably an easier way to get rid of Cyrus SASL client code would be to move to GNU SASL. My two cent: If it is as good as GNUTLS, I'd rather stick with Cyrus SASL. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
[Dovecot] Dovecot SASL Client support?
Hi all, I seem to recall mention of SASL client support either being added, but can't remember for sure. The wiki says nothing about Client support (now, or in the future)... http://wiki2.dovecot.org/Sasl So - is there support for it now? If not, is it planned for anytime soon? Thanks, -- Best regards, Charles
Re: [Dovecot] Dovecot SASL Client support?
Am 08.01.2013 14:40, schrieb Charles Marcus: Hi all, I seem to recall mention of SASL client support either being added, but can't remember for sure. The wiki says nothing about Client support (now, or in the future)... http://wiki2.dovecot.org/Sasl So - is there support for it now? If not, is it planned for anytime soon? what exactly are you missing? * dovecot can be used from postfix to replace cyrus sasl you even linked the documentation http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL * dovecot supports authentication for POP3/IMAP so hich sort fo client support are you missing? signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot SASL Client support?
On 2013-01-08 8:46 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2013 14:40, schrieb Charles Marcus: Hi all, I seem to recall mention of SASL client support either being added, but can't remember for sure. The wiki says nothing about Client support (now, or in the future)... http://wiki2.dovecot.org/Sasl So - is there support for it now? If not, is it planned for anytime soon? what exactly are you missing? * dovecot can be used from postfix to replace cyrus sasl you even linked the documentation http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL * dovecot supports authentication for POP3/IMAP so hich sort fo client support are you missing? CLIENT support... do you not understand the difference? http://www.postfix.org/SASL_README.html#client_sasl So that postfix can use dovecot-sasl for remotely authenticating against another SMTP server, ie, for secure relays... -- Best regards, Charles
Re: [Dovecot] Dovecot SASL Client support?
On 08.01.2013 14:59, Charles Marcus wrote: On 2013-01-08 8:46 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2013 14:40, schrieb Charles Marcus: Hi all, I seem to recall mention of SASL client support either being added, but can't remember for sure. The wiki says nothing about Client support (now, or in the future)... http://wiki2.dovecot.org/Sasl So - is there support for it now? If not, is it planned for anytime soon? what exactly are you missing? * dovecot can be used from postfix to replace cyrus sasl you even linked the documentation http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL * dovecot supports authentication for POP3/IMAP so hich sort fo client support are you missing? CLIENT support... do you not understand the difference? http://www.postfix.org/SASL_README.html#client_sasl So that postfix can use dovecot-sasl for remotely authenticating against another SMTP server, ie, for secure relays... If I understand you right, you would like to make postfix authenticate against a remote smtp server and relaying all emails to it. For this you don't need dovecot on your site. I use it as follows on my debian lenny. installed packages: postfix, libsasl2-modules needed main.cf configuration options: ... relayhost = [the.relayserver.com] smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd smtp_use_tls = yes smtp_sasl_security_options = noanonymous ... Content of /etc/postfix/relay_passwd: the.relayserver.com u...@domain.com:PASSWORD regards Urban
Re: [Dovecot] Dovecot SASL Client support?
Am 08.01.2013 16:43, schrieb Urban Loesch: For this you don't need dovecot on your site. I use it as follows on my debian lenny. installed packages: postfix, libsasl2-modules needed main.cf configuration options: ... relayhost = [the.relayserver.com] smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd smtp_use_tls = yes smtp_sasl_security_options = noanonymous but he wants to use dovecot and uninstall cyrus-sasl-lib for whatever reason - it makes sense to use dovecot for SASL auth to make sure using the same auth-mechs and password databases in SMTP / IMAP / POP3 but i see no sense in using dovecot here you do NOT want to authenticate with your passwords on a foreign server nor leave the option to this due accident signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot SASL Client support?
On Tue, Jan 08, 2013 at 08:59:09AM -0500, Charles Marcus wrote: So that postfix can use dovecot-sasl for remotely authenticating against another SMTP server, ie, for secure relays... I don't think this makes sense for Dovecot to implement -- maybe P@rick and/or Timo will correct this if I am wrong. Server SASL is a natural offshoot of an imapd, because the same credentials are used, and just as with an IMAP client, the imapd merely has to validate the credentials. Client SASL is different. The credentials are not necessarily in use by the imapd otherwise, and the job of the client SASL library is to generate the authentication, not to validate it. I don't expect to see Dovecot providing client SASL. You mention secure relays; for this I generally use OpenVPN. With a tunnel between the sending and relaying systems, the mail goes through said tunnel. Another good choice where this might not be possible is to use TLS certificate authentication: http://www.postfix.org/TLS_README.html#server_access http://www.postfix.org/TLS_README.html#client_tls_policy -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: [Dovecot] Dovecot SASL Client support?
On 2013-01-08 10:57 AM, Reindl Harald h.rei...@thelounge.net wrote: but he wants to use dovecot and uninstall cyrus-sasl-lib for whatever reason - it makes sense to use dovecot for SASL auth to make sure using the same auth-mechs and password databases in SMTP / IMAP / POP3 but i see no sense in using dovecot here you do NOT want to authenticate with your passwords on a foreign server nor leave the option to this due accident sigh You're ignoring obvious scenarios... What if I want to use a paid relay service that requires secure AUTH? Or use a relay that I control, but must be accessed over a public network (like the internet)? Right now I have to use (as you pointed out) cyrus-sasl, because dovecot-sasl doesn't (apparently) support client-side sasl at this time. I'd prefer to not have to install cyrus-sasl just to do it. On 2013-01-08 12:12 PM, /dev/rob0 r...@gmx.co.uk wrote: I don't expect to see Dovecot providing client SASL. I absolutely do recall Timo discussing implementing it at some point - this way dovecot could actually provide its own submission agent (one reason I'd love to see this would be the ability to DISABLE the 'Save copy to Sent folder' option in mail clients and do that on the server so the message doesn't have to be transferred over the wire twice, which is one thing I *love* about gmail). -- Best regards, Charles
Re: [Dovecot] Dovecot SASL Client support?
Am 08.01.2013 18:55, schrieb Charles Marcus: I absolutely do recall Timo discussing implementing it at some point - this way dovecot could actually provide its own submission agent (one reason I'd love to see this would be the ability to DISABLE the 'Save copy to Sent folder' option in mail clients and do that on the server so the message doesn't have to be transferred over the wire twice, which is one thing I *love* about gmail) that would make dovecot to a MTA, but how do you explain this the MUA aka mail-client? gmail can do it because it is a webinterface not acting with mail-protocols on the user side with standard protocols this is not the way you can go even if dovecot would have it's own SMTP implementation no client expects such non-standard things as other example: dbmail could easily move messages to different folders becasue it only has to update one reference but you can't do it this way with IMAP signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot SASL Client support?
On 2013-01-08 1:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 08.01.2013 18:55, schrieb Charles Marcus: I absolutely do recall Timo discussing implementing it at some point - this way dovecot could actually provide its own submission agent (one reason I'd love to see this would be the ability to DISABLE the 'Save copy to Sent folder' option in mail clients and do that on the server so the message doesn't have to be transferred over the wire twice, which is one thing I *love* about gmail) that would make dovecot to a MTA, No it wouldn't, any more than having dovecot-sasl provide SERVER-side sasl support for the postfix submission service. but how do you explain this the MUA aka mail-client? gmail can do it because it is a webinterface not acting with mail-protocols on the user side Wrong... I hate the gmail web interface, and only access my gmail accounts through IMAP+Thunderbird, and for those accounts, I can disable the 'Save copy to sent folder' option, and sent messages still show up in the sent folder. with standard protocols this is not the way you can go even if dovecot would have it's own SMTP implementation no client expects such non-standard things The client doesn't have to expect or know *anything*... the *user* simply would have to know that they can disable that option for that account. as other example: dbmail could easily move messages to different folders becasue it only has to update one reference but you can't do it this way with IMAP Dovecot moves are simply renames (ie, linux 'mv' command), so are pretty much instantaneous. -- Best regards, Charles
Re: [Dovecot] Dovecot SASL Client support?
* /dev/rob0 dovecot@dovecot.org: On Tue, Jan 08, 2013 at 08:59:09AM -0500, Charles Marcus wrote: So that postfix can use dovecot-sasl for remotely authenticating against another SMTP server, ie, for secure relays... I don't think this makes sense for Dovecot to implement -- maybe P@rick and/or Timo will correct this if I am wrong. That's a difficult subject, because I am not the author of Dovecot. So whatever I say, Timo definitely has the last word on this. But since you invited me, here are my thoughts: At the moment Dovecot does not implement an SMTP/LMTP client. This might change, when Timo decides to implement all of the LEMONADE feature, which at some point require the IMAP server to edit and send messages on behalf of a (mobile) client. Timo will shed more light on his plans. IF that part will be implemented it MAY make sense to add the AUTH capability to the SMTP/LMTP client, because the receiving SMTP/LMTP server MAY require it. IF at that point Dovecot becomes capable to AUTH on the client side, it MAY share that capability with another program e.g. Postfix. At the moment Postfix uses a simple IF/THEN mechanism, which is configured in two columns in and provided via smtp_sasl_password_maps: IF HOST THEN IDENTITY If Postfix were to use Dovecot as AUTH service it would have to query Dovecot for every hosts it contacts. Dovecot would have to know when Postfix would have to use AUTH, it would have to choose the apropriate SASL mechanism and it would have to guide Postfix through the mechanisms steps including handing over the identity when required. All this to solve a problem that already has been solved. My personal opinion/preference is: Use Cyrus SASL when you need SMTP AUTH on a Boundary Server, a Relay or if you need SASL on the client side. Use Dovecot SASL if your mail service offers SMTP and also POP/IMAP on the same system and/or if you combine more roles (mail server, Boundary Server, Relay, Gateway etc.). Server SASL is a natural offshoot of an imapd, because the same credentials are used, and just as with an IMAP client, the imapd merely has to validate the credentials. Client SASL is different. The credentials are not necessarily in use by the imapd otherwise, and the job of the client SASL library is to generate the authentication, not to validate it. recognize, choose and generate. I don't expect to see Dovecot providing client SASL. Neither do I, but it's not upon me to tell. :) p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: [Dovecot] Dovecot SASL Client support?
Hi At the moment Dovecot does not implement an SMTP/LMTP client. This might change, when Timo decides to implement all of the LEMONADE feature, which at some point require the IMAP server to edit and send messages on behalf of a (mobile) client. Timo will shed more light on his plans. Are you thinking about burl smtp? Someone from Apple implemented this for postfix some years back, but it doesn't seem to have made it into mainline (I think through oversight and Apple not pushing a second time though...) It will need client support, but my design would be something like an IMAP extension which works something like SMTP *this* specific message using these login details and these sender/recipient details. That way the mail client can completely generate the mail using any IMAP tricks at it's disposal to minimise traffic, once the mail is generated and in some location, eg Sent, Drafts or INBOX as per your preference, then finally instructing the server to push it into the normal SMTP system (for bonus marks it could forward the clients IP using X-FORWARDED-FOR so that the SMTP can make decisions based on IP address). This design gives you all the benefits of keeping the SMTP system, minimises traffic, allows for storing Sent Items or not as per your preference and avoids the use of magic folders. Now all we need is client support... Note there is a feature of Courier which does something similar, but it uses magic folders (ideally we want to be able to smtp any message in any folder in order that we can easily implement our preferred storage policies) http://www.courier-mta.org/imap/INSTALL.html#imapsend Ed W
Re: [Dovecot] Dovecot SASL Client support?
On 2013-01-08 3:34 PM, Ed W li...@wildgooses.com wrote: It will need client support, but my design would be something like an IMAP extension which works something like SMTP *this* specific message using these login details and these sender/recipient details. I would just like to be able tell postfix to use dovecot-sasl for client side auth as well as server side, so I don't have to maintain cyrus-sasl just for the client side part. That is all. -- Best regards, Charles
Re: [Dovecot] Dovecot SASL Client support?
* Ed W li...@wildgooses.com: Hi At the moment Dovecot does not implement an SMTP/LMTP client. This might change, when Timo decides to implement all of the LEMONADE feature, which at some point require the IMAP server to edit and send messages on behalf of a (mobile) client. Timo will shed more light on his plans. Are you thinking about burl smtp? Yes, I am. Someone from Apple implemented this for postfix some years back, but it doesn't seem to have made it into mainline (I think through oversight and Apple not pushing a second time though...) IIRC Wietse didn't want to implement it (at that time). It will need client support, but my design would be something like an IMAP extension which works something like SMTP *this* specific message using these login details and these sender/recipient details. Many mobile provides would support it, because it would help them to solve bandwidth and battery problems. They do all kinds of tricks to save energy e.g. send silent (hidden) SMS to notify of incoming mail instead of IDLEing, because IDLE costs much more battery power. That way the mail client can completely generate the mail using any IMAP tricks at it's disposal to minimise traffic, once the mail is generated and in some location, eg Sent, Drafts or INBOX as per your preference, then finally instructing the server to push it into the normal SMTP system (for bonus marks it could forward the clients IP using X-FORWARDED-FOR so that the SMTP can make decisions based on IP address). This design gives you all the benefits of keeping the SMTP system, minimises traffic, allows for storing Sent Items or not as per your preference and avoids the use of magic folders. Now all we need is client support... I know. Note there is a feature of Courier which does something similar, but it uses magic folders (ideally we want to be able to smtp any message in any folder in order that we can easily implement our preferred storage policies) http://www.courier-mta.org/imap/INSTALL.html#imapsend Yep. But that doesn't save bandwith etc. Anyway, we are moving OT. I'm out. :) p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
