Email Errors - but emails send ok

[Ambo]

Guys,

Initially we had some issues with relaying etc through our Exchange 2010 server, however now that is resolved with a new connector and authentication details entered into OTRS.

However, that being said - we get random issues still with the below being dumped into the logs - however the customer receives the email fine.

Code: Select all

[Error][Kernel::System::Email::SMTP::Send][163] Can't send message: 354Start mail input; end with <CRLF>.<CRLF>
! Enable Net::SMTP debug for more info!
[Info][Kernel::System::Email::Send] Error sending message
[Error][Kernel::System::Ticket::Article::ArticleSend][2180] Impossible to send message to <snipped out>

I'm not sure what the "Enable Net::SMTP debug" is talking about as i cannot seem to find that option in the OTRS settings. Checking log files on the Exchange server reinforce the fact the email was sent all OK to the Customer.

Can anyone shed any light as to what could be causing this issue ?

[ferrosti]

It seems like these kind of mails are not formatted correctly, as '<CRLF>.<CRLF>' implies.
Does this happen on automated replies only or on agents responses, too?

[Ambo]

It occurs on both and doesn't seem to occur to all clients. It seems random - but is happening very consistently.

I have modified the auto responses - maybe they need a . At then end of them or something.

Doesn't occur with internal emails (ie within exchange domain) only external.

Any help appreciated.

[ferrosti]

It also could be a problem of the CPAN module.
Can you please post the output of $OTRS_HOME\bin\otrs.CheckModules.pl

[Ambo]

Gladly

Code: Select all

D:\Program Files (x86)\OTRS\OTRS\bin>perl otrs.CheckModules.pl
   o CGI..............................ok (v3.59)
   o Crypt::PasswdMD5.................ok (v1.3)
   o CSS::Minifier....................ok (v0.01)
   o Date::Format.....................ok (v2.24)
   o Date::Pcalc......................ok (v1.2)
   o DBI..............................ok (v1.616)
   o DBD::mysql.......................ok (v4.018)
   o DBD::ODBC........................ok (v1.31)
   o DBD::Oracle......................Not installed! (Optional - Required to connect to a Oracle database.
   o DBD::Pg..........................ok (v2.17.2)
   o Digest::MD5......................ok (v2.51)
   o Digest::SHA::PurePerl............ok (v5.70)
   o Encode::HanExtra.................ok (v0.23)
   o Encode::Locale...................ok (v1.02)
   o GD...............................ok (v2.46)
      o GD::Text......................ok (v0.86)
      o GD::Graph.....................ok (v1.44)
      o GD::Graph::lines..............ok (v1.15)
      o GD::Text::Align...............ok (v1.18)
   o IO::Scalar.......................ok (v2.110)
   o IO::Wrap.........................ok (v2.110)
   o JavaScript::Minifier.............ok (v1.05)
   o JSON.............................ok (v2.53)
      o JSON::PP......................ok (v2.27200)
      o JSON::XS......................ok (v2.32)
   o Locale::Codes....................ok (v3.18)
   o LWP::UserAgent...................ok (v6.03)
   o Mail::Internet...................ok (v2.08)
   o Mail::POP3Client.................ok (v2.18 )
      o IO::Socket::SSL...............ok (v1.49)
   o Mail::IMAPClient.................ok (v3.30)
      o IO::Socket::SSL...............ok (v1.49)
   o MIME::Base64.....................ok (v3.13)
   o MIME::Tools......................ok (v5.428)
   o ModPerl::Util....................ok (v2.000004)
      o Apache::DBI...................ok (v1.11)
      o Apache2::Reload...............ok (v0.11)
   o Net::DNS.........................ok (v0.67)
   o Net::POP3........................ok (v2.29)
   o Net::IMAP::Simple................ok (v1.20271)
      o Net::IMAP::Simple::SSL........ok (v1.3)
   o Net::SMTP........................ok (v2.31)
      o Authen::SASL..................ok (v2.15)
      o Net::SMTP::SSL................ok (v1.01)
      o Net::SMTP::TLS::ButMaintained.ok (v0.18)
   o Net::LDAP........................ok (v0.43)
   o PDF::API2........................ok (v2.019)
      o Compress::Zlib................ok (v2.042)
   o SOAP::Lite.......................ok (v0.714)
      o version.......................ok (v0.88)
      o Class::Inspector..............ok (v1.25)
   o Text::CSV........................ok (v1.21)
      o Text::CSV_PP..................ok (v1.29)
      o Text::CSV_XS..................ok (v0.85)
   o XML::Parser......................ok (v2.40)
   o HTTP::Message....................ok (v6.02)
      o HTTP::Headers.................ok (v6.00)
   o URI..............................ok (v1.59)
      o URI::Escape...................ok (v3.31)
   o Scalar::Util.....................ok (v1.23)
   o Win32::Daemon....................ok (v20110117)
   o Win32::Service...................ok (v0.06)

D:\Program Files (x86)\OTRS\OTRS\bin>

[ferrosti]

Seems good to me. You should possibly go for a bugreport.
Please update your signature with your version and OS, etc.

[Ambo]

Hrmmm - very weird.

It's a fresh Windows Server 2008 R2 install with just the base OTRS 3.1.2 install.

Sig updated.

Thought it might be worth noting - both the Exchange-2010 server and the Helpdesk server run on the same ESXi Host - run on the same VLAN - no networking issues.

This is definitely a weird one - but we need to get to the bottom of it so that we can deploy OTRS into full production mode, currently have it restricted to a single customer due to this issue.

No one else having issues with external emails giving back this error with Exchange (2003, 2007, 2010) ?

[crythias]

viewtopic.php?t=10876&p=50383#p44243

[Ambo]

viewtopic.ph ... 383#p44243

This post seems to be more related to a relay error - not purely the <CRLF error.

Checked everywhere possible (i think) that you can set an email address and all appears to be ok.

Most posts on here that reference the <CRLF>.<CRLF> error are getting a 550 error - ie cannot relay - so mail server config issue.

The only post that seems to have identical issues that we are seeing is viewtopic.php?f=53&t=13414&p=52080 which seems to point to OTRS not handling the 345 code correctly given from Exchange, rather reporting an error in sending the email when in actual fact the email is sent fine.

Code: Select all

** domain changed to domain.com for posting **

From the Admin page - Email Settings -> Email Addresses -> System Email Addresses Management = helpdesk@domain.com and the test customers queue selected.

SysConfig Checks/Changes:

Framework -> Core - Sysconfig -> NotificationSenderEmail = helpdesk@domain.com
Framework -> Core::Sendmail -> SendmailNotificationEnvelopeFrom = Wasn't enabled - enabled and set to helpdesk@domain.com
Ticket -> Core::PostMaster::PreFilterModule::NewTicketReject::Sender = Wasn't enabled - enabled and set to helpdesk@domain.com

[Ambo]

Some more testing - setup another customer using my GMAIL address - added this customer to all the same groups etc.

Send emails all OK - OTRS reports OK, doesn't come back with error.

Test to actual customer and OTRS reports <CRLF> error - cannot send email - yet it's sent to them fine when checking exchange logs and confirming with them they received it.

Really weird !

[crythias]

Test to actual customer and OTRS reports <CRLF> error - cannot send email - yet it's sent to them fine when checking exchange logs and confirming with them they received it.

There may be a possibility of an additional recipient (agent?) that isn't receiving.

[Ambo]

Nope - only have 2 agents configured - they are both internal recipients for exchange.

Replying just to a customer - no additional's.

Spoke to the OP of viewtopic.php?f=53&t=13414&p=52080 who is having the same issue and working through it with commercial support.

Hopefully it can be resolved soon.

[Vadim]

Hi All,
had exactly the same issue (354 can't send message). I used Exchange 2010 relay.
The problem cause is Exchange 2010 (Transport service) shadow redundancy. The fix is very simple:
In Exchange Shell
Set-ReceiveConnector "YourReceiveConnectorNameForOTRS" -MaxAcknowledgementDelay 0

that's all.