Notify senders of email that certain attachments will be blocked

[Guest]

Since many different file types are now blocked from receiving as attachments
in Outlook, and cannot be unblocked, why not at least notify the sender that
an attachment about to be sent will not be able to be received by the
recipient, so that alternate means of sending the desired attachment can be
sought?

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/office/com...8d2aabcc2&dg=microsoft.public.outlook.general

 

[Vince Averello [MVP-Outlook]]

How can your client determine what the capabilities of a remote mail client
are?

 

[Guest]

The post was for Outlook, not some other "remote mail client". And, I now
know which file types (virtually all) are excluded from being seen (i.e.
"blocked") at the recipient's location. Since. by the wisdom of MS Outlook
management, almost all file extensions are now "blocked" on the recipient
end, at least let the sender know that his file is going to be blocked on the
other end.

 

[Vanguard]

Since many different file types are now blocked from receiving as
attachments
in Outlook, and cannot be unblocked, why not at least notify the sender
that
an attachment about to be sent will not be able to be received by the
recipient, so that alternate means of sending the desired attachment can
be
sought?

So you want to send an e-mail telling the recipient that they are going to
get another e-mail from you? Geez.

You don't have any control over the recipients e-mail client. They may
choose to block some attachments, all of them, or none of them. You won't
know and you don't get to control their e-mail client. Not everyone uses
Outlook. Not all Outlook users choose to remain crippled regarding which
attachments are blocked.

 

[Vince Averello [MVP-Outlook]]

I use Outlook 2003 and have access to all extensions. So, it would be
incorrect to assume everyone is setup the same way even if they're using the
same mail client. You could ZIP all outgoing attachments so that just about
all people, regardless of setups, would be able to access the attachments

 

[Guest]

Vanguard, if you can't keep from being a smartass, don't bother answering. I
didn't suggest sending an email to tell them they're getting another email.
Since you obviously didn't understand my suggestion, lay off please. I need
no additional responses from your type. You're obviously one of those
nerd-types that thinks everyone else is a dumbass and you're the only one who
knows anything. There are many Outlook attachment file types that "cannot"
be unblocked by design (if the recipient mail client is also Outlook)
according to MS Outlook's own group manager.

 

[Guest]

http://office.microsoft.com/en-us/assistance/HA011894211033.aspx
Vince, the above link from the Outlook Development General Manager at MS
says in this document that I "cannot" unblock various file types as
attachments. So, if you know a way to "setup" Outlook 2003 that will allow
me to receive these file types, please let me know because even MS says it
cannot be done. By the way, MS also suggests zipping the file types that
cannot be unblocked.

All I suggested was that a reminder note pop up to a sender that a file type
he is about to send will likely not be able to be received on the other end
if they are using Outlook 2003. What started this was that last night I
emailed from my home to my office a whole bunch of .url web site links, only
to find this morning in my office that I couldn't receive them because
Outlook 2003 "blocked" them. When I tried to unblock them, I found there was
no way according to the help files. If a note last night had popped up to
me, before I knew that I could not send .url file types, and suggested that I
might want to do something else, like zipping them, or that the .url file
type attachments could not be received by a user of Outlook 2003, then I
would have taken another action. But, unfortunately, I had to find out the
hard way this morning in my office that I couldn't receive my own email with
those attachments.

 

[Sue Mosher [MVP-Outlook]]

Outlook has done that for years. If the user tries to send a message with, for example an .exe file attached, Outlook warns the sender that recipients may not be able to receive it and gives the sender a chance to edit the message before finally sending it.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Vince Averello [MVP-Outlook]]

Take a look here:
http://www.slovaktech.com/attachmentoptions.htm

 

[Vanguard]

Vanguard, if you can't keep from being a smartass, don't bother answering.
I
didn't suggest sending an email to tell them they're getting another
email.
Since you obviously didn't understand my suggestion, lay off please. I
need
no additional responses from your type. You're obviously one of those
nerd-types that thinks everyone else is a dumbass and you're the only one
who
knows anything. There are many Outlook attachment file types that
"cannot"
be unblocked by design (if the recipient mail client is also Outlook)
according to MS Outlook's own group manager.

Gee, wherein your original post did you mention the group manager, or
pushing policies, or a domain, or that the recipients are somehow forced to
use Outlook or you can guarantee that every recipient uses Outlook?

So, you're going to use telepathy to notify them before sending your mail
with the attachment? Uh huh. Hey, you were the one asking to notify BEFORE
sending by your statement "why not at least notify the sender that an
attachment about to be sent". So how do YOU notify the sender that an
attachment is "about" to get sent? By telling them beforehand, that's how,
and that means sending them an e-mail to notify them about the next e-mail
that has the attachment. Or maybe you have some other magical means of
notification. How to notify before sending? Well, what did YOU think
should be that "notification"? A postcard? A telephone call? Instant
messaging (which only works if you and the recipient use compatible IMs)?
Screaming real loud? So it seems you were asking about how to send [via
e-mail] a notification before sending your e-mail with the huge attachment,
and that means the recipient gets 2 mails.

Oh, we are now supposed to know that you were using Outlook in an Exchange
environment were Level 1 attachments can be overridden by policy? Uh huh.
And that ALL your recipients will be in that same Exchange-Outlook
organization? And that ALL your recipients will always be Outlook users?
Don't really see that mentioned in your original post.

The real problem is with a rude user that consumes the recipient's mailbox
with huge attachments that the user may never need using a protocol (POP3)
that is slow compared to FTP or HTTP file transfer, especially since e-mail
providers often throttle the bandwidth to ensure adequent response to all
concurrent connects, and which easily corrupts, takes a lot longer to
download, and (on and on as to why e-mail is a stupid file transfer
mechanism). Stop sending huge attachments to your recipients. Instead put
a link in your e-mails to a copy of the file that you have saved on online
storage (web page, online file space services, online mail services, like
dropload.com, FTP server, or wherever). There are LOTS of alternate methods
to make the file available for download that are separate of bloating your
e-mail with it.

If the recipient has a high-speed connection, lots of disk space, and always
wants your huge attachments before they even know what they are, yeah, then
they want to download your huge e-mails. Within the same organization that
might be the case but not when sending, in general, to any recipient. You
never did bother to mention the network and environment for both sender
(you) and recipient, so all recipients would apply to your "suggestion",
including those with slow dial-up connects and smaller mailboxes.

*IF* the recipient also uses Outlook. So how will you guarantee that only
Outlook users are recipients of your sometime-in-the-future-delivered huge
e-mail with the attachment?

*IF* the recipient also uses a high-speed connection to reduce the time to
download your huge e-mails. Guess you forgot about all those dial-up users
that have to wait and wait and wait to download your mail only to find a
huge attachment that they don't want. Yes, they can configure to not
download if the message exceeds a certain size (*IF* their e-mail client has
that option) but then they are stuck with your huge mail consuming their
mailbox quota.

E-mail is NOT a reliable file transfer scheme. It is also a slow file
transfer scheme even when using a high-speed connect because most mail
servers are throttled per connect so that other connects get some response
and aren't locked out by just one users huge download. You huge mail takes
an excessive time to download for dial-up users. Everytime you add an
attachment, it gets encoded into a plain-text section within your mail that
balloons its size by 30% to 50%. You needlessly consume a large portion of
the recipient's quota regarding disk space for their mailbox (not everyone
has a mailbox as big as yours).

You never said the recipients are always guaranteed to be within your same
Exchange-Outlook organization. So how would any of your policies appy to
anyone else outside your orgnization regarding which filetypes are blocked.
The user can override any of the Level 1 filetypes as long as a domain
policy hasn't overwritten those values in the registry (but then the user
can override policies depending on their permissions but I'm not going to
mention how). Level 2 filetypes merely prompt the user to do a save. So
what filetypes were you talking about? You never mentioned YOUR environment
or the use of policies in a domain or just where are your recipients.

Since the Level1Remove registry key dictates which filetypes are hazardous,
what OTHER filetypes are you asking about?

http://support.microsoft.com/?id=829982

So what filetype(s) have you added to the Level1Remove registry key that
still remain blocked? Does the recipient really care about whatever
policies are enforced in your organization?

 

[Brian Tillman]

Since many different file types are now blocked from receiving as
attachments in Outlook, and cannot be unblocked, why not at least
notify the sender that an attachment about to be sent will not be
able to be received by the recipient, so that alternate means of
sending the desired attachment can be sought?

That information, however, is unknowable. How can Outlook tell what your
recipient can or cannot see?

 

[Guest]

Sue, thank you. You completely understood what I was suggesting. However,
last night when I emailed from home to my office using Outlook in both
places, with .url web site addresses as attachments, Outlook did not warn me
as the sender that I might not be able to receive it at my office (which
incidentally were all blocked by Outlook 2003 in my office). Hence, my
suggestion to Outlook. However, whatever the reason that it did not warn me,
thanks for understanding my suggestion. You win a gold star for
understanding and responding with good taste.

 

[Guest]

Thanks Vince.

Take a look here:
http://www.slovaktech.com/attachmentoptions.htm

 

[Guest]

I agree with the simple aspect of your request. Tragically, this entire issue
and all the confusion around it demonstrate the inconsistent and bipolar
behavior Outlook has adopted for attachments. If Outlook expects attachments
to be blocked, it should not even send them. But on the other hand since
perhaps they will be allowed it sends them any way. I can't always control
how friendly attachments will be sent to me. So Outlook is no longer viable
for home or small business, because this attachment behavior is not alterable
outside the enterprise environment and Exchange Server. Nor should I hve to
download a third party shareware attempt at a fix. Microsoft is right to be
concerned with malicious attachments, but it should utlimately and always be
the user that has the final liability and control.

 

[Lanwench [MVP - Exchange]]

In

I agree with the simple aspect of your request. Tragically, this
entire issue and all the confusion around it demonstrate the
inconsistent and bipolar behavior Outlook has adopted for
attachments. If Outlook expects attachments to be blocked, it should
not even send them. But on the other hand since perhaps they will be
allowed it sends them any way. I can't always control how friendly
attachments will be sent to me. So Outlook is no longer viable for
home or small business, because this attachment behavior is not
alterable outside the enterprise environment and Exchange Server. Nor
should I hve to download a third party shareware attempt at a fix.
Microsoft is right to be concerned with malicious attachments, but it
should utlimately and always be the user that has the final liability
and control.

You do have this control, and you don't need any third party stuff to use
it.
http://www.slipstick.com/outlook/esecup/getexe.htm

 

[Guest]

Thanks!! It appears that some sanity prevails. To me, this entire controversy
is summarized as follows.
1. In its perception of the users best interest, Microsoft should block or
unblock any attachments it so chooses as a default behavior in its products.
2. In its pursuit of maximizing the user's productivity, Microsoft should
provide some means to override this behavior for both the enterprise and
individual deployment.

 

[Lanwench [MVP - Exchange]]

In

Thanks!! It appears that some sanity prevails. To me, this entire
controversy is summarized as follows.
1. In its perception of the users best interest, Microsoft should
block or unblock any attachments it so chooses as a default behavior
in its products.

And that's what it does.

2. In its pursuit of maximizing the user's productivity, Microsoft
should provide some means to override this behavior for both the
enterprise and individual deployment.

And they do.