Closed Bug 618867 Opened 14 years ago Closed 13 years ago

CSS style changes from .email to ..email when sending html email from thunderbird.

Categories

(Thunderbird :: Message Reader UI, defect)

x86
Windows 7
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bernardo, Unassigned)

Details

(Whiteboard: closeme 2011-11-09)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.215 Safari/534.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-BR; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

----------------------------------------------------------------------------------
Send
----------------------------------------------------------------------------------

<style type="text/css">
.email *{font-family:Arial, Helvetica, sans-serif; font-size:11px;color:#000;padding:0;margin:0}
</style>
<div class="email">
conteudo do email
</div>


----------------------------------------------------------------------------------
received in thunderbird
----------------------------------------------------------------------------------

From - Mon Dec 13 17:49:21 2010
X-Account-Key: account2
X-UIDL: 1199463241-211752
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Return-Path: <suporte@e-login.net>
Delivered-To: bernardo@datamex.com.br
Received: from mx3.vetorial.net (mx3.vetorialnet.com.br [187.86.130.18])
	by pop03.vetorial.net (Postfix) with ESMTP id E98DB40E7A8
	for <bernardo@datamex.com.br>; Mon, 13 Dec 2010 17:49:17 -0200 (BRST)
Received: from mx3.vetorial.net (localhost [127.0.0.1])
	by mx3.vetorial.net (Postfix) with SMTP id 7C99FBFE81F
	for <bernardo@datamex.com.br>; Mon, 13 Dec 2010 17:49:18 -0200 (BRST)
Received: from mx3.vetorial.net (localhost [127.0.0.1])
	by mx3.vetorial.net (Postfix) with ESMTP id 6C0BCBFE846;
	Mon, 13 Dec 2010 17:49:17 -0200 (BRST)
Received-SPF: none (mx3.vetorial.net: 187.86.130.252 is neither permitted nor denied by domain of e-login.net) client-ip=187.86.130.252; envelope-from=suporte@e-login.net; helo=app01.datamex.com.br;
Received-SPF: none (mx3.vetorial.net: 187.86.130.252 is neither permitted nor denied by domain of e-login.net) client-ip=187.86.130.252; envelope-from=suporte@e-login.net; helo=app01.datamex.com.br;
Received: from app01.datamex.com.br (app01.datamex.com.br [187.86.130.252])
	by mx3.vetorial.net (Postfix) with ESMTP id 68713BFE82B;
	Mon, 13 Dec 2010 17:49:17 -0200 (BRST)
Received: from suporte.e-login.net (localhost [127.0.0.1])
	by app01.datamex.com.br (Postfix) with ESMTP id 0C48745004;
	Mon, 13 Dec 2010 17:49:16 -0200 (BRST)
Date: Mon, 13 Dec 2010 17:49:16 -0200
To: alex@datamex.com.br, bernardo@datamex.com.br
From: suporte@e-login.net
Subject: Tarefa atualizada: Substituir o servidor .250
Message-ID: <a47704af4d4fa0f4e4600ee065807d86@suporte.e-login.net>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="iso-8859-1"
X-Virus-Scanned: ClamAV using ClamSMTP
X-DSPAM-Result: Whitelisted
X-DSPAM-Processed: Mon Dec 13 17:49:18 2010
X-DSPAM-Confidence: 0.5322
X-DSPAM-Improbability: 1 in 115 chance of being spam
X-DSPAM-Probability: 1.0000
X-DSPAM-Signature: 64588,4d0678be853261087418724

<style type="text/css">
..email *{font-family:Arial, Helvetica, sans-serif; font-size:11px;color:#000;padding:0;margin:0}
</style>
<div class="email">
conteudo do email
</div>

****************************************************************
****************************************************************
see in tag style ".." before class name
****************************************************************
****************************************************************

----------------------------------------------------------------------------------
id change .email to #email e resend
----------------------------------------------------------------------------------

<style type="text/css">
#email *{font-family:Arial, Helvetica, sans-serif; font-size:11px;color:#000;padding:0;margin:0}
</style>
<div class="email">
conteudo do email
</div>

----------------------------------------------------------------------------------
received in thunderbird
----------------------------------------------------------------------------------

From - Mon Dec 13 17:55:42 2010
X-Account-Key: account2
X-UIDL: 1199463241-211759
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Return-Path: <suporte@e-login.net>
Delivered-To: bernardo@datamex.com.br
Received: from mx2.vetorial.net (mx2.vetorialnet.com.br [187.86.130.17])
	by pop03.vetorial.net (Postfix) with ESMTP id 5CC6240E797
	for <bernardo@datamex.com.br>; Mon, 13 Dec 2010 17:55:20 -0200 (BRST)
Received: from mx2.vetorial.net (localhost [127.0.0.1])
	by mx2.vetorial.net (Postfix) with SMTP id E8D5F34D43B
	for <bernardo@datamex.com.br>; Mon, 13 Dec 2010 17:55:20 -0200 (BRST)
Received: from mx2.vetorial.net (localhost [127.0.0.1])
	by mx2.vetorial.net (Postfix) with ESMTP id DD58134D43D;
	Mon, 13 Dec 2010 17:55:19 -0200 (BRST)
Received-SPF: none (mx2.vetorial.net: 187.86.130.252 is neither permitted nor denied by domain of e-login.net) client-ip=187.86.130.252; envelope-from=suporte@e-login.net; helo=app01.datamex.com.br;
Received-SPF: none (mx2.vetorial.net: 187.86.130.252 is neither permitted nor denied by domain of e-login.net) client-ip=187.86.130.252; envelope-from=suporte@e-login.net; helo=app01.datamex.com.br;
Received: from app01.datamex.com.br (app01.datamex.com.br [187.86.130.252])
	by mx2.vetorial.net (Postfix) with ESMTP id C180A34D43C;
	Mon, 13 Dec 2010 17:55:19 -0200 (BRST)
Received: from suporte.e-login.net (localhost [127.0.0.1])
	by app01.datamex.com.br (Postfix) with ESMTP id 72F7245004;
	Mon, 13 Dec 2010 17:55:18 -0200 (BRST)
Date: Mon, 13 Dec 2010 17:55:18 -0200
To: alex@datamex.com.br, bernardo@datamex.com.br
From: suporte@e-login.net
Subject: Tarefa atualizada: Substituir o servidor .250
Message-ID: <72f331f108dc457b87bf0b35594088c1@suporte.e-login.net>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="iso-8859-1"
X-Virus-Scanned: ClamAV using ClamSMTP
X-DSPAM-Result: Whitelisted
X-DSPAM-Processed: Mon Dec 13 17:55:20 2010
X-DSPAM-Confidence: 0.5238
X-DSPAM-Improbability: 1 in 111 chance of being spam
X-DSPAM-Probability: 1.0000
X-DSPAM-Signature: 64588,4d067a28896171395711939

<style type="text/css">
#email *{font-family:Arial, Helvetica, sans-serif; font-size:11px;color:#000;padding:0;margin:0}
</style>
<div id="email">
conteudo email
</div>


Reproducible: Always

Steps to Reproduce:
phpmailer class to send mail by using the format specified in the description.
I think with almost 100% sure that the phpmailer has nothing to do with it
Just to rule things out - could you log the smtp traffic between your PHPmailer and the smtp server that you are using ? (and see that indeed . is sent not ..).

so the .. is present in the local copy  on your desktop, can you check that it's also not present on the server before Thunderbird downloads the email ?
Summary: problems with css → CSS style changes from .email to ..email when sending html email from thunderbird.
> <style type="text/css">
> .email *{font-family:Arial, Helvetica, sans-serif;

As line starts with ".", mailer like Tb as SMTP client sends it as "..email *{..." according to RFC for SMTP.
> http://tools.ietf.org/html/rfc5321#section-4.5.2
> 4.5.2. Transparency
>    Without some provision for data transparency, the character sequence
>    "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
>    In general, users are not aware of such "forbidden" sequences.  To
>    allow all user composed text to be transmitted transparently, the
>    following procedures are used:
>    o  Before sending a line of mail text, the SMTP client checks the
>       first character of the line.  If it is a period, one additional
>       period is inserted at the beginning of the line.
>    o  When a line of mail text is received by the SMTP server, it checks
>       the line.  If the line is composed of a single period, it is
>       treated as the end of mail indicator.  If the first character is a
>       period and there are other characters on the line, the first
>       character is deleted.

As this added "." is not seen in mail source generated by "Send Later" of Tb, it's added upon mail sending to SMTP server if sent by Tb, instead of upon mail data stream generation. 

If the added "." before first character of "." of a line is not removed, it's SMTP server's fault.
If a mailer added two "..", it's mailer's fault(PHPmailer in your case).

Arrived mail.
> Received: from suporte.e-login.net (localhost [127.0.0.1])
>    by app01.datamex.com.br (Postfix) with ESMTP id 72F7245004;
>    Mon, 13 Dec 2010 17:55:18 -0200 (BRST)
> To: alex@datamex.com.br, bernardo@datamex.com.br
> From: suporte@e-login.net
Sender's ISP looks e-login.net, and used SMTP looks SMTP servers managed by datamex.com.br only.

Bernardo Silva(bug opener): 
Can you reproduce problem by sending a simple text mail of ".email" at first of a line to yourself using Tb, using SMTP server managed by datamex.com.br?
Can you rereproduce problem with SMTP server managed by other provider than datamex.com.br?
If you don't have other account, you can use SMTP of Gmail and/or Yahoo! Mail by getting free account of Gmail and/or Yahoo! Mail.
datamex.com was technology company....
Does your SMTP server support and use port=587(message submission port)?
If yes, it may be issue around "who should add . and who shouldn't add ." in  MUA -> (port=587)MSA -> (port=25)MTA configuration.

Message submission port etc. is defined by rfc4409.  
> http://tools.ietf.org/html/rfc4409
But who is SMTP server of rfc5321 and who is SMTP client of rfc5321 is slightly ambiguous, if configuration of MUA->MSA->MTA.
While port=25 is used, mailer can be considered as (MUA+MSA)==mailer -> (port=25)MTA==SMTP server, so no problem arises, even after rfc4409 is added after SMTP is defined.
However, when MSA becomes relevant, configuration becomes MUA==mailer -> (port=587)MUA==SMTP server for mail client -> (port=25)MTA==provider's SMTP servers.
In rfc4409, MSA is stated as an "SMTP client". If so, MSA component at SMTP server should add "." according to rfc5321. In this case, mailer as MUA shouldn't add ".".

Bernardo Silva(bug opener), is such complicated issue involved in your case?
This email is sent to more than one user and the problem occurs only with using the thunderbird in this case on two computers.
In other email clients like Gmail, Windows Live Mail, Horde and RoundCube the problem does not occur.

I think the problem is not in the smtp.

And really if I change
<style>
.email{
}
</style>
by
<style>.email{}</style>

the error does not occur.

something else.
"<CRLF>.<CRLF>" is different from "<style><CRLF>.email{"

e-mail is being sent over port 25 on a server postfix-2.6.3,1 in freebsd
(In reply to comment #5)

As for your "..email" problem, Thunderbird is absolutely irrelevant, if transfer to Gmail was not done by Tb or add-on of Tb. Thunderbird merely received "..email" from your POP3 server of vetorial.net.
i.e. Your bug summary is wrong, because Tb is never sender of the mail.

(A) in tb    http://www.bernardosilva.com.br/bug/email-simples-tb.txt

(Headers)
> Delivered-To: bernardo@datamex.com.br
> Received: from mx3.vetorial.net (mx3.vetorialnet.com.br [187.86.130.18])
> 	by pop03.vetorial.net (Postfix) with ESMTP id D6CD740E7A5
> 	for <bernardo@datamex.com.br>; Tue, 21 Dec 2010 10:52:50 -0200 (BRST)
> Received: from mx3.vetorial.net (localhost [127.0.0.1])
> 	by mx3.vetorial.net (Postfix) with SMTP id 1A100BFE856
> 	for <bernardo@datamex.com.br>; Tue, 21 Dec 2010 10:52:51 -0200 (BRST)

(Same Received: as mail Gmail received)
> Received: from mx3.vetorial.net (localhost [127.0.0.1])
> 	by mx3.vetorial.net (Postfix) with ESMTP id A7073BFE845;
> 	Tue, 21 Dec 2010 10:52:50 -0200 (BRST)

(First=bottom Received:, same as mail Gmail received)
> Received: from dev.datamex.com.br (localhost [127.0.0.1])
> 	by dev.datamex.com.br (8.14.2/8.14.2) with ESMTP id oBLCqnt5017482
> 	for <bernardo@datamex.com.br>; Tue, 21 Dec 2010 10:52:49 -0200 (BRST)
> 	(envelope-from suporte@e-login.net)

(Same Message-ID: as mail Gmail received)
> Message-ID: <863a00c09b663b1b6602a8d8119c5c92@dev.datamex.com.br>

(B) in gmail http://www.bernardosilva.com.br/bug/email-simples-gmail.txt

(Headers)
> Delivered-To: diou.bernardo@gmail.com
> Received: by 10.223.123.206 with SMTP id q14cs12888far;
>         Tue, 21 Dec 2010 04:52:52 -0800 (PST)
> Received: by 10.236.103.145 with SMTP id f17mr10179880yhg.12.1292935971566;
>         Tue, 21 Dec 2010 04:52:51 -0800 (PST)
> Received: from vetnet23.vetorialnet.com.br (smtp02.vetorialnet.com.br [187.86.130.25])
>         by mx.google.com with ESMTP id h23si10575363yha.160.2010.12.21.04.52.50;
>         Tue, 21 Dec 2010 04:52:51 -0800 (PST)
> Received: from mx3.vetorial.net (mx3.vetorialnet.com.br [187.86.130.18])
> 	by vetnet23.vetorialnet.com.br (Postfix) with ESMTP id 7845C6EB773
> 	for <diou.bernardo@gmail.com>; Tue, 21 Dec 2010 10:53:01 -0200 (BRST)

(Same Received: as mail Tb received)
> Received: from mx3.vetorial.net (localhost [127.0.0.1])
> 	by mx3.vetorial.net (Postfix) with ESMTP id A7073BFE845;
> 	Tue, 21 Dec 2010 10:52:50 -0200 (BRST)

(First=bottom Received:, same as mail Tb received)
> Received: from dev.datamex.com.br (localhost [127.0.0.1])
> 	by dev.datamex.com.br (8.14.2/8.14.2) with ESMTP id oBLCqnt5017482
> 	for <bernardo@datamex.com.br>; Tue, 21 Dec 2010 10:52:49 -0200 (BRST)
> 	(envelope-from suporte@e-login.net)

(Same Message-ID: as mail Tb received)
> Message-ID: <863a00c09b663b1b6602a8d8119c5c92@dev.datamex.com.br>

How did you send copy of mail to Gmail? By filter service or transfer service of vetorial.net?

If so, "transfer by server" is similar to "MUA -> MTA". So, if server of vetorial.net who transferred your mail(as MUA) doesn't add ".", and if SMTP server of vetorial.net who received mail data(as MTA) removes "." based on RFC, original "..email"(Tb received) is passed to Gmail as ".email".

Please check with clear, clean, simple mail delivery route.
Can you check with mail of "To: bernardo@datamex.com.br,  diou.bernardo@gmail.com", using PHPmailer, without transfer service?

Can you send text mail of ".email" by Tb who passes "..email" to SMTP server?
  (i)   To: bernardo@datamex.com.br using SMTP of datamex.com.br,
  (ii)  To: bernardo@datamex.com.br using SMTP of Gmail,
  (iii) To: diou.bernardo@gmail.com using SMTP of Gmail.
FYI.
Following may be relevant.
> http://www.php.net/manual/en/function.mail.php
> Caution
> (Windows only) When PHP is talking to a SMTP server directly,
> if a full stop is found on the start of a line, it is removed.
> To counter-act this, replace these occurrences with a double dot.
> <?php
> $text = str_replace("\n.", "\n..", $text);
> ?>
If PHPMailer on Win, and if PHP is talking to SMTP directly, and if PHPMailer on Win doesn't do the "counter-act", leading dot is removed by PHP.
If SMTP server is tested with such environment only or configured for such environment only(SMTP doesn't remove first dot), and if PHMailer is used on other than Win or if PHP is not talking to SMTP directly, phenomnon of "leading dot is not removed by SMTP" can happen.

By the way, PHP's spec(for many funtion's spec, not for good/concice language spec) is hard-to-understand for me in many places. It's probably for casual PHP coder on Win, after many complaints about "double dot", and, the Caution was added to manual because of reports for "lost dot" on Win.
FYI.
Following is similar report of Zend fraework to yours.
> http://framework.zend.com/issues/browse/ZF-10807
> Dot character is duplicated when in 73rd position of plain text content
As PHP/mail extention sends with line length=72(excluding new line), ".END" part of "72 bytes of X" + ".END" is sent as a line, and it's passed to SMTP server as line of "..END" according to RFC.
In the ZF-10807, I can't know "Dot character is duplicated" by reporter is TCP dump level phenomenon or phenomenon at mail recipient. As for test result by other than reporter, the data looks to have been sent correctly to mail recipient as expected, or line length greater than 72 bytes looks to have been used in their duplication test.
Request by Ludovic in commet #1 is TCP level trace data to see sent data for the ".email". Bernardo Silva(ug opener), can you get trace data like TCP dump?
Emails go out and go to the php bernardo@datamex.com.br, arriving on the server, the server sends a copy to gmail.
The strange thing is that if this email is sent to "bernardo@datamex.com.br;lisandro@datamex.com.br" in tb the error occurs and the live mail lisandro not.

DEBUG produced in class phpMailer > smtp in function Data 

input string 
string(430) "Date: Wed, 22 Dec 2010 18:48:01 -0200
Return-Path: suporte@e-login.net
To: bernardo@datamex.com.br
From: suporte@e-login.net
Subject: Tarefa atualizada: asasdfasdfafgadfg zsdfgasdfg
Message-ID: <313bcd575ca816df5d5ea59f4d458a79@dev.datamex.com.br>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="iso-8859-1"

.email
"

string send to smtp server

"DATA
Date: Wed, 22 Dec 2010 18:48:01 -0200
Return-Path: suporte@e-login.net
To: bernardo@datamex.com.br
From: suporte@e-login.net
Subject: Tarefa atualizada: asasdfasdfafgadfg zsdfgasdfg
Message-ID: <313bcd575ca816df5d5ea59f4d458a79@dev.datamex.com.br>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="iso-8859-1"

..email


."

is really the error was in class phpmailer

gmail must identify and correct this error
(In reply to comment #10)
> The strange thing is that if this email is sent to
> "bernardo@datamex.com.br;lisandro@datamex.com.br" in tb the error occurs and
> the live mail lisandro not.

If multiple mail addresses, To: should be "To: bernardo@datamex.com.br, lisandro@datamex.com.br". Did you specify recipients correctly? ";" is a part of group address, so Tb never uses ";" as separator according to RFC. But some mailers use ";" as alternative for separater of ",". 

> string send to smtp server
> "DATA
>(snip)
> ..email
> ."
> is really the error was in class phpmailer
> gmail must identify and correct this error

If the data logged by DEBUG is data passed to SMTP server from PHPMailer/PHP, phenomenon is "PHPMailer/PHP passed data to SMTP server correctly according to RFC, and, SMTP server should remove first full stop according to RFC but doesn't do it", isn't it?
Or PHP and mail extention passes "...email" to SMTP server according to RFC after it?
After reporting this error to phpmailer, and read the rfc 821 and 822 discovered that the problem is not in phpmailer but in thunderbird.

The final test to prove it is:
As described in the RFC, a line begins with "." should be prefixed with another "."

Then what is being sent by phpmailer is correct


if I send
.email *{font-family:Arial, Helvetica, sans-serif}
I receive in thunderbird
email *{font-family:Arial, Helvetica, sans-serif}

if I send
. .email *{font-family:Arial, Helvetica, sans-serif}
I receive in thunderbird
 .email *{font-family:Arial, Helvetica, sans-serif}

if I send
..email *{font-family:Arial, Helvetica, sans-serif}
I receive in thunderbird
..email *{font-family:Arial, Helvetica, sans-serif}

note that only in the last test thunderdird not removed the "." at the beginning of the line


--------------------------------------------------------
                      tests
--------------------------------------------------------

tests were conducted directly by telnet

%telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 dev.datamex.com.br ESMTP Sendmail 8.14.2/8.14.2; Thu, 17 Feb 2011 18:03:45 -0200 (BRST)
mail from:<bernardo@datamex.com.br>
250 2.1.0 <bernardo@datamex.com.br>... Sender ok
rcpt to:<bernardo@datamex.com.br>
250 2.1.5 <bernardo@datamex.com.br>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
.email *{font-family:Arial, Helvetica, sans-serif}
.
250 2.0.0 p1HK3j3O015318 Message accepted for delivery
quit
221 2.0.0 dev.datamex.com.br closing connection
Connection closed by foreign host.


%telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 dev.datamex.com.br ESMTP Sendmail 8.14.2/8.14.2; Thu, 17 Feb 2011 18:05:48 -0200 (BRST)
mail from:<bernardo@datamex.com.br>
250 2.1.0 <bernardo@datamex.com.br>... Sender ok
rcpt to:<bernardo@datamex.com.br>
250 2.1.5 <bernardo@datamex.com.br>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
. .email *{font-family:Arial, Helvetica, sans-serif}
.
250 2.0.0 p1HK5mj4015325 Message accepted for delivery
quit
221 2.0.0 dev.datamex.com.br closing connection
Connection closed by foreign host.


%telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 dev.datamex.com.br ESMTP Sendmail 8.14.2/8.14.2; Thu, 17 Feb 2011 18:07:42 -0200 (BRST)
mail from:<bernardo@datamex.com.br>
250 2.1.0 <bernardo@datamex.com.br>... Sender ok
rcpt to:<bernardo@datamex.com.br>
250 2.1.5 <bernardo@datamex.com.br>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
..email *{font-family:Arial, Helvetica, sans-serif}
.
250 2.0.0 p1HK7gSI015330 Message accepted for delivery
quit
221 2.0.0 dev.datamex.com.br closing connection
Connection closed by foreign host.
%
Severity: normal → critical
Version: unspecified → 3.1
(In reply to comment #12)
> if I send
> ..email *{font-family:Arial, Helvetica, sans-serif}
> I receive in thunderbird
> ..email *{font-family:Arial, Helvetica, sans-serif}
> note that only in the last test thunderdird not removed the "." at the
> beginning of the line

Note that "add ." should be done by SMTP client(PHPMailer + someone other than Thunderbird) and "remove ." should be done by SMTP server(your SMTP server) in your test.
Why can Tb as POP3 client or IMAP client be relevant to phenomenon of ". is adddd/not added, . is removed/not removed"? 

In your test with telnet, SMTP client defined by RFC of SMTP is "you+telnet", and telnet himself is never SMTP client, because telnet merely passes thru data typed by you to requested port of requested server by you.
i.e. You are who should add "." if data line starts with "." before "you+telnet" passes data to SMTP server.
And, who should remove the added "." in the passed data from "you+telnet" is your SMTP server.
After that, Thunderbird merely receives mail data passed from final destination server, POP3 server or IMAP server.
Can you distinguish SMTP, POP3, and IMAP?

In any your test, Thunderbird can be relevant to issue only when you send mail data of "line starts with dot" using Thunderbird.

Can you check with port=587 using your SMTP server and telnet?
Can you test with your SMTP server using SSL? (usually port=465, SSL/TLS in Tb's SMTP server definition)
Can I test with your SMTP server using telnet, port=25/587? (no userid/password needed?)

Another considerations is, as I stated before, hard-to-understand spec/implementation of PHP's mail send function on Windows.
In my quick check of several PHPMailer manuals, I couldn't find such funny spec in PHPManual, but it's still uncertain.
Is bug summary correct? Is problem really occurs only when ".email" line is sent by Thunderbird?
I don't think so, because you say "..email ..." via telnet was finally passed to Thunderbird as "..email ..."(as-is).
Because it looks no problem if ".email ..." and ". email ...", I think current phenomenon is "Your SMTP server doesn't remove dot at first byte of a line, if a line starts with two(or more) dots".
If I understand RFC correctly, first dot should be removed by SMTP server even when line starts with two consecutive dots, and many SMTP servers behaves so.
Our server is closed to outside access, it's Sendmail 8.14.2/8.14.2.

as the tests tested on a different server and Postfix error occurred.
send
.email{}
..email{}
. .email{}

receive
email{}
..email{}
 .email{}

Personal'm tired of trying to help people here spoke AoS which is smtp error in, or in another library.

Because I think it's bug in thunderbird:
1 - ALL other email clients show the email correctly
2 - Several servers were used Sendmail, Postfix, and the error only occurred in thunderbird.

Let's think
Windows Live Mail, Gmail, Outlook Express, Outlook 2003, they all show the correct email ONLY thunderbird gives error.
Sorry, who can't distinguish SMTP, IMAP, POP3 was me.

Next data was sent as text/plain and <pre> of text/html by Tb 3.1.7 via SMTP, and received via IMAP and POP3.

Start of test
email
.email
. email
..email
...email
End of test

As my ISP supports both IMAP and POP3, same data is received by Tb 3.1.7.

If POP3, followind is downloaded via POP3.
> 00000669 26.05199432 [5164] 0[192c140]: RECV:     <pre>Start of test 	
> 00000670 26.05208588 [5164] 0[192c140]: RECV: email 	
> 00000671 26.05217743 [5164] 0[192c140]: RECV: ..email 	
> 00000672 26.05227280 [5164] 0[192c140]: RECV: .. email 	
> 00000673 26.05236435 [5164] 0[192c140]: RECV: ...email 	
> 00000674 26.05245590 [5164] 0[192c140]: RECV: ....email 	
> 00000675 26.05254936 [5164] 0[192c140]: RECV: End of test 	
> 00000676 26.05264091	[5164] 0[192c140]: RECV: </pre>

Tb 3.1.7 removed this "added dot" as expected, and the expected version(dot is removed, same as oiginal string) was saved in file named Inbox of POP3 account. 

This "added dot" is not seen in IMAP log.
> 00000322 11.77125931 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket:     <pre>Start of test  
> 00000324 11.77139473 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket: email  
> 00000326 11.77152729 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket: .email  
> 00000328 11.77166176 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket: . email  
> 00000330 11.77179527 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket: ..email  
> 00000332 11.77194118 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket: ...email  
> 00000334 11.77207470 imap.cm.dream.jp:S-INBOX:CreateNewLineFromSocket: End of test

Can you get POP3 log for download of mail data by Tb, which is sent by "you+telnet"?
> https://developer.mozilla.org/en/HTTP_Logging
(In reply to comment #15)

Personal'm tired of trying to help people here spoke AoS which is Thunderbird bug without evidence or data required to analyze problem.

As seen in my next log, Tb 3.1.7 removed first dot from any of next line.
> 00000671 26.05217743 [5164] 0[192c140]: RECV: ..email 	
> 00000672 26.05227280 [5164] 0[192c140]: RECV: .. email 	
> 00000673 26.05236435 [5164] 0[192c140]: RECV: ...email 	
> 00000674 26.05245590 [5164] 0[192c140]: RECV: ....email 	

Following is pasted data from View/Message Source of really downloaded mail via my ISP's POP3 with above log, not from mail data in Sent, not from Inbox of IMAP.

X-Account-Key: account1
X-UIDL: 000001554c354af7
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
X-DTI-Virus-Check: checked
X-DTI-Recipient: <??????@ops.dti.ne.jp>
Return-Path: <??????-xxx@ops.dti.ne.jp>
Received: from mx04.cm.dti.ne.jp (mx04-fbp.cm.dti.ne.jp [10.236.71.124]) by store17-fbp.cm.dti.ne.jp (3.10pn) with ESMTP id p1INeHI2004712 for <soarex@ops.dti.ne.jp>; Sat, 19 Feb 2011 08:40:17 +0900 (JST)
(snip)
  <body bgcolor="#ffffff" text="#000000">
    <pre>Start of test
email
.email
. email
..email
...email
End of test
</pre>
  </body>
(In reply to comment #15)
> send
> .email{}
> ..email{}
> . .email{}
> receive
> email{}
> ..email{}
>  .email{}

> Windows Live Mail, Gmail, Outlook Express, Outlook 2003, they all show the
> correct email ONLY thunderbird gives error.

As seen in my test data, Tb removes first dot when sent as "..email" from POP3 server. It indicates "...email" is sent from POP3 server to Tb, if ordinal Thunderird is used. 

Is downloaded from same server of same server type by all mailers?
If different, Thunderbird case is POP3 and still checked with mail transfered by sever side transfer service? Or without transfer service?
Can you check with Tb and IMAP which doesn't add "."?
Another suspect is "[LF]..email{}" instead of "[CRLF]..email{}" from POP3 server to Thunderbird. In this case, new line character is relevant to problem. Please attach log file/mail data instead of paste, and if log file is edited by editor before attach, never change any new line character in file, please.
I'll be honest, between all of the bickering, I'm not quite sure where the problem being reported is.

Sending a mail `.test' from gmail web interface to myself (downloaded via POP) faithfully reproduced '.test' in Thunderbird. So did an email going the other way. I also know that the dot-stuffing is handled before the data gets piped in/out anywhere else in the program, so the problem could only occur via malformed messages in the first place.

There is an easy way to see if the problem is a fault by Thunderbird or by someone on the other end: that would be a POP log (if message being received by TB) or SMTP log (if message being sent by TB). Thunderbird has a built-in facility to handle these logs (<https://wiki.mozilla.org/MailNews:Logging>); these logs faithfully reproduce the TCP stream except for places where login information could be leaked. In lieu of such information, however, I must presume that the bug is not present in Thunderbird but rather some other MTA in the system.
Whiteboard: closeme 2011-11-09
Desculpe por não ter atualizado antes o bug, depois de muitas busca descobri que isso é um problema conhecido no dspam.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Sorry for not updated before the bug, after much searching found that this is a known issue with dspam.
dspam: 
  http://en.wikipedia.org/wiki/DSPAM
  http://www.nuclearelephant.com/
A Web page found by Google search for "dspam bug dot".
> http://www.mail-archive.com/dspam-devel@lists.sourceforge.net/msg01887.html
> [Dspam-devel] [ dspam-Bug Tracker-3102438 ] double dots in mails after SMTP dot escaping
> Bug Tracker item #3102438, was opened at 2010-11-03 19:56
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: