On 08.01.2013 14:59, Charles Marcus wrote:

On 2013-01-08 8:46 AM, Reindl Harald h.reindl@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 user@domain.com:PASSWORD

regards Urban

On 2013-01-08 10:57 AM, Reindl Harald h.reindl@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 rob0@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

On 2013-01-08 1:52 PM, Reindl Harald h.reindl@thelounge.net wrote:

...

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)

Am 08.01.2013 18:55, schrieb Charles Marcus: 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

• /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

On 2013-01-08 3:34 PM, Ed W lists@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

• Ed W lists@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

• 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

Am 09.01.2013 11:36, schrieb Markus Schönhaber:

09.01.2013 09:52, Patrick Ben Koetter:

...

If it is as good as GNUTLS, I'd rather stick with Cyrus SASL.

Out of curiosity: what's so bad with GNUTLS?

google for "openvas gnutls"

• Aleksandar Lazic al-dovecot@none.at:

Am 09-01-2013 11:36, schrieb Markus Schönhaber:

...

09.01.2013 09:52, Patrick Ben Koetter:

...

If it is as good as GNUTLS, I'd rather stick with Cyrus SASL.

Out of curiosity: what's so bad with GNUTLS?

+1

I thought the same, you was faster for the question.

We've been hunting down interoperability problems on Debian/Ubuntu plattforms ever since Debian switched to GNUTLS. OpenLDAP, Postfix, Dovecot... you name it. We ended up rebuilding the packages with OpenSSL support.

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