Has anyone had success using the mod_auth_dovecot module via TCP socket?

[deoren]

Hi all,

Thanks for reading this.

Short version:

Anyone had success using the mod_auth_dovecot module with Prosody via
TCP socket?


Long version:

My end goal is to have Dovecot running on one box and Prosody on another
using mod_auth_dovecot to auth users.

For several months now I've had Prosody and Dovecot running on the same
box where Prosody authenticates via a UNIX socket. That works great.
I've begun the process of migrating the Prosody setup from the Dovecot
box where it uses a UNIX socket to another box where it would connect
via TCP/SSL.

That didn't work so well.

Sep 3 22:28:42 chatbox prosody[26878]: auth_dovecot: Dovecot connection
failure: No data read from socket: closed
Sep 3 22:28:42 chatbox prosody[26878]: modulemanager: Error
initializing module 'auth_dovecot' on 'example.org':
...s/mod_auth_dovecot/auth_dovecot/mod_auth_dovecot.lua:44: Could not
create a new SASL object#012stack
traceback:#012#011/usr/lib/prosody/core/modulemanager.lua:29: in
function </usr/lib/prosody/core/modulemanager.lua:29>#012#011[C]: in
function
'assert'#012#011...s/mod_auth_dovecot/auth_dovecot/mod_auth_dovecot.lua:44:
in main chunk#012#011(tail call): ?#012#011[C]: in function
'xpcall'#012#011/usr/lib/prosody/core/modulemanager.lua:29: in function
'pcall'#012#011/usr/lib/prosody/core/modulemanager.lua:171: in function
'do_load_module'#012#011/usr/lib/prosody/core/modulemanager.lua:249: in
function 'load'#012#011/usr/lib/prosody/core/modulemanager.lua:74: in
function '?'#012#011/usr/lib/prosody/util/events.lua:67: in function
'fire_event'#012#011/usr/lib/prosody/core/hostmanager.lua:97: in
function 'activate'#012#011/usr/lib/prosody/core/hostmanager.lua:44: in
function '?'#012#011/usr/lib/prosody/util/events.lua:67: in function
'fire_event'#012#011/usr/bin/prosody:331: in function
'prepare_to_start'#012#011/usr/bin/prosody:397: in main
chunk#012#011[C]: ?


So, I backed up and decided to first get Prosody working with Dovecot
over a local TCP socket on the Dovecot box. Dovecot is running with IMAP
TCP ports 143 (non-ssl) and 993 (ssl) open to localhost, so the ports
are open, but I get the same errors back.

In addition, I see this in the mail log:

Sep 4 00:03:07 chatbox dovecot: imap-login: Disconnected: Inactivity
(no auth attempts): rip=127.0.0.1, lip=127.0.0.1, secured


These are the Prosody settings I have in play for the dovecot auth
functionality:


authentication = "dovecot"

-- https://code.google.com/p/prosody-modules/wiki/mod_auth_dovecot
-- dovecot_auth_socket = "/var/spool/prosody/private/auth"

-- If true, sends the bare JID as authzid.
auth_append_host = true

-- Not needed since we're using a UNIX socket
dovecot_auth_host = "127.0.0.1"
dovecot_auth_port = "143"


My Prosody setup as told by 'prosodyctl about':


root@chatbox:/opt/prosody-modules# prosodyctl about
general error The version of LuaExpat on your system
does not support stanza size limits, which may leave servers on
untrusted networks (e.g. the internet) vulnerable to denial-of-service
attacks. You should upgrade to LuaExpat 1.3.0 or higher as soon as
possible. See http://prosody.im/doc/depends#luaexpat for more
information.
Prosody 0.10 nightly build 69 (2014-09-01, f1dd1716aa9d)

# Prosody directories
Data directory: /var/lib/prosody
Plugin directory: /opt/prosody-modules;/usr/lib/prosody/modules/
Config directory: /etc/prosody
Source directory: /usr/lib/prosody

# Lua environment
Lua version: Lua 5.1

Lua module search paths:
/usr/lib/prosody/?.lua
/usr/local/share/lua/5.1/?.lua
/usr/local/share/lua/5.1/?/init.lua
/usr/local/lib/lua/5.1/?.lua
/usr/local/lib/lua/5.1/?/init.lua
/usr/share/lua/5.1/?.lua
/usr/share/lua/5.1/?/init.lua

Lua C module search paths:
/usr/lib/prosody/?.so
/usr/local/lib/lua/5.1/?.so
/usr/lib/i386-linux-gnu/lua/5.1/?.so
/usr/lib/lua/5.1/?.so
/usr/local/lib/lua/5.1/loadall.so

LuaRocks: Not installed

# Lua module versions
lfs: LuaFileSystem 1.5.0
lxp: LuaExpat 1.2.0
pposix: 0.3.6
socket: LuaSocket 2.0.2
ssl: 0.3.2M


Even though I am under the impression that it doesn't do any good, I
tried flipping these settings as well:

* c2s_require_encryption
* s2s_secure_auth

No changes. If I change the host/port configuration to this:

dovecot_auth_host = "127.0.0.1"
dovecot_auth_port = "993"

I then see these entries:

Sep 4 00:04:17 chatbox dovecot: imap-login: Disconnected (no auth
attempts): rip=127.0.0.1, lip=127.0.0.1, secured
Sep 4 00:04:17 chatbox dovecot: imap-login: Disconnected (no auth
attempts): rip=127.0.0.1, lip=127.0.0.1, TLS handshaking: SSL_accept()
failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol
Sep 4 00:04:17 chatbox dovecot: imap-login: Disconnected (no auth
attempts): rip=127.0.0.1, lip=127.0.0.1, TLS handshaking: SSL_accept()
failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol

That is after I set Dovecot (2.0.x) to use loose SSL ciphers:

ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

At this point I'm not really sure what else to do. I've tried making TCP
socket connections with and without SSL and I'm not getting anywhere.

Thanks again for reading this.

[deoren]

I ended up going with a local Dovecot instance that was stripped down to
the point where it auth'd users against a MySQL DB and provided a UNIX
socket for Prosody to connect to. Instead of having Prosody auth against
a remote Dovecot server it uses a local instance of Dovecot and _that_
Dovecot instance auths against a remote database. This wasn't my first
choice, but it works.

Another problem that I ran into was Prosody starting before Dovecot.
Dovecot loads via Upstart and Prosody via an init.d script, so getting
the timing just right was a major pain. I tried removing init.d links
and setting the priority for Prosody lower (99), but the timing was
still hit/miss with more failures than otherwise.

I don't know whether it's Prosody's job or the plugin's, but once the
initial connection to the (UNIX) socket fails a later attempt isn't
made. Instead I have to manually restart Prosody (or use something like
Nagios to detect and auto-correct the situation).

A workaround for my setup is to create an /etc/default/prosody file and
insert a suitable delay there. The init.d script reads it by default, so
it ended up being the least invasive approach. I had removed the
/etc/init.d/prosody script (properly via update-rc.d) and created an
Upstart job conf file, but then the prosodyctl command kept reporting
that prosody wasn't running because the Prosody process didn't obtain an
exclusive lock on the pid file. It was a mess. I tried lots of
variations and would be happy to provide examples, but I scrapped that
attempt and went with something a little more simple.

I probably could have just stuck with "sleep 10" and that would have
been sufficient, but I opted to instead only allow Prosody to start if
Dovecot was already running.

I hope the snippet below is of use to someone.

############/etc/default/prosody#####################
#dovecot_process_to_verify="dovecot/anvil"
dovecot_process_to_verify="dovecot"
delay_seconds="6"

# Don't check for Dovecot process if we're rebooting/shutting down
if [ ! "$(runlevel | awk '{ print $2 }')" -eq 6 ]
then

# Wait for dovecot to come online and create the necessary UNIX
socket so
# Prosody is able to auth users.
while [ ! $(pgrep -f $dovecot_process_to_verify) ]
do
sleep $delay_seconds
done
fi
############/etc/default/prosody#####################

[Karsten Hoffmann]

You can use /etc/rc.local, see man rc.local for further details.


Am 17.09.2014 um 07:25 schrieb deoren:
> ppet bel

[Kim Alvefur]

Hi!

On 2014-09-04 07:11, deoren wrote:
> Anyone had success using the mod_auth_dovecot module with Prosody via
> TCP socket?

(snip)
> dovecot_auth_port = "993"

That's the IMAP-SSL port. mod_auth_dovecot talks a Dovecot-specific
protocol for authentication, not IMAP.

You'd need to configure dovecot something like this:

service auth {
inet_listener {
port = 9999
}
}

and then configure prosody to use that port + host.

--
Kim "Zash" Alvefur

[deoren]

On 2014-09-17 09:35, Karsten Hoffmann wrote:
> You can use /etc/rc.local, see man rc.local for further details.

Thanks, but I can get the Prosody daemon to start, I just had problems
delaying it long enough for all other dependencies to be loaded and
fully operational.

[deoren]

Fantastic, thanks for responding and showing me what I was doing wrong.
I obviously have a lot to learn still about Dovecot. :)

[deoren]

On 2014-09-17 00:25, deoren wrote:
> I hope the snippet below is of use to someone.
>
> ############/etc/default/prosody#####################
> #dovecot_process_to_verify="dovecot/anvil"
> dovecot_process_to_verify="dovecot"
> delay_seconds="6"
>
> # Don't check for Dovecot process if we're rebooting/shutting down
> if [ ! "$(runlevel | awk '{ print $2 }')" -eq 6 ]
> then
>
> # Wait for dovecot to come online and create the necessary UNIX
> socket so
> # Prosody is able to auth users.
> while [ ! $(pgrep -f $dovecot_process_to_verify) ]
> do
> sleep $delay_seconds
> done
> fi
> ############/etc/default/prosody#####################

I haven't worked with shell scripts on a daily basis in many years, so I
introduced an error that was giving me a bit of grief. Turns out the
syntax was wrong and I failed to toss the output (/dev/null).

Working code block:

############/etc/default/prosody#####################

dovecot_process_to_verify="dovecot"
delay_seconds="6"

# Don't check for Dovecot process if we're rebooting/shutting down
if [ ! "$(runlevel | awk '{ print $2 }')" -eq 6 ]
then

# Wait for dovecot to come online and create the necessary UNIX
socket so
# Prosody is able to auth users.

while ! $(pgrep -f $dovecot_process_to_verify > /dev/null)

[rainer zufall]

Hi deoren,

you had Prosody with mod_auth_dovecot module working, using a UNIX socket. Could you sent me the prosody config for that because it is not working for me?

I have prosody and dovecot running on the same machine. Is there anything to regard while using that? Or do I just have to adjust the prosody config??

[fauno]

fwiw, the tcp auth for dovecot is not done to imap or pop ports, but you
have to open an auth inet_listener on your config.

look in /etc/dovecot/conf.d/10-master.conf for service auth blocks.


i have this in mine:

service auth {

unix_listener /run/dovecot/auth-prosody {
mode = 0660
group = prosody
user = prosody
}
}

and you can use an inet_listener, for instance:
http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL

--
:D

[rainer zufall]

Thanks a lot for the help. Seems I got the next problem. I made the following configurations:

/etc/dovecot/conf.d/10-master.conf:

service auth {

unix_listener /run/dovecot/auth-prosody {

mode = 0660

user = prosody

group = prosody

}

}

/etc/prosody/prosody.cfg.lua:

authentication = "dovecot"

dovecot_auth_socket = "/run/dovecot/auth-prosody"

auth_append_host = false

dovecot_auth_host = "127.0.0.1"

dovecot_auth_port = "143"

I restarted dovecot and then prosody. But Prosody has problems to create a new SASL object:

Feb 02 22:33:18 general info Hello and welcome to Prosody version 0.9.7

Feb 02 22:33:18 general info Prosody is using the select backend for connection handling

Feb 02 22:36:18 auth_dovecot error Dovecot connection failure: No data read from socket: closed

Feb 02 22:36:18 modulemanager error Error initializing module 'auth_dovecot' on 'localhost': ...s/mod_auth_dovecot/auth_dovecot/mod_auth_dovecot.lua:44: Could not create a new SASL object

stack traceback:

/usr/lib/prosody/core/modulemanager.lua:29: in function </usr/lib/prosody/core/modulemanager.lua:29>

[C]: in function 'assert'

...s/mod_auth_dovecot/auth_dovecot/mod_auth_dovecot.lua:44: in main chunk

(tail call): ?

[C]: in function 'xpcall'

/usr/lib/prosody/core/modulemanager.lua:29: in function 'pcall'

/usr/lib/prosody/core/modulemanager.lua:171: in function 'do_load_module'

/usr/lib/prosody/core/modulemanager.lua:249: in function 'load'

/usr/lib/prosody/core/usermanager.lua:67: in function '?'

/usr/lib/prosody/util/events.lua:67: in function 'fire_event'

/usr/lib/prosody/core/hostmanager.lua:98: in function 'activate'

/usr/lib/prosody/core/hostmanager.lua:44: in function '?'

/usr/lib/prosody/util/events.lua:67: in function 'fire_event'

/usr/lib/prosody/../../bin/prosody:337: in function 'prepare_to_start'

/usr/lib/prosody/../../bin/prosody:403: in main chunk

[C]: ?

Feb 02 22:36:18 portmanager info Activated service 's2s' on [::]:5269, [*]:5269

Feb 02 22:36:18 portmanager info Activated service 'c2s' on [::]:5222, [*]:5222

Feb 02 22:36:18 portmanager info Activated service 'legacy_ssl' on no ports

Feb 02 22:36:18 mod_posix info Prosody is about to detach from the console, disabling further console output

Feb 02 22:36:18 mod_posix info Successfully daemonized to PID 13018

Feb 02 22:39:18 auth_dovecot error Dovecot connection failure: No data read from socket: closed

Feb 02 22:39:18 modulemanager error Error initializing module 'auth_dovecot' on 'meet.example.com': ...s/mod_auth_dovecot/auth_dovecot/mod_auth_dovecot.lua:44: Could not create a new SASL object

stack traceback:

/usr/lib/prosody/core/modulemanager.lua:29: in function </usr/lib/prosody/core/modulemanager.lua:29>

[C]: in function 'assert'

...s/mod_auth_dovecot/auth_dovecot/mod_auth_dovecot.lua:44: in main chunk

(tail call): ?

[C]: in function 'xpcall'

/usr/lib/prosody/core/modulemanager.lua:29: in function 'pcall'

/usr/lib/prosody/core/modulemanager.lua:171: in function 'do_load_module'

/usr/lib/prosody/core/modulemanager.lua:249: in function 'load'

/usr/lib/prosody/core/usermanager.lua:67: in function '?'

/usr/lib/prosody/util/events.lua:67: in function 'fire_event'

/usr/lib/prosody/core/hostmanager.lua:98: in function 'activate'

/usr/lib/prosody/core/hostmanager.lua:44: in function '?'

/usr/lib/prosody/util/events.lua:67: in function 'fire_event'

/usr/lib/prosody/../../bin/prosody:337: in function 'prepare_to_start'

/usr/lib/prosody/../../bin/prosody:403: in main chunk

[C]: ?

Did I forget anything?

[rainer zufall]

Okay, found that mistake myself. I was supposed to comment out the following lines:

[fauno]

rainer zufall <spack...@gmail.com> writes:
> *authentication = "dovecot"*
>
> *dovecot_auth_socket = "/run/dovecot/auth-prosody"*
>
> *auth_append_host = false*
>
> *dovecot_auth_host = "127.0.0.1"*
>
> *dovecot_auth_port = "143"*

if you're going to use the socket, the host and port options are not
needed. otherwise remove the socket option and add an inet_listener on
dovecot.

--
http://utopia.partidopirata.com.ar/

[rainer zufall]

Hi,

now i got a new problem when I login using Pidgin. As the mod_auth_dovecot module needs the email address of the user as a username, Pidgin doesn't accept usernames with an '@' in the username it always puts the part right behind the '@' into the domain field. I can login with "rai...@example.com" using Jitsi but I can't with Pidgin. Here is what I get with Pidgin:

Feb 05 22:55:51 socket debug server.lua: accepted new client connection from 81.2.34.167:55759 to 5222

Feb 05 22:55:51 c2s136c110 info Client connected

Feb 05 22:55:51 c2s136c110 debug Client sent opening <stream:stream> to example.com

Feb 05 22:55:51 c2s136c110 debug Sent reply <stream:stream> to client

Feb 05 22:55:51 c2s136c110 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>

Feb 05 22:55:51 socket debug server.lua: we need to do tls, but delaying until send buffer empty

Feb 05 22:55:51 c2s136c110 debug TLS negotiation started for c2s_unauthed...

Feb 05 22:55:51 socket debug server.lua: attempting to start tls on tcp{client}: 0x1781cc8

Feb 05 22:55:52 socket debug server.lua: ssl handshake done

Feb 05 22:55:52 c2s136c110 debug Client sent opening <stream:stream> to example.com

Feb 05 22:55:52 c2s136c110 debug Sent reply <stream:stream> to client

Feb 05 22:55:52 c2s136c110 debug Received[c2s_unauthed]: <auth mechanism='LOGIN' http://www.google.com/talk/protocol/auth#client-uses-full-bind-result='true' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

Feb 05 22:55:52 example.com:auth_dovecot debug sending "AUTH 35 LOGIN service=xmpp resp=="

Feb 05 22:55:52 example.com:auth_dovecot debug received "CONT 35 VXNlcm5hbWU6"

Feb 05 22:55:52 example.com:saslauth debug sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>VXNlcm5hbWU6</challenge>

Feb 05 22:55:52 c2s136c110 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

Feb 05 22:55:52 example.com:auth_dovecot debug sending "CONT 35 ZnJhbms="

Feb 05 22:55:52 example.com:auth_dovecot debug received "CONT 35 UGFzc3dvcmQ6"

Feb 05 22:55:52 example.com:saslauth debug sasl reply: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>UGFzc3dvcmQ6</challenge>

Feb 05 22:55:52 c2s136c110 debug Received[c2s_unauthed]: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

Feb 05 22:55:52 example.com:auth_dovecot debug sending "CONT 35 c1NiZXIhMDY4OA=="

Feb 05 22:55:54 example.com:auth_dovecot debug received "FAIL 35 user=rainer"

Feb 05 22:55:54 example.com:saslauth debug sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/></failure>

Feb 05 22:55:54 c2s136c110 debug Received[c2s_unauthed]: <auth mechanism='PLAIN' http://www.google.com/talk/protocol/auth#client-uses-full-bind-result='true' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

Feb 05 22:55:54 example.com:auth_dovecot debug sending "AUTH 36 PLAIN service=xmpp resp=AGZyYW5rAHNTYmVyITA2ODg="

Feb 05 22:56:00 example.com:auth_dovecot debug received "FAIL 36 user=rainer"

Feb 05 22:56:00 example.com:saslauth debug sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/></failure>

Feb 05 22:56:00 c2s136c110 debug Received </stream:stream>

Feb 05 22:56:00 c2s136c110 info c2s stream for <81.2.34.167> closed: session closed

Feb 05 22:56:00 c2s136c110 debug Destroying session for (unknown) ((unknown)@example.com)

Feb 05 22:56:00 c2s136c110 info Client disconnected: connection closed

Feb 05 22:56:00 c2s136c110 debug Destroying session for (unknown) ((unknown)@(unknown))

Feb 05 22:56:00 socket debug server.lua: closed client handler and removed socket from list

I have read that an '@' is not a legal character in the Jabber ID node (username). So you are supposed to use "rainer\40example.com" but then Pidgin always makes "rainer\\40example.com" and  the mod_auth_dovecot module cannot match that too of course.  Is there a way that the mod_auth_dovecot module checks only the username without the domain?? How did you guys do that or do you use an other XMPP Client? If I use Jitsi I get this:

Feb 05 23:06:50 socket debug server.lua: accepted new client connection from 81.2.34.167:55764 to 5222

Feb 05 23:06:50 c2s16a68a0 info Client connected

Feb 05 23:06:50 c2s16a68a0 debug Client sent opening <stream:stream> to example.com

Feb 05 23:06:50 c2s16a68a0 debug Sent reply <stream:stream> to client

Feb 05 23:06:50 c2s16a68a0 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>

Feb 05 23:06:50 socket debug server.lua: we need to do tls, but delaying until send buffer empty

Feb 05 23:06:50 c2s16a68a0 debug TLS negotiation started for c2s_unauthed...

Feb 05 23:06:50 socket debug server.lua: attempting to start tls on tcp{client}: 0x16521f8

Feb 05 23:06:51 socket debug server.lua: ssl handshake done

Feb 05 23:06:51 c2s16a68a0 debug Client sent opening <stream:stream> to example.com

Feb 05 23:06:51 c2s16a68a0 debug Sent reply <stream:stream> to client

Feb 05 23:06:52 c2s16a68a0 debug Received[c2s_unauthed]: <auth mechanism='PLAIN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

Feb 05 23:06:52 example.com:auth_dovecot debug sending "AUTH 38 PLAIN service=xmpp resp=ZnJhbmsAZnJhbmsAc1NiZXIhMDY4OA=="

Feb 05 23:06:54 example.com:auth_dovecot debug received "FAIL 38 user=rainer"

Feb 05 23:06:54 example.com:saslauth debug sasl reply: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/></failure>

Feb 05 23:06:54 c2s16a68a0 debug Received[c2s_unauthed]: <presence id='J1RIF-1' type='unavailable'>

Feb 05 23:06:54 stanzarouter debug Unhandled c2s_unauthed stanza: presence; xmlns=jabber:client

Feb 05 23:06:54 socket debug server.lua: client 81.2.34.167:55764 read error: closed

Feb 05 23:06:54 c2s16a68a0 info Client disconnected: closed

Feb 05 23:06:54 c2s16a68a0 debug Destroying session for (unknown) ((unknown)@example.com): closed

Feb 05 23:06:54 socket debug server.lua: closed client handler and removed socket from list

Feb 05 23:06:54 socket debug server.lua: accepted new client connection from 81.2.34.167:55767 to 5222

Feb 05 23:06:54 c2s172fd20 info Client connected

Feb 05 23:06:54 c2s172fd20 debug Client sent opening <stream:stream> to example.com

Feb 05 23:06:54 c2s172fd20 debug Sent reply <stream:stream> to client

Feb 05 23:06:54 c2s172fd20 debug Received[c2s_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>

Feb 05 23:06:54 socket debug server.lua: we need to do tls, but delaying until send buffer empty

Feb 05 23:06:54 c2s172fd20 debug TLS negotiation started for c2s_unauthed...

Feb 05 23:06:54 socket debug server.lua: attempting to start tls on tcp{client}: 0x171fb18

Feb 05 23:06:54 socket debug server.lua: ssl handshake done

Feb 05 23:06:54 c2s172fd20 debug Client sent opening <stream:stream> to example.com

Feb 05 23:06:54 c2s172fd20 debug Sent reply <stream:stream> to client

Feb 05 23:06:54 c2s172fd20 debug Received[c2s_unauthed]: <auth mechanism='PLAIN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

Feb 05 23:06:54 example.com:auth_dovecot debug sending "AUTH 40 PLAIN service=xmpp resp=ZnJhbmtAd29ybXNkb3JmLmRlAGZyYW5rQHdvcm1zZG9yZi5kZQBzU2JlciEwNjg4"

Feb 05 23:06:58 example.com:auth_dovecot debug received "OK 40 user=rai...@example.com"

Feb 05 23:06:58 c2s172fd20 info Authenticated as rainer\40exam...@example.com

Feb 05 23:06:58 example.com:saslauth debug sasl reply: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'></success>

Feb 05 23:06:58 c2s172fd20 debug Client sent opening <stream:stream> to example.com

Feb 05 23:06:58 c2s172fd20 debug Sent reply <stream:stream> to client

Feb 05 23:06:58 c2s172fd20 debug Received[c2s]: <iq id='J1RIF-3' type='set'>

Feb 05 23:06:58 rostermanager debug load_roster: asked for: rainer\40exam...@example.com

Feb 05 23:06:58 rostermanager debug load_roster: loading for new user: rainer\40exam...@example.com

Feb 05 23:06:58 c2s172fd20 debug Resource bound: rainer\40exam...@example.com/jitsi-1a3t4dt

But I actually don't want to use jitsi. Is there a way around this issue? Or an other method to configure?

[fauno]

rainer zufall <spack...@gmail.com> writes:

> Hi,
>
> now i got a new problem when I login using Pidgin. As the mod_auth_dovecot
> module needs the email address of the user as a username, Pidgin doesn't
> accept usernames with an '@' in the username it always puts the part right
> behind the '@' into the domain field. I can login with "rai...@example.com"
> using Jitsi but I can't with Pidgin. Here is what I get with Pidgin:

have you tried "auth_append_host = true" on prosody.cfg.lua?

--
http://vqfe4xmhxzi7w2uv.onion/

[rainer zufall]

That did the trick thank you. I must have overlooked that one. great!! now it all works fine