search for: 0username

Hi List, I just updated an old sendmail installation to a modern postfix/dovecot system with mysql backend. Everything works fine but SMTP-AUTH fails with some clients. The problem is, that with PLAIN (old) clients send the base64 coded form: USERNAME\0USERNAME\0PASSWORD which, as i understand dovecot interprets as MASTERUSER\0USERNAME\PASSWORD. New clients send \0USERNAME\0PASSWORD which works fine. I don`t like to use masterusers, because then everyone would be able to log in as someone else. When i don`t have a passdb with master=yes in my dovecot.co...

On Apr 10, 2015, at 12:14 AM, Steffen Kaiser <skdovecot at smail.inf.fh-brs.de> wrote: > pass"word > > is no atom and Dovecot should reject it. No, not passwords should be rejected. > Maybe the former version did not checked the atoms 100% RFC conform. Where is the definition that passwords have to be atomic? And if it is there, it should be changed. Nothing anywhere at

...and 2003) and Outlook Express 6, authentification always fails. Turning on the Dovecot auth debug on reveals the reason: Dovecot SASL expects, in accordance with the standards, the following format of the SMTP AUTH command (using the PLAIN auth mechanism): AUTH PLAIN base64_encode("username\0username\0password") whereas the M$ clients send as the second argument only base64_encode("username\0password"), which naturally leads to authentification failure. Postfix apparently does not play any role in this game, as it simply passes the received command arguments to dovecot. Before...

I'm trying to use Dovecot SASL with postfix 2.3.3 and when trying to send mail I get the debug output below. I don't know enough about whats going on to know where the problem is but something clearly is not right. I would send the configurations for postfix and dovecot except they are clearly talking to each other so I kinda doubt its a configuration issue. The machine can afford to be

...lsof). so both postfix and dovecot have read/write access to the socket. the credentials sent are the same whether they're sent via a true pop3 client or via the command line. when sent via the command line, they're generated via perl -MMIME::Base64 -e 'print encode_base64("\0username\0password");'and i've verified they're correct via decode_base64 config stuff: # postconf -n biff = no command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix debug_peer_level = 2 enab...

...ername\0", 7, MSG_NOSIGNAL, NULL, 0) = 7 poll([{fd=5, events=POLLIN}], 1, 300000) = 1 ([{fd=5, revents=POLLIN}]) read(5, "K\0\0\0\21\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 poll([{fd=5, events=POLLIN}], 1, 300000) = 1 ([{fd=5, revents=POLLIN}]) read(5, "\1\0\0\0\0\0\0\0N{\0\0\17'\0\0username\0*\0Name Last"..., 59) = 59 open("/etc/ld.so.cache", O_RDONLY) = 6 fstat(6, {st_mode=S_IFREG|0644, st_size=23522, ...}) = 0 mmap(NULL, 23522, PROT_READ, MAP_PRIVATE, 6, 0) = 0x7f96bfe3e000 close(6) = 0 open("/lib64/libnss_files.so.2", O_R...