User-Agent: lynx 5.5 (vision impaired version) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 Attached a file to my email. wasn't finished composing yet, needed to do more testing....testing overwrote file that I had already attached. Later, hit SEND, and it either (1) sends wrong file contents (if file contents were replaced after attachment but before send) or (2) says file doesn't exist (if file deleted after attachment and before send). Either way this is a nasty bug, with possible unintentional security leakage -- i.e. if file has been replaced with new contents that contain sensitive info, you just accidently released the sensitive info -- even though the file didn't contain the info when you attached it. Reproducible: Always Steps to Reproduce: 1. attach file with text "boring text" in it. 2. modify file, add your checking account statement to it! :-) 3. send email; the recipient gets your checking account statement instead of just "boring text" Actual Results: wrong file got sent in 1 case, in another was flagged with error that file didn't exist when I hit send -- shouldn't matter, I already "attached" the file and it should store it somewhere as a separate copy. Expected Results: should copy attached file into tmpdir/mozilla-tmpname-xxxxxx when attached, so user isn't surprised. It's like the modern "lp/print" systems -- they make a copy of the file being submitted for print, so if user deletes or edits file afterwards, before file is actually printed from queue, it doesn't alter the output -- they still get the file they queued for printing (or in this case, attached for sending) in the final output...

Confrming, WinXP, Moz 1.5. I've also noticed/suspected this, but didn't complain 'cos I kind of found this useful. Namely, I attached a file, edited the file some more, then hit send. However, this IS a small security issue. Before actually fixing this, we should also see what other mail agents do. What do Outlook, Eudora, Pine, (your other favorite email program) do?

guessing this should go from cavin -> mscott, bienvenu, ssptizer at this point. not sure this is really a security bug... attachments should be made when the file is ready to go would be the behavor that most people observe and expect I would think

this is by design. we have always done it this way. So has 4.x

There are several duplicate bugs that request the same. Furthermore, things have changed over time since 2003... There's Bug 378046 around the same problem and it has been confirmed, so this can no longer be invalid. And, there's some agreement among developers in bug 378046 that "always take a snapshot" at attachment time should be the starting point for fixing the respective bugs, including this one --> duplicate of bug 378046. btw the fact that "we have always done it this way since 4.x" surely doesn't mean that things couldn't or shouldn't change, otherwise there'd be no evolvement at all...