Re: identify MUA connecting?
On Tue, 29 Jul 2014 00:49:37 +0200 Reindl Harald wrote: Am 28.07.2014 22:40, schrieb Peter Chiochetti: Am 2014-07-28 um 21:15 schrieb Reindl Harald: Am 28.07.2014 20:57, schrieb Rick Romero: Am 28.07.2014 19:58, schrieb Juan Pablo: The reason I am wanting to do this is I would like to know if people are getting their email on personal devices instead of work secured / standardized phones IMHO, client certificates would work work well here. I think Dovecot supports it yes, but you accept them or not that's a different story than log the MUA information Yes, it is a means to stop people from using insecure devices. a client certificate hadrly makes a device secure if the device is compromised your cert is gone So possibly a useful hint the OP may be interested in! Might well be that its the reason for learning which MUA was used? well, what client is used is impossible there is no user-agent like HTTP and even for HTTP the header is not mandatory and rqeuire it will break your web-app for anybody who cares for privacy while gain nothing Not in general: cyrus/imaps[9143]: client id: name Thunderbird version 24.6.0 I guess, dovecot simply must learn it. --Frank Elsner
Re: Exit status code 134; what is it, in the context of Dovecot Antispam plug-in?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 28 Jul 2014, Ben Johnson wrote:
I have some debugging output in my pipe script; the output looks
How does your script looks like?
Copying message contents to temporary file for debugging purposes; file
is: /tmp/sendmail-msg-7662.txt
Checking if the command-line input argument string (--spam) contains the
string ham or spam
Mode is SPAM
Calling (as user vmail) '/usr/lib/dovecot/deliver -d
sa-train...@example.com -m Training.SPAM -p
/tmp/sendmail-msg-7662.txt'
Exit status was 134
Check out your local /usr/include/sysexits.h, if the exit code is defined
there. It's not in mine.
Yet, I'm able to copy the above command and execute it manually, via the
command-line, and it works (and by works, I mean to say that the
behavior is correct and exactly as expected; I receive the Spam email
at the designated mailbox). Here's how I'm calling it when it works
perfectly well (as root):
# su -c '/usr/lib/dovecot/deliver -d sa-train...@example.com -m
Training.HAM -p /tmp/sendmail-msg-7460.txt' vmail
Any idea what status 134 might be or how to work around it? It looks to
be some kind of temporary failure exception, but that is less than
informative in this context.
# 2.2.9: /etc/dovecot/dovecot.conf
# OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS
plugin {
antispam_backend = pipe
antispam_debug_target = syslog
antispam_pipe_program = /bin/bash
antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh
antispam_pipe_program_notspam_arg = --ham
antispam_pipe_program_spam_arg = --spam
antispam_pipe_tmpdir = /tmp
antispam_spam_pattern_ignorecase = SPAM;JUNK
antispam_trash_pattern_ignorecase = trash;Deleted *
antispam_verbose_debug = 1
}
- --
Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBU9dJrnz1H7kL/d9rAQIskggAt2Otvh4sHZPrmYNm2aSiUwJqarmZmiLV
KrXuMwuvDs33Wd60Bihqjykw96fwz3v+jQuqx+t/V+uN/jRffFpp98aUA4rR9rZ6
AJ3HJfPTyf11Pi9cCG8EhqmY9amPRFrp1Ox+NCg4Jt2liUPzmdtPe6+OUR+QlUdR
Dr2Q6nyH+0sA948mnihJRVERf/oY+7/1s/UTLtCyyGGm4nXy9yoFWVeGxIybXF8G
HMH0I1CYCvKVtmh3o/6IaqJD7IIvJGcUPcEiSNtoKAUC5hu1IhwwkbZnD9IEiigG
HPDL0JIBZBleU8/6SC+e7eP7SF6deu4db1E/I45JVNOZLsZjzgtIVA==
=5sDi
-END PGP SIGNATURE-
Re: identify MUA connecting?
Am 29-07-2014 09:08, schrieb Frank Elsner: On Tue, 29 Jul 2014 00:49:37 +0200 Reindl Harald wrote: Am 28.07.2014 22:40, schrieb Peter Chiochetti: Am 2014-07-28 um 21:15 schrieb Reindl Harald: Am 28.07.2014 20:57, schrieb Rick Romero: Am 28.07.2014 19:58, schrieb Juan Pablo: The reason I am wanting to do this is I would like to know if people are getting their email on personal devices instead of work secured / standardized phones IMHO, client certificates would work work well here. I think Dovecot supports it yes, but you accept them or not that's a different story than log the MUA information Yes, it is a means to stop people from using insecure devices. a client certificate hadrly makes a device secure if the device is compromised your cert is gone So possibly a useful hint the OP may be interested in! Might well be that its the reason for learning which MUA was used? well, what client is used is impossible there is no user-agent like HTTP and even for HTTP the header is not mandatory and rqeuire it will break your web-app for anybody who cares for privacy while gain nothing Not in general: cyrus/imaps[9143]: client id: name Thunderbird version 24.6.0 I guess, dovecot simply must learn it. But this depend on if some Mailheader (X-mailer, User-Agent (k9), ...) are set. I'm sure this could be logged with sieve. I haven't seen a option on http://wiki2.dovecot.org/Variables for normal dovecot log, maybe there is one. Cheers Aleks
Re: identify MUA connecting?
29.07.2014 09:08, Frank Elsner: Not in general: cyrus/imaps[9143]: client id: name Thunderbird version 24.6.0 I guess, dovecot simply must learn it. Dovecot already knows about the ID fields a client sends. It just doesn't log them by default. This default, of course, can be changed - by setting imap_id_log appropriately. For example imap_id_log = * will log all ID info a client sends. Obviously, if a client doesn't send ID info, there's nothing dovecot can do about it, though. -- Regards mks
Re: dovecot-2-2-pigeonhole-92405f753f6a - 77e6a42bff9b
On 29 Jul 2014, at 06:10, Tamsy dovecot-l...@mohtex.net wrote: Just a report to Stephan: I tried to compile two builds from the Mercurial: - dovecot-2-2-pigeonhole-92405f753f6a - dovecot-2-2-pigeonhole-77e6a42bff9b Both builds fail to compile with the same following error: 8 ../../src/lib-sieve-tool/.libs/libsieve-tool.a(sieve-tool.o): In function `sieve_tool_open_output_stream': /usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b/src/lib-sieve-tool/sieve-tool.c:518: undefined reference to `o_stream_create_fd_autoclose' ../../src/lib-sieve/.libs/libdovecot-sieve.so: undefined reference to `i_stream_create_fd_autoclose' You need to compile against a newer Dovecot hg version.
Re: Dovecot mailstore performance tuning
On 22 Jul 2014, at 04:57, Murray Trainer mtrai...@westnet.com.au wrote: We have a couple of dovecot director proxies and six backed mailstores each accessing mailboxes stored on five NFSv4 filsystems with about 1TB of mail on each in maildir format. We have about 800 max users on each mailstore at peak times and performance appears to starting to degrade at these times. The mailstores are pretty recent hardware with 64GB of RAM and 24 cores. The NFS storage is EMC VNX and we are doing about 250 I/O per sec upto max of 500 on each filesystem. I need to squeeze more performance out of these servers whether that is in the NFS client, Dovecot or Linux OS/kernel areas. We use LDAP for auth and I am doing some tuning in that area. The NFS filesystems are mounted with the options below: 10.11.0.238:/mailbox_store_01 on /home1 type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,nordirplus,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.11.0.96,local_lock=none,addr=10.11.0.238) Does relatime work with NFS? If yes, changing it to noatime would save some I/O. maildir_very_dirty_syncs=yes should be helpful. # 2.2.9: /etc/dovecot/dovecot.conf mailbox_list_index=yes might be useful, although it has had some further performance improvements since v2.2.13. I should try to make v2.2.14 soon.. quota = maildir Dict file quota would be a bit faster than maildir++ quota.
Re: dovecot-2-2-pigeonhole-92405f753f6a - 77e6a42bff9b
Timo Sirainen wrote on 29.07.2014 18:09: On 29 Jul 2014, at 06:10, Tamsy dovecot-l...@mohtex.net wrote: Just a report to Stephan: I tried to compile two builds from the Mercurial: - dovecot-2-2-pigeonhole-92405f753f6a - dovecot-2-2-pigeonhole-77e6a42bff9b Both builds fail to compile with the same following error: 8 ../../src/lib-sieve-tool/.libs/libsieve-tool.a(sieve-tool.o): In function `sieve_tool_open_output_stream': /usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b/src/lib-sieve-tool/sieve-tool.c:518: undefined reference to `o_stream_create_fd_autoclose' ../../src/lib-sieve/.libs/libdovecot-sieve.so: undefined reference to `i_stream_create_fd_autoclose' You need to compile against a newer Dovecot hg version. Thank you for the hint. On Dovecot 2.2.13 now but will upgrade soonest to the latest HG and let you know.
Re: Multiple servers and NFS
On 7/29/14, Daniel Parthey kabelp...@kabelmail.de wrote: Nick Edwards wrote: On 7/26/14, Robert Schetterer r...@sys4.de wrote: Am 25.07.2014 um 16:12 schrieb Eduardo Ramos: I did not understand what the advantage of use dovecot LMTP with director too. in very short words... with nfs ,the director should avoid concurrent events which may happen with lmtp too, depending to multiple server setup using director was considered in risk assessment as its another point of failure, and weighed against its claimed benefit, the decision was made its not justified. mail_location = maildir:/mail/%1n/%1.1n/%2.1n/%n/Maildir:INDEX=MEMORY With maildir you won't have data-loss without the director, since the index files are auto-regenerated without any problem. disagree, if we'd had data loss we would have a case to use director, we also had none when we were using qmail and vpopmail, if dovecot did, and as said we are yet to see it, but if it did have data loss, than thats dovecots design issue, but I have no doubt it is that much of an issue. and from memory the only difference is some messages that just arrive may or may not appear immediately, this is only a problem with imap, and of all the users, we have a some total of about 200 that bother with imap, the other 100K plus use pop3 With mdbox on NFS and no director, you will have data-loss sooner or later: irrelevant, we use Maildir, it is time proved.
problem migrating shared folders from cyrus to dovecot
Hi all, We face a problem migrating shared mailboxes from an old cyrus server to dovecot. Whereas migrating regular users works like a charm, the shared mailboxes cannot be migrated. dsync/doveadm states: Error: Failed to access mailbox INBOX: Mailbox does not exist. This is somehow true since the shared mailboxes live not under user.mailbox but rather under shared.mailbox (cyrus special). Has anyone a solution for this peculiar problem? Cheers, -- j.hofmüllerhttp://thesix.mur.at/ signature.asc Description: OpenPGP digital signature
incremental mailbox syncs for quick migration
Hi all, We are facing quite large mailboxes (10GB) in our migration from cyrus to dovecot. I did a test on one mailbox and repeated the sync a couple of times with the expected result that the second, third, etc. sync took only seconds compared to minutes for the first sync. We use this command to sync a mailbox: doveadm backup -R -u USER imapc: Are there any problems to be expected when we first do a sync for all mailboxes but do not migrate the users right away but instead do the actual migration using a second sync? Cheers, -- j.hofmüllerhttp://thesix.mur.at/ signature.asc Description: OpenPGP digital signature
LMTP during dsync migration
Hi all, Another question regarding migration. While migrating a mailbox with dsync is it safe to deliver mail via LMTP to the new (target) mailbox or is it wiser to deactivate LMTP delivery to this mailbox until it's fully migrated? And what methods could I use to stop delivery to a mailbox during migration? Our user data is stored on an LDAP server. Cheers, -- j.hofmüllerhttp://thesix.mur.at/ signature.asc Description: OpenPGP digital signature
Missing IMAP Subfolders
I've recently encountered an issue with my IMAP folders on Dovecot 2.0.19. When I telnet into my account and perform a list, I get the following response: A list * * LIST (\Unmarked) . INBOX A OK List completed. However I know there are subfolders here and have examined the server directly via SSH and strangely: a select INBOX.Clients * OK [CLOSED] Previous mailbox closed. * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1394028715] UIDs valid * OK [UIDNEXT 1] Predicted next UID * OK [HIGHESTMODSEQ 1] Highest a OK [READ-WRITE] Select completed. When I also subscribe to a couple if these which I am able to to do despite not being able to LIST them, I get this with LIST-EXTENDED: a04 LIST (SUBSCRIBED RECURSIVEMATCH) * * * LIST (\Subscribed \NonExistent) . INBOX (CHILDINFO (SUBSCRIBED)) * LIST (\Subscribed \NonExistent) . INBOX.Clients (CHILDINFO (SUBSCRIBED)) * LIST (\Subscribed \NonExistent) . INBOX.Clients.Bob a04 OK List completed. Just not sure why a LIST is not giving me a full list as it's causing problems subscribing to these with Mail Clients. Any help is appreciated!
Re: LMTP during dsync migration
On 29.7.2014 15:48, Jogi Hofmüller wrote: Hi all, Another question regarding migration. While migrating a mailbox with dsync is it safe to deliver mail via LMTP to the new (target) mailbox or is it wiser to deactivate LMTP delivery to this mailbox until it's fully migrated? And what methods could I use to stop delivery to a mailbox during migration? Our user data is stored on an LDAP server. Cheers, Considering you're planning to use doveadm backup, you can't deliver into the new mailbox. From dsync man page: backup - Backup mails from default mail location to location2 (or vice versa, if -R parameter is given). No changes are ever done to the source location. Any changes done in destination are discarded. Unless I misunderstood something, this means that if you deliver messages to the new mailbox, next run of doveadm backup will remove them.
Re: [Dovecot] Converting old emails to compressed format
Hi, On Fri, Feb 28, 2014 at 12:18 AM, Renaud Allard ren...@allard.it wrote: I know this question has already been asked, but I would really like a solution here as I tried all I could find on the wiki or mail archives I am now running dovecot 2.2.12 Compression works fine for new mails, so zlib works Mails are currently stored using dbox So I tried for testing dsync -D -v mirror -u user -m Archives dbox:~/temp dsync -o plugin/zlib_save=xz -D -v mirror -u user -m Archives dbox:~/temp dsync -o plugin/zlib_save= -D -v mirror -u user -m Archives dbox:~/temp dsync -o plugin/zlib_save= -D -v mirror -u user -m Archives maildir:~/temp dsync -o plugin/zlib_save=xz -D -v mirror -u user -m Archives maildir:~/temp And also converting again those maildir messages to dbox (just in case it wouldn't work from dbox format) And also with backup instead of mirror None of this actually works, mails are indeed copied, but not compressed So I am wondering if there is a way to compress those mails? I'm now facing the same issue with 2.2.13. zlib is working for new mails but as opposed to some information I found dsync (backup) does not convert old mails to compressed. For example this post suggests that it should happen: http://thr3ads.net/dovecot/2013/07/2663810-dsync-backup-mails-compressed and also some Dovecot book also states to convert the mailbox just use dsync backup after zlib is enabled. Still I'm not able to make it work. Any hints? Thanks, Wolfgang
Re: [Dovecot] Converting old emails to compressed format
Hello Wolfgang, On 29.07.2014 16:58, Wolfgang Rosenauer wrote: I'm now facing the same issue with 2.2.13. zlib is working for new mails but as opposed to some information I found dsync (backup) does not convert old mails to compressed. For example this post suggests that it should happen: http://thr3ads.net/dovecot/2013/07/2663810-dsync-backup-mails-compressed and also some Dovecot book also states to convert the mailbox just use dsync backup after zlib is enabled. Still I'm not able to make it work. You have to set the compression type with the zlib_save option. i.e.: -o plugin/zlib_save=gz Regards Christian
Re: [Dovecot] Converting old emails to compressed format
Am 29.07.2014 um 16:58 schrieb Wolfgang Rosenauer: I'm now facing the same issue with 2.2.13. zlib is working for new mails but as opposed to some information I found dsync (backup) does not convert old mails to compressed. i guess this is by design, perhaps a -force should be introduced Best Regards MfG Robert Schetterer -- [*] 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: identify MUA connecting?
On 28. jul. 2014 19.59.07 Juan Pablo juanpabl...@openmailbox.org wrote: Hello I am using dovecot 1.2.15 on ubuntu. dovecot -n is more usefull for more help ignore this maillist of unsupported version here is what settings i have in pluging section mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_group_events = no mail_log_fields = uid box msgid size Sent with AquaMail for Android http://www.aqua-mail.com
Re: Exit status code 134; what is it, in the context of Dovecot Antispam plug-in?
On 7/29/2014 3:13 AM, Steffen Kaiser wrote:
On Mon, 28 Jul 2014, Ben Johnson wrote:
I have some debugging output in my pipe script; the output looks
How does your script looks like?
http://pastebin.com/nh8SwQtw
Copying message contents to temporary file for debugging
purposes; file is: /tmp/sendmail-msg-7662.txt Checking if the
command-line input argument string (--spam) contains the string
ham or spam Mode is SPAM Calling (as user vmail)
'/usr/lib/dovecot/deliver -d sa-train...@example.com -m
Training.SPAM -p /tmp/sendmail-msg-7662.txt' Exit status was
134
Check out your local /usr/include/sysexits.h, if the exit code is
defined there. It's not in mine.
Exit code 134 is not defined in /usr/include/sysexits.h on my system.
Yet, I'm able to copy the above command and execute it manually,
via the command-line, and it works (and by works, I mean to
say that the behavior is correct and exactly as expected; I
receive the Spam email at the designated mailbox). Here's how
I'm calling it when it works perfectly well (as root):
# su -c '/usr/lib/dovecot/deliver -d sa-train...@example.com -m
Training.HAM -p /tmp/sendmail-msg-7460.txt' vmail
Any idea what status 134 might be or how to work around it? It
looks to be some kind of temporary failure exception, but that
is less than informative in this context.
# 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic
x86_64 Ubuntu 14.04.1 LTS plugin { antispam_backend = pipe
antispam_debug_target = syslog antispam_pipe_program = /bin/bash
antispam_pipe_program_args = /usr/local/bin/sa-learn-pipe.sh
antispam_pipe_program_notspam_arg = --ham
antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir =
/tmp antispam_spam_pattern_ignorecase = SPAM;JUNK
antispam_trash_pattern_ignorecase = trash;Deleted *
antispam_verbose_debug = 1 }
-- Steffen Kaiser
Is it possible that this is some kind of apparmor restriction? I ask
because apparmor is indeed installed on this machine.
If you examine the script source (cited above), you will see that I've
had to use the hammer that is strace to debug issues with Dovecot +
Antispam before... maybe it's worth trying in this case.
Happy to hear any further suggestions.
Thanks again,
-Ben
Re: [Dovecot] Converting old emails to compressed format
Am 29.07.2014 um 17:13 schrieb Christian Rohmann: Hello Wolfgang, On 29.07.2014 16:58, Wolfgang Rosenauer wrote: I'm now facing the same issue with 2.2.13. zlib is working for new mails but as opposed to some information I found dsync (backup) does not convert old mails to compressed. For example this post suggests that it should happen: http://thr3ads.net/dovecot/2013/07/2663810-dsync-backup-mails-compressed and also some Dovecot book also states to convert the mailbox just use dsync backup after zlib is enabled. Still I'm not able to make it work. You have to set the compression type with the zlib_save option. i.e.: -o plugin/zlib_save=gz Regards Christian thx for info i missed that Best Regards MfG Robert Schetterer -- [*] 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Converting old emails to compressed format
Hi Christian, On Tue, Jul 29, 2014 at 5:13 PM, Christian Rohmann crohm...@netcologne.de wrote: You have to set the compression type with the zlib_save option. i.e.: -o plugin/zlib_save=gz been there: dsync -o plugin/zlib_save=gz backup -u testy maildir:/srv/dovecot/testy/maildir.new doesn't make a difference unfortunately. My mailboxes are in maildir format and besides enabling zlib I do not change the format. My testmailbox has only one message but this still is uncompressed after dsync. Where is Peer who wrote in his book that this should just work? Thanks, Wolfgang
Re: [Dovecot] Converting old emails to compressed format
Am 29.07.2014 um 17:22 schrieb Wolfgang Rosenauer: Hi Christian, On Tue, Jul 29, 2014 at 5:13 PM, Christian Rohmann crohm...@netcologne.de wrote: You have to set the compression type with the zlib_save option. i.e.: -o plugin/zlib_save=gz been there: dsync -o plugin/zlib_save=gz backup -u testy maildir:/srv/dovecot/testy/maildir.new doesn't make a difference unfortunately. My mailboxes are in maildir format and besides enabling zlib I do not change the format. My testmailbox has only one message but this still is uncompressed after dsync. Where is Peer who wrote in his book that this should just work? Thanks, Wolfgang perhaps its a version bug, is see, i have to test it my own for verify Best Regards MfG Robert Schetterer -- [*] 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, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
PAM and YubiKeys
Hi List,
I am trying to get authentication to Dovecot with a Yubikey OTP.
I have the PAM modules installed and can successfully authenticate to
ssh with the Yubikey, so I am confident that the network level and
Yubikey configuration is correct. I can also authenticate to Dovecot via
PAM using a plain password, however when I try to use the Yubikey
authentication with Dovecot things don't go well. Network monitoring
reveals that the software does not even attempt to connect to the
authentication servers.
My Dovecot authentication is configured as follows :-
passdb {
driver = pam
args = failure_show_msg=yes dovecot
override_fields = proxy host=1.2.3.4 master=XX pass=XX
}
userdb {
driver = passwd-file
args = username_format=%u /etc/dovecot/users
}
The dovecot Pam config file is :-
auth sufficient pam_yubico.so id=9 key=xxx
authfile=/etc/yubikey_mappings debug
@include common-auth
@include common-account
@include common-session
When failing to authenticate with Dovecot, the PAM debug log shows :-
[../pam_yubico.c:parse_cfg(761)] called.
[../pam_yubico.c:parse_cfg(762)] flags 0 argc 4
[../pam_yubico.c:parse_cfg(764)] argv[0]=id=xx
[../pam_yubico.c:parse_cfg(764)] argv[1]=key=xx
[../pam_yubico.c:parse_cfg(764)] argv[2]=authfile=/etc/yubikey_mappings
[../pam_yubico.c:parse_cfg(764)] argv[3]=debug
[../pam_yubico.c:parse_cfg(765)] id=xx
[../pam_yubico.c:parse_cfg(766)] key=x
[../pam_yubico.c:parse_cfg(767)] debug=1
[../pam_yubico.c:parse_cfg(768)] alwaysok=0
[../pam_yubico.c:parse_cfg(769)] verbose_otp=0
[../pam_yubico.c:parse_cfg(770)] try_first_pass=0
[../pam_yubico.c:parse_cfg(771)] use_first_pass=0
[../pam_yubico.c:parse_cfg(772)] authfile=/etc/yubikey_mappings
[../pam_yubico.c:parse_cfg(773)] ldapserver=(null)
[../pam_yubico.c:parse_cfg(774)] ldap_uri=(null)
[../pam_yubico.c:parse_cfg(775)] ldapdn=(null)
[../pam_yubico.c:parse_cfg(776)] user_attr=(null)
[../pam_yubico.c:parse_cfg(777)] yubi_attr=(null)
[../pam_yubico.c:parse_cfg(778)] yubi_attr_prefix=(null)
[../pam_yubico.c:parse_cfg(779)] url=(null)
[../pam_yubico.c:parse_cfg(780)] capath=(null)
[../pam_yubico.c:parse_cfg(781)] token_id_length=12
[../pam_yubico.c:parse_cfg(782)] mode=client
[../pam_yubico.c:parse_cfg(783)] chalresp_path=(null)
[../pam_yubico.c:pam_sm_authenticate(823)] get user returned: jack
[../pam_yubico.c:pam_sm_authenticate(929)] conv returned 44 bytes
[../pam_yubico.c:pam_sm_authenticate(947)] Skipping first 0 bytes.
Length is 44, token_id set to 12 and token OTP always 32.
[../pam_yubico.c:pam_sm_authenticate(954)] OTP:
ccbcitfdueencldivbcjvghvikdtrnujbgubirru ID: ccbcitfd
[../pam_yubico.c:pam_sm_authenticate(985)] ykclient return value (101):
Could not parse server response
[../pam_yubico.c:pam_sm_authenticate(1038)] done. [Authentication
service cannot retrieve authentication info]
A successful authentication (via ssh) looks like
[../pam_yubico.c:parse_cfg(761)] called.
[../pam_yubico.c:parse_cfg(762)] flags 1 argc 4
[../pam_yubico.c:parse_cfg(764)] argv[0]=id=
[../pam_yubico.c:parse_cfg(764)] argv[1]=key=xx
[../pam_yubico.c:parse_cfg(764)] argv[2]=authfile=/etc/yubikey_mappings
[../pam_yubico.c:parse_cfg(764)] argv[3]=debug
[../pam_yubico.c:parse_cfg(765)] id=xx
[../pam_yubico.c:parse_cfg(766)] key=xxx
[../pam_yubico.c:parse_cfg(767)] debug=1
[../pam_yubico.c:parse_cfg(768)] alwaysok=0
[../pam_yubico.c:parse_cfg(769)] verbose_otp=0
[../pam_yubico.c:parse_cfg(770)] try_first_pass=0
[../pam_yubico.c:parse_cfg(771)] use_first_pass=0
[../pam_yubico.c:parse_cfg(772)] authfile=/etc/yubikey_mappings
[../pam_yubico.c:parse_cfg(773)] ldapserver=(null)
[../pam_yubico.c:parse_cfg(774)] ldap_uri=(null)
[../pam_yubico.c:parse_cfg(775)] ldapdn=(null)
[../pam_yubico.c:parse_cfg(776)] user_attr=(null)
[../pam_yubico.c:parse_cfg(777)] yubi_attr=(null)
[../pam_yubico.c:parse_cfg(778)] yubi_attr_prefix=(null)
[../pam_yubico.c:parse_cfg(779)] url=(null)
[../pam_yubico.c:parse_cfg(780)] capath=(null)
[../pam_yubico.c:parse_cfg(781)] token_id_length=12
[../pam_yubico.c:parse_cfg(782)] mode=client
[../pam_yubico.c:parse_cfg(783)] chalresp_path=(null)
[../pam_yubico.c:pam_sm_authenticate(823)] get user returned: jack
[../pam_yubico.c:pam_sm_authenticate(929)] conv returned 44 bytes
[../pam_yubico.c:pam_sm_authenticate(947)] Skipping first 0 bytes.
Length is 44, token_id set to 12 and token OTP always 32.
[../pam_yubico.c:pam_sm_authenticate(954)] OTP:
ccbcitfdetdfkbjrtfbuhgbtjgethkdebcgthgde ID: ccbcitfd
[../pam_yubico.c:pam_sm_authenticate(985)] ykclient return value (0):
Success
[../pam_yubico.c:authorize_user_token(221)] Using system-wide auth_file
/etc/yubikey_mappings
[../pam_yubico.c:check_user_token(178)] Authorization line:
jack:ccbcitfd
[../pam_yubico.c:check_user_token(182)] Matched user: jack
[../pam_yubico.c:check_user_token(187)] Authorization token:
ccbcitfd
Re: dovecot-2-2-pigeonhole-92405f753f6a - 77e6a42bff9b
Timo Sirainen wrote on 29.07.2014 18:09: On 29 Jul 2014, at 06:10, Tamsy dovecot-l...@mohtex.net wrote: Just a report to Stephan: I tried to compile two builds from the Mercurial: - dovecot-2-2-pigeonhole-92405f753f6a - dovecot-2-2-pigeonhole-77e6a42bff9b Both builds fail to compile with the same following error: 8 ../../src/lib-sieve-tool/.libs/libsieve-tool.a(sieve-tool.o): In function `sieve_tool_open_output_stream': /usr/local/src/dovecot-2-2-pigeonhole-77e6a42bff9b/src/lib-sieve-tool/sieve-tool.c:518: undefined reference to `o_stream_create_fd_autoclose' ../../src/lib-sieve/.libs/libdovecot-sieve.so: undefined reference to `i_stream_create_fd_autoclose' You need to compile against a newer Dovecot hg version. To Report back on this matter: After upgrading Dovecot to the latest HG version, Pigeonhole compiled nicely. Thank you Timo.
