OpaqueMail icon indicating copy to clipboard operation
OpaqueMail copied to clipboard

GetMessages method returning extra characters in the email body

Open f1patty opened this issue 8 years ago • 1 comments

Hello,

I am using Pop3Client to connect and retrieve messages. The GetMessages method is returning extra characters in the content body of the message.

For example, if the original email body content contains the following text: src=123.45.67.89

Using the GetMessages method to get the email Body content returns the following text: (please note the consecutive period character after 45) src=123.45..67.89

Is there a way to prevent the extra period character?

The RawBody message returns the also the extra period character: src=3D123.45=\r\n..67.89

Thanks

f1patty avatar Oct 18 '17 14:10 f1patty

The extra dot is from what is called "byte-stuffing". Since SMTP and POP3 use a line starting with a lone . to terminate a message, a method called "byte-stuffing" was introduced that munged all lines starting with a . by prepending another . to it.

An SMTP client needs to implement the byte-stuffing process when posting a message to an SMTP server and POP3 clients need to revert the byte-stuffing process when downloading a message from a POP3 server.

   Responses to certain commands are multi-line.  In these cases, which
   are clearly indicated below, after sending the first line of the
   response and a CRLF, any additional lines are sent, each terminated
   by a CRLF pair.  When all lines of the response have been sent, a
   final line is sent, consisting of a termination octet (decimal code
   046, ".") and a CRLF pair.  If any line of the multi-line response
   begins with the termination octet, the line is "byte-stuffed" by
   pre-pending the termination octet to that line of the response.
   Hence a multi-line response is terminated with the five octets
   "CRLF.CRLF".  When examining a multi-line response, the client checks
   to see if the line begins with the termination octet.  If so and if
   octets other than CRLF follow, the first octet of the line (the
   termination octet) is stripped away.  If so and if CRLF immediately
   follows the termination character, then the response from the POP
   server is ended and the line containing ".CRLF" is not considered
   part of the multi-line response.

jstedfast avatar Dec 04 '17 20:12 jstedfast