[Dovecot] Passwordless auth?
Hey all,
I'm in the process of writing some scripts which I want to be able to take actions on my local mailbox. (For example, to move a subset of messages to the trash over time, if unread for a week. To act on messages in my learn-spam folder and then delete them).
What occured to me as being a Neat Idea is if Dovecot could honor ident (rfc1413) lookups, from trusted hosts (i.e. 127.0.0.1). In this way I get all the benefits of dovecot's indexing being updated and nice locking, but I don't have to leave my password laying around in a plaintext file.
(Yes, this assumes I'm running a shell on the mail server. I'm not concerned about the same level of security when you could simply cat my mail spool).
I'd definitely consider something like an SSH key with a forced command (I do see questions in the FAQ about making dovecot work over a socket connection), but that forgoes using standard imap clients.
I could also create a dovecot-only user with my UID and no other login privileges, but I'd like this to "just work" for anyone.
I don't know anything about if dovecot supports X509 auth, but this would require the client libraries to support such a thing, which not all do.
I'd love to hear about any other ways people have thought about to do this. Any ideas?
-Dan Mahoney
--
--------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org
On Thu, May 23, 2013 at 04:10:01PM -0700, Dan Mahoney, System Admin wrote:
I'd love to hear about any other ways people have thought about to do this. Any ideas?
Are you familiar with the mutt(1) MUA? I use it with a: set tunnel="MAILDIR=~/Mail/ /usr/libexec/dovecot/imap" So it speaks IMAP, but to its own /usr/libexec/dovecot/imap process, not through a network socket.
Maybe you could adapt this idea in some way.
http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
/dev/rob0 rob0@gmx.co.uk:
On Thu, May 23, 2013 at 04:10:01PM -0700, Dan Mahoney, System Admin wrote:
I'd love to hear about any other ways people have thought about to do this. Any ideas?
Are you familiar with the mutt(1) MUA? I use it with a: set tunnel="MAILDIR=~/Mail/ /usr/libexec/dovecot/imap" So it speaks IMAP, but to its own /usr/libexec/dovecot/imap process, not through a network socket.
Gnus can do the same thing, ie. run the daemon as its own subprocess (I used to do that back when I was running UoW imapd in the late 1990-ies, early 2000-ies).
Gnus can also run ssh in a subprocess, that ssh-es into the mail server, and then starts the imap daemon as a program on the other side, and communicate with IMAP over the SSH connection. I've done that as well.
Of course, both of those was with the old nnimap backend.
(And Gnus probably doesn't classify as a "standard imap client")
At 4PM -0700 on 23/05/13 you (Dan Mahoney, System Admin) wrote:
I'm in the process of writing some scripts which I want to be able to take actions on my local mailbox. (For example, to move a subset of messages to the trash over time, if unread for a week. To act on messages in my learn-spam folder and then delete them).
http://wiki2.dovecot.org/PreAuth
You can also use doveadm for quite a lot of this sort of administration; this may be easier if you're scripting in shell rather than something more sophisticated.
I'd definitely consider something like an SSH key with a forced command (I do see questions in the FAQ about making dovecot work over a socket connection), but that forgoes using standard imap clients.
Well, I'm not sure what you consider 'standard' here, but there are both Perl and Python IMAP libraries which will connect to a command rather than a socket. If you're using a client which insists on connecting to an (INET) socket, it's a little harder; while you can obviously connect preauthed imap to a listening socket with netcat, that's not remotely secure.
I could also create a dovecot-only user with my UID and no other login privileges, but I'd like this to "just work" for anyone.
I believe with the latest 2.2 you can also do this with Kerberos principals, if you're running Kerberos; I haven't looked into this yet, but I mean to (for much the same reason).
Ben
On Fri, 24 May 2013, Ben Morrow wrote:
At 4PM -0700 on 23/05/13 you (Dan Mahoney, System Admin) wrote:
I'm in the process of writing some scripts which I want to be able to take actions on my local mailbox. (For example, to move a subset of messages to the trash over time, if unread for a week. To act on messages in my learn-spam folder and then delete them).
Aah!
I came across this in the Q&A, and assumed such a thing wasn't possible:
-=-
Can Dovecot authenticate and work via UNIX sockets?
Dovecot authentication already works via UNIX sockets, but it only speaks its internal protocol. You could always create a "socket" passdb/userdb. Probably should be made compatible with "checkpassword" protocol. Patches welcome :)
-=-
Which could probably use some expansion/repointing. The "preauth" name kind of just implies in my mind "things you check before pam" -- I would have not looked there if not pointed.
You can also use doveadm for quite a lot of this sort of administration; this may be easier if you're scripting in shell rather than something more sophisticated.
I'm pretty much resigned to trying to parse the whole mailbox anyway, because I want functions like "when I move a message to the "threadkill" folder, move any message with the referenced messageid's in said message to folder X".
All this is in pursuit of making that little red number in my mail.app window meaningful -- and it seems the only real control plane mobile clients give you is the ability to move a message to a folder :)
I'd definitely consider something like an SSH key with a forced command (I do see questions in the FAQ about making dovecot work over a socket connection), but that forgoes using standard imap clients.
Well, I'm not sure what you consider 'standard' here, but there are both Perl and Python IMAP libraries which will connect to a command rather than a socket. If you're using a client which insists on connecting to an (INET) socket, it's a little harder; while you can obviously connect preauthed imap to a listening socket with netcat, that's not remotely secure.
I'm constructing a client, really. In perl, it looks like Mail::Box::Manager is the thing I want, in conjunction with the above.
I could also create a dovecot-only user with my UID and no other login privileges, but I'd like this to "just work" for anyone.
I believe with the latest 2.2 you can also do this with Kerberos principals, if you're running Kerberos; I haven't looked into this yet, but I mean to (for much the same reason).
we are at the day job, but I'm not doing so personally.
-Dan
--
--------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org
On Fri, 24 May 2013, Ben Morrow wrote:
At 4PM -0700 on 23/05/13 you (Dan Mahoney, System Admin) wrote:
I'm in the process of writing some scripts which I want to be able to take actions on my local mailbox. (For example, to move a subset of messages to the trash over time, if unread for a week. To act on messages in my learn-spam folder and then delete them).
http://wiki2.dovecot.org/PreAuth
You can also use doveadm for quite a lot of this sort of administration; this may be easier if you're scripting in shell rather than something more sophisticated.
I'd definitely consider something like an SSH key with a forced command (I do see questions in the FAQ about making dovecot work over a socket connection), but that forgoes using standard imap clients.
Well, I'm not sure what you consider 'standard' here, but there are both Perl and Python IMAP libraries which will connect to a command rather than a socket. If you're using a client which insists on connecting to an (INET) socket, it's a little harder; while you can obviously connect preauthed imap to a listening socket with netcat, that's not remotely secure.
I could also create a dovecot-only user with my UID and no other login privileges, but I'd like this to "just work" for anyone.
I believe with the latest 2.2 you can also do this with Kerberos principals, if you're running Kerberos; I haven't looked into this yet, but I mean to (for much the same reason).
Ben
To access the mail storage on the imap server you can just speak the imap protocol and authenticate against the imap server just like any other mail client would do. If you are using Kerberos and have a ticket granting ticket (after e.g. kinit) then the authentication against a properly configured imap server is done without typing passwords. If the imap server does support pam (and dovecot does) then this is handled there.
As an example I do attach a script that logs a user into an imap server using Kerberos authentication and then displays the mail quota. Any other action on the users mailboxes could be done as well. The script makes use of SASL, therefore by changing the authenticate call and the callback routine any other SASL mechanism could be used as well.
If you intend to perform tasks centrally for more than one user then doveadm is certainly the right choice as was pointed out already
For accessing local mailboxes (i.e. not stored on an imap server) I'd recommend one of the perl modules that can parse and process mailboxes (typically in mbox format)
Wolfgang
At 9AM +0200 on 24/05/13 you (Wolfgang.Friebel@desy.de) wrote:
On Fri, 24 May 2013, Ben Morrow wrote:
At 4PM -0700 on 23/05/13 you (Dan Mahoney, System Admin) wrote:
I could also create a dovecot-only user with my UID and no other login privileges, but I'd like this to "just work" for anyone.
I believe with the latest 2.2 you can also do this with Kerberos principals, if you're running Kerberos; I haven't looked into this yet, but I mean to (for much the same reason).
To access the mail storage on the imap server you can just speak the imap protocol and authenticate against the imap server just like any other mail client would do. If you are using Kerberos and have a ticket granting ticket (after e.g. kinit) then the authentication against a properly configured imap server is done without typing passwords. If the imap server does support pam (and dovecot does) then this is handled there.
I didn't quite mean that: yes, that is 'passwordless' in a sense, but you still have to have typed a password into kinit fairly recently.
What I meant was that with 2.2 it's finally possible to set a list of krb5 principals for imap which is different from the list in .k5login. This makes it possible to create special-purpose principals, which can have their keys put in a keytab, which can then log on as an ordinary imap user.
This is somewhat similar to the 'ssh keys with a forced command' idea, except that the whole thing is a good deal more secure because the keys can be cancelled centrally.
Ben
Hi,
I didn't quite mean that: yes, that is 'passwordless' in a sense, but you still have to have typed a password into kinit fairly recently.
What I meant was that with 2.2 it's finally possible to set a list of krb5 principals for imap which is different from the list in .k5login. This makes it possible to create special-purpose principals, which can have their keys put in a keytab, which can then log on as an ordinary imap user.
perhaps I misunderstand you, but something like
kinit -k -t /path/to/keytab
authenticates w/o the need of typing a password.
Cheers Dirk
At 5PM +0200 on 24/05/13 you (Dirk Jahnke-Zumbusch) wrote:
[I wrote:]
I didn't quite mean that: yes, that is 'passwordless' in a sense, but you still have to have typed a password into kinit fairly recently.
What I meant was that with 2.2 it's finally possible to set a list of krb5 principals for imap which is different from the list in .k5login. This makes it possible to create special-purpose principals, which can have their keys put in a keytab, which can then log on as an ordinary imap user.
perhaps I misunderstand you, but something like
kinit -k -t /path/to/keytab
authenticates w/o the need of typing a password.
Yes, but that means putting your ordinary user's key into a keytab, and since that key can (probably) be used for a whole lot more than just accessing IMAP, this isn't exactly very safe. The advantage of using a dedicated principal is that you can give it the minimum rights it needs to do its job, making the keytab much safer. You can also disable just that principal on the KDC if it gets compromised without locking the user out altogether.
Ben
participants (7)
-
/dev/rob0
-
Ben Morrow
-
Bob Miller
-
Dan Mahoney, System Admin
-
Dirk Jahnke-Zumbusch
-
Steinar Bang
-
Wolfgang.Friebel＠desy.de