SMTPTLS - No SASL mechanism found

[dolfiz]

Hi all,

we've setup an otrs that is expected to send mail through SMTP-TLS using a MS exchange server (that is not our, we don't control it, unfortunately; I don't know yet which version it is).

I've setup IMAPTLS account in order to fetch all mails on the same server and it is working good. Outbound mail with SMTP-TLS on the contrary do not work, and log says:

Code: Select all

[Mon Feb 24 03:12:27 2014] [error] No SASL mechanism found\n at /opt/otrs/Kernel/cpan-lib/Authen/SASL.pm line 77\n at /usr/share/perl/5.14/Net/SMTP.pm line 143\n

The error shows up everytime an agent tries to reply via email.

Here's my otrs config:

Code: Select all

SendmailModule=SMTPLS
SendmailModule::CMD=/usr/sbin/sendmail -i -f
SendmailModule::Host=195.x.x.x
SendmailModule::Port=25
SendmailModule::AuthUser=domain\username
SendmailModule::AuthPassword=xxxxxx

I specified username with the domain and a "\" as I did for the IMAP configuration. I think that the config should be right. I know that SMTPTLS uses also the 587 port, but in this case the admin server explicity says to use 25. Indeed a telnet on port 25 works, on the contrary on port 587 it does not. By he way, the system is not missing any module: otrs.CheckModules.pm returns OK for everything except for third part db modules.

I googled and searched on forum but I'm not able to find a common problem and a common solution. It seems to be a problem concerning SMTP with TLS and MS Exchange server but I don't understand completely what the error means and what possible exchange configuration I'm expecting to suggest to the server admin (we don't control it but our client does, maybe we can change some exchange configuration in order to help solving the problem).

The error is really not verbose and I really don't know where to start in order to solve it I tried to enable more verbose logs modifying

Code: Select all

[Kernel/System/Email/SMTP.pm]> $Self->{SMTPDebug} = 0; # shown on STDERR [...]

but the log is still the same :/

Any idea?
Thanks,
Luca

[dolfiz]

I'm searching and finding just small breadcrumbs...

Found some topics that suggest to change authentication mode on the exchange server to "PLAIN SASL Authentication". Could someone be more specific? The configuration, from otrs, will be still the same? Still SMTPTLS? This change on exchange can be made without impacts? I know, the latter is OT, this is not a MS Exchange forum. Still the problem concerns it, due to the fact that otrs does not support default SASL mechanism of MS Exchange (am I right?), so I hope that someone knows a solution for this

[crythias]

Try this: http://sourceforge.net/p/webadmin/discu ... d/065b463c

[dolfiz]

Thank you crythias.

Unfortunately I tried it and it does not work, the error actually changes in:

Code: Select all

ERROR: OTRS-CGI-88 Perl: 5.14.2 OS: linux Time: Mon Feb 24 15:05:49 2014

 Message: SMTP authentication failed: 5045.7.4 Unrecognized authentication type

I think that the authentication mechanism currently used on this exchange server is not supported by otrs (or by the perl modules it uses). We can't relax the authentication encryption, so we can't use "plaintext SASL authentication" as suggested somewhere else.

The only solution we can think of is to create a windows server as mail relay on local network. Let otrs auth with it in plain text mode (locally should be secure) and then let this relay server communicate properly with the remote exchange server, with SMTPTLS using the preferred auth mechanism that exchange wants.

[crythias]

https://www.google.com/search?q=SMTP+au ... ation+type
viewtopic.php?f=62&t=11252
https://www.google.com/search?q=perl+smtptls+otrs

[dolfiz]

https://www.google.com/search?q=SMTP+au ... ation+type
viewtopic.php?f=62&t=11252
https://www.google.com/search?q=perl+smtptls+otrs

I appreciate your help but I've already tried same searches and several others similar (every permutation/combination of words smtp smtptls perl otrs exchange sasl etc...). I'm not able to find (recent) topics that help me. Actually my ignorance of perl or mail protocols do not help me too

[dolfiz]

We made a step forward...

We are able now to send an email through this perl script (outside from otrs):

Code: Select all

#!/usr/bin/perl -w

use Net::SMTP_auth;

$smtp = Net::SMTP_auth->new('x.y.w.z');
$smtp->auth('NTLM', 'user', 'pwd');

$smtp->mail('mail@mydomain.com');
$smtp->to("mail\@remote_domain.com");

$smtp->data();
$smtp->datasend("To: mail\@remote_domain.com\n");
$smtp->datasend("\n");
$smtp->datasend("A simple test message\n");
$smtp->dataend();

$smtp->quit;

The MS Exchange server does accept the connection and actually send the email.

Now the problem is to make OTRS able to execute the script using proper recipient, sender, subject, body, etc...

The esy&ugly try could be:
- we change the sendmail call on SysConfig in order to call our script in place of sendmail
- we edit the script in order to parse parameters properly (do you know the exact format of an otrs call to sendmail?)

This solution is not really clean but should work. Anyway, as I said, it's not so nice. Do you have suggestions for us (we are perl unskilled, as you could guess) in order to improve this solution?

[vagnerinf]

I'm very interested in solving this article. I'm going through the same problem. If you have got a solution, please reply.

How can I configure OTRS to send it in Procolo PLAIN by default?

[dolfiz]

I'm very interested in solving this article. I'm going through the same problem. If you have got a solution, please reply.

How can I configure OTRS to send it in Procolo PLAIN by default?

I'm sorry vagnerinf but that was the point where we stucked and we were not able to solve it completely. At the end, they give us the chance to use a different SMTP server and we catched the opportunity and switched to another in order to let the issue to vanish.

Anyway the point is not how to configure OTRS to use plain authentication, but actually how to configure in that way exchange! As far as I know OTRS already use plain mode for auth and that was the problem for us (on exchange server side the auth was configured as encrypted).

I hope you'll find a complete solution if this kind of auth is mandatory

Bye,
Luca