Egroupware 1.8 smtp + sasl -- Emailversand geht nicht

mc-hack 2012-09-25 12:10:28 UTC #1

Liebe Forumsmitglieder,

ich versuche seit geraumer Zeit, eGroupware zum Versenden von Mails über
unseren Postfix Mailserver zu bewegen. Das Empfangen (imaps) geht wunderbar.
FeLaMail bemängelt:

SMTP Fehler: Authentifizierung fehlgeschlagen.

Und richtig, im Logfile des Mailservers erscheint:

Sep 25 14:06:26 mailserver postfix/smtpd[…]: warning:
egroupwareserver[…]: SASL LOGIN authentication failed: Invalid
authentication mechanism

Ich weiß wirklich nicht, wo ich ansetzen soll. An TLS und SSL liegt es
nicht, offensichtlich verstehen sich hier smtp-client und smtp-server
grundlegend falsch. Dazu muß ich sagen, daß der Versand über den Mailserver
mit allen möglichen Emailclienten tadellos funktioniert: Roundcube Webmail,
Thunderbird, Claws, Applemail u.v.m.

Hat dazu jemand eine Idee?

Vielen Dank,

mc-hack

–
View this message in context: http://egroupware.219119.n3.nabble.com/egroupware-1-8-smtp-sasl-Emailversand-geht-nicht-tp3985930.html

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

sbegw 2012-09-26 07:34:48 UTC #2

Hallo mc-hack,

versuch mal bei dem smtp server: ssl://deinserver auf dem Port 465 bzw.
tls://deinserver auf dem richtigen Port.

Am besten in Thunderbird nachsehen, was die richtigen Einstellungen für
deine Domain sind.

Und ganz wichtig, prüfen, ob das Passwort und der Benutzername richtig
für den SMTP-Server eingetragen wurde.

Stefan Becker

–
Stylite AG

Morschheimer Strasse 15 | Tel. +49(0)6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49(0)6352 70629 30
Germany |

Email: sb@stylite.de |

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern

Liebe Forumsmitglieder,

ich versuche seit geraumer Zeit, eGroupware zum Versenden von Mails über
unseren Postfix Mailserver zu bewegen. Das Empfangen (imaps) geht wunderbar.
FeLaMail bemängelt:

SMTP Fehler: Authentifizierung fehlgeschlagen.

Und richtig, im Logfile des Mailservers erscheint:

Sep 25 14:06:26 mailserver postfix/smtpd[…]: warning:
egroupwareserver[…]: SASL LOGIN authentication failed: Invalid
authentication mechanism

Ich weiß wirklich nicht, wo ich ansetzen soll. An TLS und SSL liegt es
nicht, offensichtlich verstehen sich hier smtp-client und smtp-server
grundlegend falsch. Dazu muß ich sagen, daß der Versand über den Mailserver
mit allen möglichen Emailclienten tadellos funktioniert: Roundcube Webmail,
Thunderbird, Claws, Applemail u.v.m.

Hat dazu jemand eine Idee?

Vielen Dank,

mc-hack

–
View this message in context: http://egroupware.219119.n3.nabble.com/egroupware-1-8-smtp-sasl-Emailversand-geht-nicht-tp3985930.html
Sent from the egroupware-german mailing list archive at Nabble.com.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

mc-hack 2012-09-26 07:55:51 UTC #3

Hallo Stefan

danke für Deine Antwort.

Die Einstellungen stimmen, der Port ist korrekt – da bin ich mir sehr sicher, denn ich betreibe auch den entsprechenden Mailserver selbst. Nach der Meldung zu urteilen, ist nicht TLS oder SSL mein Problem, sondern der danach folgende Austausch der Authentifizierungsdaten (SASL).

Gibt es eventuell Probleme mit der von eGroupware verwendeten Perl Library für SASL? Ich bin da nicht so besonders bewandert und wüßte auch nicht, was ich da noch tun kann. Sie fehlte anfänglich auf jeden Fall und ich habe einiges auf dem eGroupware nachinstalliert in diesem Zusammenhang.

Grüße,

Martin

mc-hack 2012-09-26 08:05:30 UTC #4

… ich habe eben den Installationscheck von eGroupware nochmal laufen lassen:

Passed ---- Überprüfe ob PEAR::Auth_SASL installiert ist: 999.egw-pear

Detlev 2012-10-02 09:29:30 UTC #5

Hallo Miteinander,

ich möchte mich in dieses Problem einklinken:
Auch ich habe zum ersten Mal ein SMTP-Problem mit eGW 1.8 auf einem Cent-OS System. Pegasus und Webmail von Horde laufen ohne Probleme. Es geht bei mir ebenfalls um den Versand (SMTP).

Meine Einstellungen in eGW unter SMTP habe ich auf ssl://ip-adresse vorgenommen. Port auf 465 eingestellt. Authentifizierung korrekt vorgenommen.

In der sqpsmtp/current finde ich folgenden Eintrag, den eGW auslöst (Fehler 552):

@4000000050699dd91b0876ac 22765 354 go ahead
@4000000050699dd91b176acc 22765 spooling message to disk
@4000000050699dd91d9357ac 22765 bcc plugin (data_post): message copied to maillog
@4000000050699dd91d994f04 22765 logging::logterse plugin (deny): ` ip-Adresse static.ip-Adresse.clients.you$
@4000000050699dd91d9aa2dc 22765 552 Mail with no Date header not accepted here
@4000000050699dda1907ebbc 3743 cleaning up after 22765
@400000005069a07c12759024 3743 tls plugin (init): ciphers: ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
@400000005069a07c127597f4 3743 Initializing spool_dir

Danach versuche ich es mit Pegasus (gleicher Benutzer, gleiche Einstellungen):

@40000000506a092b2b710e3c 28350 354 go ahead
@40000000506a092b2c622ccc 28350 spooling message to disk
@40000000506a092b2c8d7abc 28350 bcc plugin (data_post): message copied to maillog
@40000000506a092b2cff5344 28350 virus::clamav plugin (data_post): Changing permissions on file to permit scanner access
@40000000506a092b2d75db04 28350 virus::clamav plugin (data_post): clamscan results: /var/spool/qpsmtpd/1349126433:28350:$
@40000000506a092b2d7cff24 28350 logging::logterse plugin (queue): ` ip-adresse static.ip-adresse.clients.you$
@40000000506a092b2d89a184 28360 queue::qmail_2dqueue plugin (queue): (for 28350 ) Queuing qp 28360 to /var/qmail/bin/qma$
@40000000506a092b2dc5105c 28350 250 Queued! 1349126433 qp 28360 506A097A.18400.E992C293@domain
@40000000506a092b2f664cdc 28350 dispatching QUIT
@40000000506a092b2f6654ac 28350 221 domain closing connection. Have a wonderful day.
@40000000506a092b2f6771d4 28350 click, disconnecting
@40000000506a092c237d1b1c 3743 cleaning up after 28350

Die Überprüfung der php-Dienste ergibt:
[root@domsrv01 ~]# rpm -qa | grep php
php-pear-1.4.9-8.el5
php-pear-File-1.2.2-1.el5.centos
php-pear-Net-URL-1.0.15-1.el5.centos
php-pear-Net-DIME-1.0.1-1.el5
php-pear-Auth-SASL-1.0.2-4.el5.centos
php-pear-SOAP-0.11.0-2.el5
php-mbstring-5.3.3-13.el5.sme.1
php-devel-5.3.3-13.el5.sme.1
smeserver-phpldapadmin-0.9.8.3-1
phpMyAdmin3-3.5.2.2-1.el5
php-process-5.3.3-13.el5.sme.1
php53-php-gettext-1.0.11-3.el5
smeserver-phpmyadmin-3.5.2.2-2.el5.sme
eGroupware-phpbrain-1.8.004.20120822-2.1
eGroupware-phpsysinfo-1.8.004.20120822-2.1
php-pear-DB-1.7.13-1.el5.centos
php-pear-Date-1.4.7-2.el5.centos
php-pear-HTTP-1.4.0-7.el5
php-pear-MDB2-2.4.1-2.el5.centos
php-pear-HTTP-Request-1.4.2-1.el5.centos
php-pear-Mail-Mime-1.4.0-1.el5.centos
php-pear-XML-Util-1.1.4-3.el5
php-pear-XML-Serializer-0.20.0-1.el5
php-pear-Net-SMTP-1.2.10-1.el5.centos
php-pear-Log-1.12.7-1.el5
php-pear-Services-Weather-1.4.2-1.fc6
php-cli-5.3.3-13.el5.sme.1
php-5.3.3-13.el5.sme.1
php-xml-5.3.3-13.el5.sme.1
php-gd-5.3.3-13.el5.sme.1
php-ldap-5.3.3-13.el5.sme.1
php-pear-Net-Socket-1.0.8-1.el5.centos
php-pear-Net-FTP-1.3.4-1.el5
php-pear-Cache-1.5.5-0.1.RC4.fc6.1
php-pear-XML-Parser-1.2.8-1.el5
php-pear-Mail-1.1.14-1.el5.centos
e-smith-php-2.2.0-6.el5.sme
php-common-5.3.3-13.el5.sme.1
php-pdo-5.3.3-13.el5.sme.1
php-mysql-5.3.3-13.el5.sme.1
php-imap-5.3.3-13.el5.sme.1
php53-mcrypt-5.3.3-1.el5
eGroupware-phpfreechat-1.8.004.20120822-2.1

In der Installationsprüfung von eGW gibt es ein Problem mit:
Überprüfe ob PEAR::XML_Feed_Parser installiert ist: Falsch
PEAR::XML_Feed_Parser wird benötigt von: NewsAdmin. Installation durch ausführen von: pear install XML_Feed_Parser

Dieser sollte aber nichts mit SMTP zu tun haben, oder? Ich kann auch nicht nachvollziehen, warum der XML_Feed_Parser von eGW nicht gefunden wird, denn dieser ist geladen.

Hat jemand von Euch noch eine Idee?

Vielen Dank und Grüße
Detlev

Detlev 2012-10-03 07:11:26 UTC #6

Hallo,

eine Ergänzung noch zum XML_Parser:

[root@domsrv01 ~]# whereis pear
pear: /usr/bin/pear /etc/pear.conf /usr/share/pear

Wenn’s hilft:
[root@domsrv01 etc]# vi pear.conf
#PEAR_Config 0.9R_Config 0.9
a:23:{s:9:“cache_dir”;s:19:"/var/cache/php-pear";s:15:“default_channel”;s:12:“pear.php.net”;s:16:“preferred_mirror”;s:12:“pear.php.net”;s:13:“remote_config”;s:0:"";s:13:“auto_discover”;i:0;s:13:“master_server”;s:12:“pear.php.net”;s:10:“http_proxy”;s:0:"";s:7:“php_dir”;s:15:"/usr/share/pear";s:7:“doc_dir”;s:19:"/usr/share/pear/doc";s:7:“bin_dir”;s:8:"/usr/bin";s:8:“data_dir”;s:20:"/usr/share/pear/data";s:8:“test_dir”;s:20:"/usr/share/pear/test";s:7:“php_bin”;s:12:"/usr/bin/php";s:8:“username”;s:0:"";s:8:“password”;s:0:"";s:7:“verbose”;i:1;s:15:“preferred_state”;s:6:“stable”;s:5:“umask”;i:18;s:9:“cache_ttl”;i:3600;s:8:“sig_type”;s:3:“gpg”;s:7:“sig_bin”;s:18:"/usr/local/bin/gpg";s:9:“sig_keyid”;s:0:"";s:10:“sig_keydir”;s:13:"/etc/pearkeys";}

Gruß Detlev

Sebastian_Steinhube1 2012-10-03 15:35:07 UTC #7

Hallo Miteinander,

ich möchte mich in dieses Problem einklinken:
Auch ich habe zum ersten Mal ein SMTP-Problem mit eGW 1.8 auf einem Cent-OS
System. Pegasus und Webmail von Horde laufen ohne Probleme. Es geht bei mir
ebenfalls um den Versand (SMTP).

Meine Einstellungen in eGW unter SMTP habe ich auf ssl://ip-adresse
vorgenommen. Port auf 465 eingestellt. Authentifizierung korrekt
vorgenommen.

In der sqpsmtp/current finde ich folgenden Eintrag, den eGW auslöst (Fehler
552):

@4000000050699dd91b0876ac 22765 354 go ahead
@4000000050699dd91b176acc 22765 spooling message to disk
@4000000050699dd91d9357ac 22765 bcc plugin (data_post): message copied to
maillog
@4000000050699dd91d994f04 22765 logging::logterse plugin (deny): `
ip-Adresse static.ip-Adresse.clients.you$
@4000000050699dd91d9aa2dc 22765 552 Mail with no Date header not accepted
here

Der SMTP-Server meckert darüber, dass es kein “Date”-Feld im Header der
E-Mail gibt. Könntest du das überprüfen?

Sebastian
[…]

Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Detlev 2012-10-03 21:59:09 UTC #8

Hallo Sebastian,

vielen Dank für Deine Unterstützung.

[quote=“Sebastian Steinhuber”]
Der SMTP-Server meckert darüber, dass es kein “Date”-Feld im Header der
E-Mail gibt. Könntest du das überprüfen?[/quote]

Yep, Dein Hinweis hat dafür gesort, dass zumindest jetzt auch MS Outlook fehlerfrei funktioniert.
Hatte dies dazu gefunden:

I can’t receive/send email from my application (ACT!, vTiger, MS Outlook, etc)

Most likely, this is a bug the application you’re using and not a problem with the SMESERVER. The application sends an email with ‘no Date header’. As the name suggests, this means a message without any date. Since the server doesn’t accept mail with ‘no Date header’ (because it’s required) the message is rejected.

As a workaround you can disable the check for the ‘Date header’.

Nachdem ich die Basic header ausgeschaltet habe, kann ich aus Outlook Mails nun ebenfalls versenden. Pegasus lief ohnehin schon.

Felamimail funktioniert jetzt nach vielen Ausprobieren mit der SMTP-Authentifizierung auf Port 465, ohne den Zuatz ssl://ip-Adresse. Alles andere scheiterte.

Also, noch einmal vielen Dank.

Gruß Detlev

Sebastian_Steinhube1 2012-10-05 12:00:37 UTC #9

Hallo Sebastian,

vielen Dank für Deine Unterstützung.

Sebastian Steinhuber wrote

Der SMTP-Server meckert darüber, dass es kein “Date”-Feld im Header der
E-Mail gibt. Könntest du das überprüfen?

Yep, Dein Hinweis hat dafür gesort, dass zumindest jetzt auch MS Outlook
fehlerfrei funktioniert.
Hatte dies dazu gefunden:

I can’t receive/send email from my application (ACT!, vTiger, MS Outlook,
etc)

Most likely, this is a bug the application you’re using and not a problem
with the SMESERVER. The application sends an email with ‘no Date header’. As
the name suggests, this means a message without any date. Since the server
doesn’t accept mail with ‘no Date header’ (because it’s required) the
message is rejected.

As a workaround you can disable the check for the ‘Date header’.

Nachdem ich die Basic header ausgeschaltet habe, kann ich aus Outlook Mails
nun ebenfalls versenden. Pegasus lief ohnehin schon.

Felamimail funktioniert jetzt nach vielen Ausprobieren mit der
SMTP-Authentifizierung auf Port 465, ohne den Zuatz ssl://ip-Adresse. Alles
andere scheiterte.
Ist es SMTP mit SSL?

Also, noch einmal vielen Dank.

Gruß Detlev

Danke für die Rückmeldung.
Hmm, zum Thema Date Header – technisch gesehen ist er nicht
absolut notwendig, um eine E-Mail zu versenden, richtig.
Der Ersteller der E-Mail setzt ihn bei… der Erstellung, was dabei
hilft, den Weg der Nachricht nachzuvollziehen, immerhin kann es zu
Verzögerungen nach dem Abliefern beim SMTP-Server kommen – soweit ich
es verstehe. Dass Outlook hier (scheinbar) mal wieder patzt, wundert
mich weit weniger als bei eGW. Es ist kein gravierender Bug, aber der
Date Header sollte implementiert werden – nach meiner bescheidenen
Meinung.

Sebastian

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Sebastian_Steinhube1 2012-10-05 12:21:22 UTC #10

Hallo Sebastian,

vielen Dank für Deine Unterstützung.

Sebastian Steinhuber wrote

Der SMTP-Server meckert darüber, dass es kein “Date”-Feld im Header der
E-Mail gibt. Könntest du das überprüfen?

Yep, Dein Hinweis hat dafür gesort, dass zumindest jetzt auch MS Outlook
fehlerfrei funktioniert.
Hatte dies dazu gefunden:

I can’t receive/send email from my application (ACT!, vTiger, MS Outlook,
etc)

Most likely, this is a bug the application you’re using and not a problem
with the SMESERVER. The application sends an email with ‘no Date header’. As
the name suggests, this means a message without any date. Since the server
doesn’t accept mail with ‘no Date header’ (because it’s required) the
message is rejected.

As a workaround you can disable the check for the ‘Date header’.

Nachdem ich die Basic header ausgeschaltet habe, kann ich aus Outlook Mails
nun ebenfalls versenden. Pegasus lief ohnehin schon.

Der Date Header dient auch dazu, für Antworten usw. die Bezug-Zeile
zusammensetzen zu können wie bspw.:

mc-hack 2012-10-08 14:43:23 UTC #11

Hallo Leute,

die Antworten bringen mich in meinem Problem leider nicht weiter. Mein Mailserver lehnt ja
wie gesagt die SASL Authentifizierung ab. Hat wirklich keiner eine Idee? Der Mailserver
funktioniert ansonsten tadellos.

Ich will aber auch nicht die Verschlüsselung abschalten.

Ich bin für jeden weiteren Hinweis dankbar!

Sebastian_Steinhube1 2012-10-08 15:30:55 UTC #12

Hallo Leute,

die Antworten bringen mich in meinem Problem leider nicht weiter. Mein
Mailserver lehnt ja
wie gesagt die SASL Authentifizierung ab. Hat wirklich keiner eine Idee? Der
Mailserver
funktioniert ansonsten tadellos.

Ich will aber auch nicht die Verschlüsselung abschalten.

Ich bin für jeden weiteren Hinweis dankbar!

Welche eGroupWare-Version ist es genau?
… php-pear und php-auth-sasl installiert, und welche Version?

Sebastian

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Leithoff_Klaus 2012-10-08 15:33:41 UTC #13

Hallo Sebastian,
soweit ich das sehen kann wird in der Klasse class.phpmailer.inc.php in der 1.8
immer mit der Funktion RFCDate gesetzt. Das passiert beim Send wenn
dort CreateHeader aufgerufen wird.
Ganz ohne Bedingung. Das bedeutet ausser die Date-Funktionalität
liefert kompletten Mist bzw. nichts, dürfte das bei Dir nicht auftreten.
Insofern kann das Fehlen des DateHeaders nicht wirklich aus einer
aktuellen 1.8 stammen.
Danke jedoch für Deine Untersuchung.

mit freundlichen Grüssen
Klaus

Detlev 2012-10-08 16:03:54 UTC #14

Hallo Klaus, Hallo Sebastian,

[quote=“Leithoff, Klaus”]
Hallo Sebastian,
soweit ich das sehen kann wird in der Klasse class.phpmailer.inc.php in der 1.8
immer mit der Funktion RFCDate gesetzt. Das passiert beim Send wenn
dort CreateHeader aufgerufen wird.[/quote]
Da es bei mir jetzt funktioniert, müßte man den alten Zustand noch einmal herstellen, um das Problem genauer zu analysieren.

Naja, es war das aktuelle 1.8.004

Ich muss mich bei mc-hack entschuldigen, dass ich diesen Thread für mein Problem genutzt habe. Sein Problem mit der Authentifizierung ist leider noch nicht gelöst.

Danke und Gruß
Detlev

Sebastian_Steinhube1 2012-10-08 17:33:18 UTC #15

Hallo Sebastian,
soweit ich das sehen kann wird in der Klasse class.phpmailer.inc.php in der 1.8
immer mit der Funktion RFCDate gesetzt. Das passiert beim Send wenn
dort CreateHeader aufgerufen wird.
Ganz ohne Bedingung. Das bedeutet ausser die Date-Funktionalität
liefert kompletten Mist bzw. nichts, dürfte das bei Dir nicht auftreten.
Insofern kann das Fehlen des DateHeaders nicht wirklich aus einer
aktuellen 1.8 stammen.
Danke jedoch für Deine Untersuchung.

mit freundlichen Grüssen
Klaus

Hallo Klaus,
ich hatte jetzt Gelegenheit für einen Versuch mit meinem 1.8er-System,
und ich kann sagen, dass ich das von Detlev Beschriebene nicht auf
eGW zurückführen kann, da der Header der Versuchsnachrichten das
Date-Feld enthält, sowohl in HTML- als auch in Text-Nachrichten,
scheinbar also eher ein problematisches SMTP-Relay. Danke, und sorry für
den Krach.

@Detlev
Ich habe kein Outlook zum Ausprobieren ;-). Bitte die Konfiguration des
SME-Servers überprüfen. Dazu vielleicht auch den Mailversand ohne SSL
auf Paketebene mitschneiden.
Soweit ich weiß, wird beim SMES QMail verwendet…
Wenn du nicht weiterkommst, hat es vielleicht im SMES-Forum schon
diesbezügliche Themen gegeben, die dir weiterhelfen.

Sebastian

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

mc-hack 2012-10-09 07:48:58 UTC #16

Hallo Sebastian!

Hier meine Versionen der Pakete, nach denen Du gefragt hast:

dpkg -l | grep php-

…
ii php-auth-sasl 1.0.4-1 Abstraction of various SASL mechanism responses
…
ii php-pear 5.3.3-7 PEAR - PHP Extension and Application Repository
…

Danke,

Martin

Sebastian_Steinhube1 2012-10-09 14:19:44 UTC #17

Hallo Sebastian!

Hier meine Versionen der Pakete, nach denen Du gefragt hast:

dpkg -l | grep php-

…
ii php-auth-sasl 1.0.4-1
Abstraction of various SASL mechanism responses
…
ii php-pear 5.3.3-7 PEAR

PHP Extension and Application Repository
…

Danke,

Martin

Okay, dann ist noch merkwürdig, dass andere MUAs kein Problem mit der
Authentifizierung haben, aber eGW.
Benötigen die anderen MUAs vielleicht keine, weil sie beispielsweise
über permit_mynetworks generell erlaubt sind?

Sep 25 14:06:26 mailserver postfix/smtpd[…]: warning:
egroupwareserver[…]: SASL LOGIN authentication failed: Invalid
authentication mechanism

Mal ins Blaue geschossen – der Fehler müsste immer, mit jedem MUA, bei
der Verwendung von saslauth(d) auftreten. Das hat dann nichts mit eGW
zu tun.

Sebastian

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Detlev 2012-10-09 15:22:40 UTC #18

Hallo Sebastian,

[quote=“Sebastian Steinhuber”]

Vielen Dank, dass Du Dir die Arbeit gemacht hast, um den Zustand zu prüfen. Da FMail ein Client ist, gehe ich auch davon aus, dass der Fehler eher im BackOffice zu suchen ist. Gleichwohl läßt der Hinweis aus meinem Beitrag darauf schließen, dass durch die angebotene Änderung das Problem behoben ist. Leider gab es keine weiteren Fehlerhinweise in den Logs.

Da noch kein Anderer diese Problem hatte, ich bei nunmehr 16 eGW-Installationen ebenfalls nicht, scheint es aber in der Tat an meinem Server zuliegen. Es ist das erste Mal, dass ich die Installation auf einen Server installiere, auf dem zeitgleich auch der Mailservice läuft.

Danke und Gruß
Detlev

Detlev 2012-10-09 15:49:22 UTC #19

Hallo Martin,

[quote=“mc-hack”]
Hier meine Versionen der Pakete, nach denen Du gefragt hast:

dpkg -l | grep php-

…
ii php-auth-sasl 1.0.4-1 Abstraction of various SASL mechanism responses
…
ii php-pear 5.3.3-7 PEAR - PHP Extension and Application Repository
…[/quote]

Vielleicht liege ich hier völlig falsch, aber ist es möglich, dass der “authentication mechanisms” (MECHANISMS=“pam shadow”) etwas damit zu tun hat?
Was gibt denn saslauth -v aus? Und stimmen diese Werte mit Deinen Einstellungen überein?

Gruß Detlev

mc-hack 2012-10-15 12:09:59 UTC #20

Hallo Detlev,

host:# saslauthd -v
saslauthd 2.1.23
authentication mechanisms: sasldb getpwent kerberos5 pam rimap shadow ldap

Einstellungen bei eGroupware Emailversand:

ssl://… funktioniert garnicht.
tls://… auf Port 25 führt zu dem beschriebenenen Problem

Im letzteren Fall vermeldet der Mailserver (nach dieser Anleitung aufgesetzt: http://kefk.org/free_software/postfix#Postfix_Admin), daß der Client, also der MUA von eGroupware, den falschen Authentifizierungsmechanismus nutzen will (ich gehe inzwischen davon aus: gar keinen).

Ich weiß nicht mehr weiter, inzwischen habe ich die dazugehörige Maschine geklont und eine separate Instanz des Servers zum Weitertesten aufgesetzt. Wir sind jetzt seit fast einem halben Jahr nicht in der Lage, Emails zu versenden aus eGW. Ansonsten rennen unsere dazugehörigen Mailserver wie die Bienchen mit wirklich allen möglichen Arten von MUAs.

Viele Grüße und auf Hilfe hoffend,

Martin