[horde] Horde\Socket\Client tls, ManageSieve git master - "Server does not support any auth methods" - Seems like

[Ralf Lang]

Hallo, I am debugging the following in ManageSieve from git master


$params = array(

'euser' => 'FOOO',

'user' => 'FOOO',

'password' => 'FOOO',
'host' => 'imap.FOOOOOO',

'port' => 2000, 'secure' => 'tls'
);

$d = new Horde\ManageSieve($params);

Horde\ManageSieve\Exception: This server doesn't support any authentication methods. in /srv/git/horde/ManageSieve/lib/Horde/ManageSieve.php:1080

root at XXXX:/srv/git/horde/ManageSieve/lib# nc FOO 2000

"IMPLEMENTATION" "Cyrus timsieved v2.3.11"
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy"
"STARTTLS"
OK
CAPABILITY
"IMPLEMENTATION" "Cyrus timsieved v2.3.11"
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy"
"STARTTLS"
OK

The server worked with a stable ingo / Net_SIEVE from another hosts, works with common thunderbird or commandline sieve clients
The server works with a perl-based commandline sieve client from the same host where the php managesieve fails.

I manually patched the PLAIN mechanism into _getBestAuthMethod - which resulted in an auth error for the known-good user/pass.

According to pidgeonhole, https://wiki.dovecot.org/Pigeonhole/ManageSieve/Troubleshooting
https://tools.ietf.org/html/rfc4616
PLAIN auth does 

AUTHENTICATE "PLAIN" "<base64-encoded credentials>" 

when authenticating as "yourself"

( "\0<username>\0<password")

but Horde\ManageSieve does unconditionally (euser\0\user\0pass) (format
for authenticating as somebody else)

I have manually done a pre-login chat

$s = new Horde\Socket\Client('FOOSERVER', '2000', 5, true);
print($s->gets(8192));
print($s->gets(8192));
print($s->gets(8192));
print($s->gets(8192));
$s->write("STARTTLS\n");
print "SENT STARTTLS\n";

print($s->gets(8192));
$tls = $s->startTls();
print("\n TLS: $tls \n");
print($s->gets(8192));print($s->gets(8192));print($s->gets(8192));


"IMPLEMENTATION" "Cyrus timsieved v2.3.11"
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy"
"STARTTLS"
OK
OK "Begin TLS negotiation now"

 TLS: 1 
"IMPLEMENTATION" "Cyrus timsieved v2.3.11"
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy"
OK

What puzzles me is that it works with the perl client:

<<< "IMPLEMENTATION" "Cyrus timsieved v2.3.11"\r\n
<<< "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation
imapflags notify include envelope body relational regex subaddress copy"\r\n
<<< "STARTTLS"\r\n
<<< OK
-T- will use TLS certs from directory "/usr/lib/ssl/certs"
-T- using hostname 'imap.intern.b1-systems.de', verification verify-peer
cert-required
>>> STARTTLS\r\n
<<< OK "Begin TLS negotiation now"\r\n
-T- TLS activated here [256 bits]
>>> NOOP "STARTTLS-RESYNC-CAPA"\r\n
<<< "IMPLEMENTATION" "Cyrus timsieved v2.3.11"\r\n
<<< "SASL" "PLAIN LOGIN"\r\n
<<< "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation
imapflags notify include envelope body relational regex subaddress copy"\r\n
<<< OK
<<< NO "Expected a command. Got something else."\r\n
auth: will try requested SASL mechanism PLAIN
Sieve/IMAP Password:
>>> AUTHENTICATE "PLAIN" {20+}\r\n
>>> CENSOREDSTRING\r\n
<<< OK\r\n

As you can see, after Socket\Client's STARTTLS, it still does not offer
the SASL line but it does when connecting with the perl client (with a
very similar chat)

What's the difference here?


-- 

Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537