Using buildid 2002040210 on Windows XP Reproducible: Always Steps to Reproduce 1. Get someone using N.4x to email you a link to a file on a shared network drive. 2. Try clicking on link Actual Result. Clicking on link does nothing Expected Result: Clicking on link opens file from shared network drive.
This works fine in NS4.x so I'll mark as 4xp
Invalid. Remote content cannot link to local content for security reasons. Mail is remote content. See bug 84128 for discussion on the issue as well as the pref you can set to disable this security check (in bug 84128, comment 20)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Bug 84128 is to do with browser file:// links and whether it pops up a window and what sort of window it should pop up. This is a change in behaviour from NS4.x and users, used to NS4.x, will be confused by the change and lack of explanation. Corporates tend to encourage use of links to files on shared network drives rather than sending huge attachments round and eating up disk space. A file:// link in an email doesn't pop up any sort of window error or dialog! The user_pref("security.checkloaduri", false) mentioned seems to be to black and white, there should be some sort of grading. I think the Mozilla should be able to determine whether it is an internal e-mail (or a list of safe domains which it auto-fills with your domain when you run mail account wizard) or an external e-mail (or those not in your list of safe domains) and have preferences to let you configure what Mozilla does with file links in each circumstance. Reopening and tweaking summary.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: file:// links sent from NS4.x do not open in Mozilla → file:// links sent from NS4.x do not open in Mozilla or pop up an explaination
Splitting no information pop-up part of bug into bug 157885. I'll alter this bug to be an enhancement request.
Severity: normal → enhancement
Adjusting summary original summary was "file:// links sent from NS4.x do not open in Mozilla or pop up an explaination"
Summary: file:// links sent from NS4.x do not open in Mozilla or pop up an explaination → [RFE] Allow graded access to file:// links within mailnews
Raising security to normal, the user should be able to click on a valid file url link. Also set component to Security:General
Assignee: sspitzer → mstoltz
Severity: enhancement → major
Component: Mail Window Front End → Security: General
QA Contact: olgam → junruh
*** Bug 179511 has been marked as a duplicate of this bug. ***
Any status on this bug?
*** Bug 225425 has been marked as a duplicate of this bug. ***
Bug 233108 covers the more general case and has a patch. *** This bug has been marked as a duplicate of 233108 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 15 years ago
Resolution: --- → DUPLICATE
This is different, imo... That bug's patch will let you give your mail messages access to all files on your hard drive. Doing so, imo, is stupid. We need a better setup for mail messages.
Status: RESOLVED → REOPENED
Depends on: 233108
Resolution: DUPLICATE → ---
*** Bug 266261 has been marked as a duplicate of this bug. ***
*** Bug 301173 has been marked as a duplicate of this bug. ***
*** Bug 337581 has been marked as a duplicate of this bug. ***
The first part of a fix to this bug is probably implementing a way of checking if the file resides on a networked drive. AFAIK in non-windows environments this will be any link starting with file://///, in windows there is that but also networked drives which we should be able to determine using a call to GetDriveType
Assignee: security-bugs → nobody
Status: REOPENED → NEW
QA Contact: bsharma → security
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.