You are here: Foswiki>Tasks Web>Item13699 (03 Feb 2016, GeorgeClark)Edit Attach

Item13699: Mail sending fails when non-latin text in utf8 is being sent.

pencil
Priority: Normal
Current State: Closed
Released In: 2.1.0
Target Release: minor
Applies To: Engine
Component: FoswikiNet
Branches: Item13699 master
Reported By: VadimBelman
Waiting For:
Last Change By: GeorgeClark
Symptoms:

  1. Non-latin alphabet language is used for interface.
  2. An email is being sent by the engine.
  3. Depending on which SMTP encryption option is used either timeout occurs without any verbose feedback (SSL/TLS/STARTTLS); or the following message could be found in the error log (plain SMTP):

MAIL  -- Wide character in syswrite at /usr/local/lib/perl5/site_perl/Net/Cmd.pm

A suggested fix is to use Encode::encode_utf8 before submitting message text.

-- VadimBelman - 13 Sep 2015

I can't seem to get this to fail. I've registered users with interface language set to several different languages ensuring utf-8 text in the body of the confirmation message. And used utf-8 names for the wikiname. It's working with or without the encode_utf8 call. Tried with both my local SMPT server, as well as gmail.com. I'm reluctant to apply this one without a test case. Any hints on how to trigger the failure?

-- GeorgeClark - 27 Oct 2015

The problem is nothing about mail servers but about Net::Cmd improperly dealing with utf8 flag.

Somehow the problem was reproducible from the configure script when tested sending emails but not anymore. Now test emails are being sent using English text causing no trouble.

For now the way to see the problem is to try to reset password. The web server timeouts. In the apache logs I find the following:

Script timed out before returning headers: resetpasswd AH01220: Timeout waiting for output from CGI script /usr/local/www/foswiki/bin/resetpasswd

Yet there is nothing in the Foswiki error.log.

I'm now using Foswiki v2.0.2, perl v5.20.2, Net::Cmd v2.30 bundled with the perl.

In my opinion the patch attached is a quick a dirty fix. In either case it'd be much safer to encode the message using base64 and wrap it into corresponding MIME envelope.

-- VadimBelman - 27 Oct 2015
 
Topic revision: r17 - 03 Feb 2016, GeorgeClark - This page was cached on 18 Nov 2017 - 16:58.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License