[asterisk-bugs] [Asterisk 0016557]: Asterisk produces malformed email files for voicemail

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16557 
====================================================================== 
Reported By:                jcovert
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16557
Category:                   Applications/app_voicemail
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.0.20 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-01-06 09:29 CST
Last Modified:              2010-01-06 14:43 CST
====================================================================== 
Summary:                    Asterisk produces malformed email files for
voicemail
Description: 
Asterisk is inserting an extra <cr> into the voicemail attachment.  This
causes some mail relays to fail to forward the SMTP message.

While the correct line termination in an SMTP message IS <cr><lf>, the
conversion from the Unix <lf> line terminator to <cr><lf> is handled by
sendmail.  When sendmail gets a file which (mostly) has just <lf>
terminators up until the attachment, it sees the <cr><lf> in the attachment
portion and converts that to <cr><cr><lf>.  This confuses some mail relays
down the road and prevents delivery.

This is a problem in all versions, and the fix is trivial:

At line 418 of the current head, there appears

#define eol "\r\n" 

this should just be "\n"

The resulting SMTP message will still have <cr><lf> once it has been
processed by the sendmail command.

"eol" is used ONLY in "ochar" which is used only in "base_encode".

====================================================================== 

---------------------------------------------------------------------- 
 (0116158) jcovert (reporter) - 2010-01-06 14:43
 https://issues.asterisk.org/view.php?id=16557#c116158 
---------------------------------------------------------------------- 
The RFC requires that what goes over the wire have <cr><lf> as line
terminators.

Any Unix MTA which accepts a Unix file as input (typically by accepting
"standard input") must change <lf> to <cr><lf> as it is streamed over the
network connection.  The insertion of the extra <cr> by routine ochar is
incorrect.  My suggested change makes the messages compliant with the RFC. 
See the use of "MUST" in capital letters below.

RFC 2821             Simple Mail Transfer Protocol            April 2001


2.3.7 Lines

   SMTP commands and, unless altered by a service extension, message
   data, are transmitted in "lines".  Lines consist of zero or more data
   characters terminated by the sequence ASCII character "CR" (hex value
   0D) followed immediately by ASCII character "LF" (hex value 0A).
   This termination sequence is denoted as <CRLF> in this document.
   Conforming implementations MUST NOT recognize or generate any other
   character or character sequence as a line terminator.  Limits MAY be
   imposed on line lengths by servers (see section 4.5.3).

   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a <CRLF>
   sequence. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-06 14:43 jcovert        Note Added: 0116158                          
======================================================================