Per SMTP specs, a CRLF + PERIOD + CRLF is
the "End of Message" signal (why, oh why did someone
think THAT was a good idea?!?).
Haven't tested with latest (1.11), but prior version does
not protect against a lone period in a message
prematurely terminating the message. For example,
send a message containing the following text will result
in only half the message:
=======================
Hello, World!
.
(You will not get this text. Message terminated at prior
line)
=======================
Also, it probably depends on the STMP server recieving
the message, but we had problems if a QP-encoded line
in the message STARTED with a period. In this case,
the period would be OMITTED from the message. (Took
a loooong while to track that down).
Solution to both problems was to simply Hex encode all
periods in the message body. Don't know if that will
impact attachments or MIME-boundaries, but hey, it
works for us.
HERE'S THE FIX: in MailEncoder.cs:ConvertToQP( )
Find the line that looks like this:
else if(ch > 126 || (ch < 32 && ch != '\t') || ch == '=')
Add || ch == '.' to the condition. Save. Compile.
Deploy.
Logged In: YES
user_id=1068867
Update. This fix *does* affect attachments (file names come
across QP encoded). Sorry.
This has also been reported many, many times as various
open and closed bugs. Use fix from one of the other threads
(look for "RFC 821 4.5.2 Transparancy").