340121 - Simultaneous email sending with identical file name attachment (from different directories) causes first email's attachment to be sent to all recipients.

Status: RESOLVED INCOMPLETE

(Thunderbird :: General, defect)

Description

[ken.byers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

When sending more than one email at the same time (simultaneous) with a large attachment on a 100 Mbps DSL line and each attachment file names is the same (but from different directories and with different content) all the simultaneous email recipients receives the attachment from the email that started sending first.

Reproducible: Always

Steps to Reproduce:
1.Create 2 large zip files in different directories with the same file name but containing different content.
2.Right click on - file name, click on - send to, click on - mail recipient, address the email to yourself, click - send.
3.Repeat step 2 above for the second directory WHILE first email is STILL in the process of sending.

Actual Results:  
Check the sent and received email attachments contents and both will contain the content of the attachment from the email that started sending first.

Expected Results:  
Both emai's attachments should have different content even though the attachment file names are the same.

Thunderbird release is 1.5.0.4 (200060516)

I think this is a critical problem because email recipients could receive information intended for another recipient.

The workaround is, "don't sned while another send in in progress that has the same attachment file name."

Comment 1

[Joxean]

I've had a very similar problem but sending wasn't simultaneous.

First I sent a file on a message and later I created a new version of that file with the same name and sent it. The file sent was the first one.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Reporter, does the issue still occur in the latest supported 2.0.0.x / trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.16)

Comment 3

[Joshua Cranmer [:jcranmer]]

RESO INCO per lack of response to last question. If you feel this change was made in error, please respond to this bug with your reasons why.