jd142 said:
That's not what happens. Double click a file and the app opens.
There's no prompt to save it before the default action takes place.
And that's what I want to stop.
Actually my behavior was modified from the default because I had
performed the registry hack to not block .exe, .com, .bat, and .url
attachments. So what I saw in Outlook 2002 when I double-clicked on the
attachment in the e-mail was a dialog that only allowed me to save the
attachment to a file. There was no option to open the attachment. Once
I removed the Level1Remove registry hack (so those filetypes were no
longer bypassed), an e-mail received having an attachment of a hazardous
filetype, like .exe, showed a yellow status bar at the top of the view
pane that said Outlook had blocked that attachment and I had no way to
access it (so it could not be opened or saved). I'm sure if you visit
the newsgroups long enough that you'll see plenty of post of users
asking how to get around "Outlook blocked access". I doubt Outlook 2003
would reduce the security measures present in Outlook 2002. So, unless
I use the Level1Remove registry edit, I cannot even get at the hazardous
attachment. Are you claiming that Outlook 2003 discard all security
measures from Outlook 2002 and now any and all attachments can be opened
when double-clicking on the attachment icon in the e-mail? Wow, that
ought to piss off a lot of network admins.
Since they save it in the same directory where the temp file is,
windows hides this from them. By default, Outlook 2003 makes temp
files in c:\documents and settings\%username%\local
settings\temp\out<differentnumber>. By default, the c: drive is
hidden
when they go to my computer. And by default the local settings folder
and temp folders are too. I'm not opening up the hard drive to them
so
they can browse down to copy the files.
So why are Outlook users on their hosts having to go to your host to get
their attachments? If you're using Exchange, they'll be using the
mailbox on the Exchange server. If they are using a PST file, that is a
local message store on their host (and Microsoft recommends AGAINST
using PST files across a network). Non-admin users aren't going to see
the PST files normally saved under the %userprofile% for other accounts,
and they won't be able to access resources for mapped drives other than
the permissions configured for that access.
Why do Outlook users have to go to your host to get their attachments
(or anything generated by their instance of Outlook)? Your host goes
down or you power it off or lose power and everyone's e-mail dies. I'm
not even sure how you could even get Outlook to go put its temp files
under someone else's %userprofile%. It's not a configurable option and
fraught with disaster.
Obviously I'm not talking about a hazardous file type.
Well, yeah, now that you made that declaration it is obvious. It was
not obvious in your original post. I haven't seen a lot of admins
worried about their users getting .txt files as attachments.
Except it isn't the first prompt.
You've gotten something weird setup for your test case of Outlook.
http://office.microsoft.com/en-us/assistance/HP052746751033.aspx
You're saying that when the user attempts to do something with the
attachment that the only option available is to open it?
http://support.microsoft.com/default.aspx?scid=kb;en-us;277793
"you can double-click the attachment, and then click Save to disk or
Open."
(except for a hazardous filetype which only has the Save to disk option)
Nope. You don't understand the situation.
What, you've never heard of private network space? Why would you
assume the default location is a shared one? It's trivial to tell
Word, Excel, Access, and Powerpoint that they should use
\\servname\%username%\ as the default file location, and only that
user
gets access to that directory. Or do you not know how to use
environment variables and gpos to control office apps?
Which was what I alluded to later by mentioning this method of
attachment striping should save them somewhere that regulates who can
access them based on the account through which they were received. Lots
of ways to do that so I wasn't going to bother delineating them all.
Sometimes there isn't choice when central IT forces programs but
leaves
implementation up to individual departments. You must use *this* app,
but how you customize it for your users is up to you.
Alas, tis true. They want Outlook and that's all you get to use. But I
don't see anything of what you want to do as being something innate to
Outlook's functionality. That's why I mentioned maybe using a filtering
proxy upstream of the user hosts to do the attachment stripping for you.
Since the product won't do what you want, something else might. All the
users still get to use Outlook which is mandated but perhaps IT will
allow running the upstream proxy to effect the behavior you want
(presumably Exchange isn't involved here).
I specifically said I wanted them to open the app, then the
attachment.
I don't want to stop them from opening the app, I just want them
forced to save it only.
The app? The attachment? What's the difference? I went back to your
original post and from the statement, "They double click an attachment,
edit and save it and it ends up buried in local settings and they have
to change the name" then I'm guessing what is really happening is that
the recipient gets an e-mail with, say, a .doc attachment, chooses to
open it (instead of save it to a selected and known path), and they are
actually editing the temporary copy and then forgetting to specify where
to save it to a selected an known path before exiting the editor. If
that's what is happening, Open never did a save of the file to keep a
non-temporary copy of it and opening files inplace or inline has always
incurred the liability of loss if the user doesn't then save it before
exiting the application used to view or edit it. Open doesn't imply
Save. Eudora's behavior was different in that it performed a save even
if the user never did want to do the save and then links to that in the
e-mail message. This means the e-mail content is probably getting
altered to removed the encoded portions representing the attached files
and creating files for them and then replacing the encoded text section
for the attachment with a link. That means the user never does get the
real e-mail but instead some sliced up version of it. If Eudora isn't
stripping out the encoded section after creating the file containing the
attached file, you end up with twice the space wasted, one for the
holding file and another for the encoded section in the e-mail. In
either case, Eudora has already created a file by effecting an
unsolicited save operation.
The users are migrating to a different e-mail client. They didn't
expect some retraining was needed? They'll have to get used to doing a
Save first and then editing the saved copy, or opening the attachment
document to edit it and remember to use Save As before exiting so they
don't lose that temporary copy.
I sent myself a test e-mail with a .doc attachment. On receiving the
e-mail, it was available as an attachment since it isn't one of the
hazardous filetypes (actually I was a bit surprised since it could
contain macro viruses). I then double-clicked on it. I got the prompt
dialog offering me to Open It or to Save It To Disk (both options were
there, not just Open). It is possible the user unchecked the option to
always ask about opening a file of this type. I want that prompt so I'm
not sure how it would change if this option was disabled. I chose to
Open It which sounds like what your users are doing. Since Word which
is installed is associated with .doc files, the document opens in Word.
When I look under File -> Properties, it says the path to the file is
"C:\Documents and Settings\<myaccount>\Local Settings\Temporary Internet
Files\OLK89" but the filename is not "out<number>" nor is the file under
my %temp% path. If I edit the file and just exit and opt to save, it is
still in the same TIF path as before. I'll need to use Save As if I
want it somewhere else (if all I'm trying to get around is having to
view hidden directories). Yeah, that folder is hidden but that won't
stop the user from going there if they change Explorer's settings, or
just add the "\OLK89" at the end of the Address bar after navigating to
the TIF directory.
So, yeah, Outlook behaves differently but then any application that lets
you open a file without first explicitly saving it is performing an
implicit save for you and so how it does the implicit save is how it was
coded. Eudora did it differently. Pegasus probably does it differently
than Outlook and Eudora, too.
It does once you flag their attachment directory as deny execute.
Duh.
Because that path continues to exist whether the application is using it
not, so your permissions on it will still apply. The TIF\OLK89 path is
*temporary* because the file was never saved before opening it.
Just because you think you know what you're talking about but don't
have any actual useful information, doesn't mean you still have to
post. dumbass.
Outlook won't do what you want it to do. No one apparently bothered to
consider the cost of retraining their users when forcing them to change
e-mail clients. Apparently you (or your IT dept) doesn't want to deploy
upstream solutions, like a proxy, to modify and effect the behavior that
you want. So you're stuck with what features the e-mail client provides
that you choose to use or were forced to use.
This will be my last post to you since you find my suggestions or
replies so offensive. This will also be the last post I see from you.
Maybe you'll get help from some others. Maybe not since we are, after
all, volunteers here and not working for Microsoft and definitely not
working for you.
*PLONK*
