Is there a way to configure Outlook 2007 to download headers and
bodies of emails with attachments but not download the attachments?
When needing to use a dial-up connection, having this ability will
allow reading emails but not tie up the connection for hours
downloading the attachments.

Thanks!
--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

System Administrator wrote:

> Is there a way to configure Outlook 2007 to download headers and
> bodies of emails with attachments but not download the attachments?
> When needing to use a dial-up connection, having this ability will
> allow reading emails but not tie up the connection for hours
> downloading the attachments.
> 
> Thanks!

Not possible.  Attachments are not floating around in the cyber ether
without being *in* the e-mail.  All attachments are IN the body of an
e-mail.  They are MIME parts in the body of the e-mail which your e-mail
client presents as "attachments".  All e-mail gets sent as text.  All of it.
Doesn't matter if it is RTF, HTML, or plain text format or if it has
attachments or not.  Attachments get encoded into long strings of text (and
why their size bloats by 137%, or often much more, when you add them).

If you only download the e-mail's headers then you only get that information
and nothing of the body of the e-mail.  If you download the body of the
e-mail, you get all of the body and that includes the MIME parts containing
the encoded text strings for the attachments.

Tell your senders to stop being rude.  Senders should not be trying to use
e-mail as a file transfer mechanism.  They should save the files somewhere
in online storage and include a link to it in their e-mail.  

You can configure Outlook to download only the headers for e-mails that
exceed some configured maximum size.  However, that means you will need to
manually mark which large e-mails you want to download and then either wait
until the next mail poll to get them or manually instigate a mail poll to
get them now.  It's a pain in the butt and means you're acting stupid
because someone else wants you to.  Tell the sender you won't accept their
e-mails if they exceed, say, 50KB in size.  If they want to give you those
huge files, have them give a link to it.

You can set Outlook to download headers only if the message is larger than x 
KB.
Tools-> Options-> tab Mail Setup-> button Send/Receive-> button Edit

You cannot exclude attachments from the message body as they are actually 
part of it. So it is pretty much all or nothing ;-)

-- 
Robert Sparnaaij [MVP-Outlook]
Coauthor, Configuring Microsoft Outlook 2003
http://www.howto-outlook.com/
Outlook FAQ, HowTo, Downloads, Add-Ins and more

http://www.msoutlook.info/
Real World Questions, Real World Answers

-----

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in 
message news:2m3pn51ge1fppb3040tqa9j8fj5mciripc@4ax.com...
> Is there a way to configure Outlook 2007 to download headers and
> bodies of emails with attachments but not download the attachments?
> When needing to use a dial-up connection, having this ability will
> allow reading emails but not tie up the connection for hours
> downloading the attachments.
>
> Thanks!
> --
> System Administrator
> Sprotte + Watson Architecture and Planning
> Vista, CA 

Thanks, to both respondents.  I was aware of the download headers only
facility and the ability to set a message size limit for download.  I
was also aware of attachments being MIME encoded and contained in the
message body.  I was hoping that there was a way to exclude the MIME
content of the message body from the downloading since that section of
the body is clearly coded as being MIME encoded content and, I
believe, follows all other message content in the body.

Oh, well!  So much for that idea.  Thanks for your responses.

Seems to me that would be a nice addition to the POP3 protocol
structure.

On Wed, 17 Feb 2010 16:53:34 -0800, System Administrator
<sysadmin.removethis@sprottewatson.com> wrote:

>Is there a way to configure Outlook 2007 to download headers and
>bodies of emails with attachments but not download the attachments?
>When needing to use a dial-up connection, having this ability will
>allow reading emails but not tie up the connection for hours
>downloading the attachments.
>
>Thanks!

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

On Wed, 17 Feb 2010 22:26:08 -0800
System Administrator <sysadmin@sprottewatson.com>
articulated:

> Thanks, to both respondents.  I was aware of the download headers only
> facility and the ability to set a message size limit for download.  I
> was also aware of attachments being MIME encoded and contained in the
> message body.  I was hoping that there was a way to exclude the MIME
> content of the message body from the downloading since that section of
> the body is clearly coded as being MIME encoded content and, I
> believe, follows all other message content in the body.
> 
> Oh, well!  So much for that idea.  Thanks for your responses.
> 
> Seems to me that would be a nice addition to the POP3 protocol
> structure.

I sincerely hope that no moron takes your suggestion seriously. An
implementation of that sort would surely break GPG signatures, not to
mention DKIM, etc.

A more favorable solution would be for you to obtain a different
Internet connection.

-- 
Carmel	|::::=======
	|::::=======
	|===========
	|===========
	|

I was not aware my suggestion might break usages of MIME encoded
content for purposes other than message attachments.  Perhaps these
other usages could be identified differently than attachments and the
"filter" that I'm suggesting act only on attachment encoded content.

Alas!  Not all of us are fourtunate enough to live in an area served
by affordable high speed Internet service.  I presently have a T1 at
my home location which costs my landlord $470 per month.  He has
decided to drop the service due to the cost.  DSL and cable TV service
are not available at my address.  From pervious experience with
satellite Internet, its reliability is not all that great and
obtaining requires committing to a 2-year contract.  So, I will be
relegated to having to use a dial-up service which only achieves
25Kbps.


On Thu, 18 Feb 2010 06:38:11 -0500, Carmel <carmel_ny@hotmail.com>
wrote:

>On Wed, 17 Feb 2010 22:26:08 -0800
>System Administrator <sysadmin@sprottewatson.com>
>articulated:
>
>> Thanks, to both respondents.  I was aware of the download headers only
>> facility and the ability to set a message size limit for download.  I
>> was also aware of attachments being MIME encoded and contained in the
>> message body.  I was hoping that there was a way to exclude the MIME
>> content of the message body from the downloading since that section of
>> the body is clearly coded as being MIME encoded content and, I
>> believe, follows all other message content in the body.
>> 
>> Oh, well!  So much for that idea.  Thanks for your responses.
>> 
>> Seems to me that would be a nice addition to the POP3 protocol
>> structure.
>
>I sincerely hope that no moron takes your suggestion seriously. An
>implementation of that sort would surely break GPG signatures, not to
>mention DKIM, etc.
>
>A more favorable solution would be for you to obtain a different
>Internet connection.
>
>-- 
>Carmel	|::::=======
>	|::::=======
>	|===========
>	|===========
>	|
>

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in 
message news:4b7d901d.580586171@msnews.microsoft.com...

>I was not aware my suggestion might break usages of MIME encoded
> content for purposes other than message attachments.  Perhaps these
> other usages could be identified differently than attachments and the
> "filter" that I'm suggesting act only on attachment encoded content.
>
> Alas!  Not all of us are fourtunate enough to live in an area served
> by affordable high speed Internet service.  I presently have a T1 at
> my home location which costs my landlord $470 per month.  He has
> decided to drop the service due to the cost.  DSL and cable TV service
> are not available at my address.  From pervious experience with
> satellite Internet, its reliability is not all that great and
> obtaining requires committing to a 2-year contract.  So, I will be
> relegated to having to use a dial-up service which only achieves
> 25Kbps.

Do you have cell phone service in your area?  Unlinited data plans are not 
nearly $470 per month.  You should be able to pick up a USB cell modem and a 
data plan for your use.
-- 
Brian Tillman [MVP-Outlook] 

Thanks for the suggestion.  I have a Verizon Wireless phone and
coverage at my address.  Their data plan is $70 month with a 5GB
limit.  I believe I would run over that limit almost every month.  The
overage charge is $0.05 per MB thus making that service potentially
expensive as well.  But, it might be my only choice for "high speed"
service.


On Thu, 18 Feb 2010 14:37:57 -0500, "Brian Tillman [MVP-Outlook]"
<tillman1952@yahoo.com> wrote:

>"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in 
>message news:4b7d901d.580586171@msnews.microsoft.com...
>
>>I was not aware my suggestion might break usages of MIME encoded
>> content for purposes other than message attachments.  Perhaps these
>> other usages could be identified differently than attachments and the
>> "filter" that I'm suggesting act only on attachment encoded content.
>>
>> Alas!  Not all of us are fourtunate enough to live in an area served
>> by affordable high speed Internet service.  I presently have a T1 at
>> my home location which costs my landlord $470 per month.  He has
>> decided to drop the service due to the cost.  DSL and cable TV service
>> are not available at my address.  From pervious experience with
>> satellite Internet, its reliability is not all that great and
>> obtaining requires committing to a 2-year contract.  So, I will be
>> relegated to having to use a dial-up service which only achieves
>> 25Kbps.
>
>Do you have cell phone service in your area?  Unlinited data plans are not 
>nearly $470 per month.  You should be able to pick up a USB cell modem and a 
>data plan for your use.
>-- 
>Brian Tillman [MVP-Outlook] 
>

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

System Administrator wrote:

> I was not aware my suggestion might break usages of MIME encoded
> content for purposes other than message attachments.  Perhaps these
> other usages could be identified differently than attachments and the
> "filter" that I'm suggesting act only on attachment encoded content.
> 
> Alas!  Not all of us are fourtunate enough to live in an area served
> by affordable high speed Internet service.  I presently have a T1 at
> my home location which costs my landlord $470 per month.  He has
> decided to drop the service due to the cost.  DSL and cable TV service
> are not available at my address.  From pervious experience with
> satellite Internet, its reliability is not all that great and
> obtaining requires committing to a 2-year contract.  So, I will be
> relegated to having to use a dial-up service which only achieves
> 25Kbps.
> 
> On Thu, 18 Feb 2010 06:38:11 -0500, Carmel <carmel_ny@hotmail.com>
> wrote:
> 
>>On Wed, 17 Feb 2010 22:26:08 -0800
>>System Administrator <sysadmin@sprottewatson.com>
>>articulated:
>>
>>> Thanks, to both respondents.  I was aware of the download headers only
>>> facility and the ability to set a message size limit for download.  I
>>> was also aware of attachments being MIME encoded and contained in the
>>> message body.  I was hoping that there was a way to exclude the MIME
>>> content of the message body from the downloading since that section of
>>> the body is clearly coded as being MIME encoded content and, I
>>> believe, follows all other message content in the body.
>>> 
>>> Oh, well!  So much for that idea.  Thanks for your responses.
>>> 
>>> Seems to me that would be a nice addition to the POP3 protocol
>>> structure.
>>
>>I sincerely hope that no moron takes your suggestion seriously. An
>>implementation of that sort would surely break GPG signatures, not to
>>mention DKIM, etc.
>>
>>A more favorable solution would be for you to obtain a different
>>Internet connection.
>>
>>-- 
>>Carmel	|::::=======
>>	|::::=======
>>	|===========
>>	|===========
>>	|
>>

Technical solutions cannot compensate for user stupidity.  You know the real
problem, and that is your senders are the morons for trying to use e-mail as
a file transfer mechanism for which is was not designed.  The solution is
telling your senders to stop being rude by sending oversized e-mails.  As I
stated before, have them store their files in online storage and provide a
*link* to it in their message.

When you get a memo from your secretary about a missed call, do you expect
to get an encyclopedia-sized memo?  No, you expect to get a short note with
some critical information.

Below is my typical canned response to some boob that wants to use e-mail
for file transfers.

----------

E-mail is NOT a reliable file transfer mechanism.  It wasn't intended or
designed for that.  It was designed to send lots of small messages.  There
is no CRC check on the file to ensure integrity.  There is no resume to
re-retrieve the file if the e-mail download fails.  There is no guarantee
the e-mail will arrive uncorrupted.  Large e-mails can generate timeouts and
retries due to the delay when anti-virus programs interrogate their content.  

Do not use e-mail to send large files.  It is rude to the recipient.  Not
every recipient might want your large file.  Not every recipient has
high-speed broadband Internet access.  Many users still use slow dial-up
access, especially if all they do is e-mail.  You waste your e-mail
provider's disk space and their bandwidth to send a huge e-mail.  You waste
the e-mail provider's disk space and bandwidth at the recipient's end.  You
eat up the disk quota for the recipient's mailbox (which could render it
unusable so further e-mails get rejected due to a full mailbox).  You
irritate users still on dial-up that have to wait eons waiting to download
your huge e-mail. Some users have usage quotas (i.e., so many bytes/month)
and you waste it with a file that they may not want.  Don't be insensitive
to recipients of your e-mails.  Take the large file out of the e-mail.

Save the file in online storage and send the recipient a URL link to the
file.  Your e-mail remains small.  It is more likely to arrive.  It is more
likely to be seen.  The recipient can decide whether or not and when to
download your large file.  Be polite by sending small e-mails. 

Your ISP probably allows many gigabytes of online storage for personal web
pages.  Upload your file there and provide a URL link to it.  Other methods
(of using online storage), all free, are: 

http://www.adrive.com/              (50GB max quota, 2GB max file size) 
http://www.driveway.com/            (500MB max file size) 
http://www.filefactory.com/         (300MB max file size) 
http://www.megashares.com/          (10GB max file size) 
http://www.sendspace.com/           (300MB max file size) 
http://www.spread-it.com/           (500MB max file size) 
http://www.transferbigfiles.com/    (1GB max file size) 
http://zshare.net/                  (500MB max file size) 
http://www.zupload.com/             (500MB max file size) 

If it is sensitive content and when storing it online in a public storage
area or to guard it against whomever operates the online storage service,
remember to encrypt it.

I agree.  I have instructed the employees at SWAP not to send emails
larger than 2MB and to use the FTP server for large file or groups of
files distribution.  However, SWAP has some clients, consultants, and
contractors that are not very computer savy and don't know how to use
FTP.  Thus, some large files must be sent via email.  However, that is
rare.

Personal correspondents are an entirely different matter.  Some can be
instructed as you say and may comply, but not all.  It is just too
easy to forward an item received, not even knowing or caring how large
it is, to a group of correspondents.  Having to save the item and then
placing it into an online depository would just be too much effort.


On Thu, 18 Feb 2010 18:16:16 -0600, VanguardLH <V@nguard.LH> wrote:

>System Administrator wrote:
>
>> I was not aware my suggestion might break usages of MIME encoded
>> content for purposes other than message attachments.  Perhaps these
>> other usages could be identified differently than attachments and the
>> "filter" that I'm suggesting act only on attachment encoded content.
>> 
>> Alas!  Not all of us are fourtunate enough to live in an area served
>> by affordable high speed Internet service.  I presently have a T1 at
>> my home location which costs my landlord $470 per month.  He has
>> decided to drop the service due to the cost.  DSL and cable TV service
>> are not available at my address.  From pervious experience with
>> satellite Internet, its reliability is not all that great and
>> obtaining requires committing to a 2-year contract.  So, I will be
>> relegated to having to use a dial-up service which only achieves
>> 25Kbps.
>> 
>> On Thu, 18 Feb 2010 06:38:11 -0500, Carmel <carmel_ny@hotmail.com>
>> wrote:
>> 
>>>On Wed, 17 Feb 2010 22:26:08 -0800
>>>System Administrator <sysadmin@sprottewatson.com>
>>>articulated:
>>>
>>>> Thanks, to both respondents.  I was aware of the download headers only
>>>> facility and the ability to set a message size limit for download.  I
>>>> was also aware of attachments being MIME encoded and contained in the
>>>> message body.  I was hoping that there was a way to exclude the MIME
>>>> content of the message body from the downloading since that section of
>>>> the body is clearly coded as being MIME encoded content and, I
>>>> believe, follows all other message content in the body.
>>>> 
>>>> Oh, well!  So much for that idea.  Thanks for your responses.
>>>> 
>>>> Seems to me that would be a nice addition to the POP3 protocol
>>>> structure.
>>>
>>>I sincerely hope that no moron takes your suggestion seriously. An
>>>implementation of that sort would surely break GPG signatures, not to
>>>mention DKIM, etc.
>>>
>>>A more favorable solution would be for you to obtain a different
>>>Internet connection.
>>>
>>>-- 
>>>Carmel	|::::=======
>>>	|::::=======
>>>	|===========
>>>	|===========
>>>	|
>>>
>
>Technical solutions cannot compensate for user stupidity.  You know the real
>problem, and that is your senders are the morons for trying to use e-mail as
>a file transfer mechanism for which is was not designed.  The solution is
>telling your senders to stop being rude by sending oversized e-mails.  As I
>stated before, have them store their files in online storage and provide a
>*link* to it in their message.
>
>When you get a memo from your secretary about a missed call, do you expect
>to get an encyclopedia-sized memo?  No, you expect to get a short note with
>some critical information.
>
>Below is my typical canned response to some boob that wants to use e-mail
>for file transfers.
>
>----------
>
>E-mail is NOT a reliable file transfer mechanism.  It wasn't intended or
>designed for that.  It was designed to send lots of small messages.  There
>is no CRC check on the file to ensure integrity.  There is no resume to
>re-retrieve the file if the e-mail download fails.  There is no guarantee
>the e-mail will arrive uncorrupted.  Large e-mails can generate timeouts and
>retries due to the delay when anti-virus programs interrogate their content.  
>
>Do not use e-mail to send large files.  It is rude to the recipient.  Not
>every recipient might want your large file.  Not every recipient has
>high-speed broadband Internet access.  Many users still use slow dial-up
>access, especially if all they do is e-mail.  You waste your e-mail
>provider's disk space and their bandwidth to send a huge e-mail.  You waste
>the e-mail provider's disk space and bandwidth at the recipient's end.  You
>eat up the disk quota for the recipient's mailbox (which could render it
>unusable so further e-mails get rejected due to a full mailbox).  You
>irritate users still on dial-up that have to wait eons waiting to download
>your huge e-mail. Some users have usage quotas (i.e., so many bytes/month)
>and you waste it with a file that they may not want.  Don't be insensitive
>to recipients of your e-mails.  Take the large file out of the e-mail.
>
>Save the file in online storage and send the recipient a URL link to the
>file.  Your e-mail remains small.  It is more likely to arrive.  It is more
>likely to be seen.  The recipient can decide whether or not and when to
>download your large file.  Be polite by sending small e-mails. 
>
>Your ISP probably allows many gigabytes of online storage for personal web
>pages.  Upload your file there and provide a URL link to it.  Other methods
>(of using online storage), all free, are: 
>
>http://www.adrive.com/              (50GB max quota, 2GB max file size) 
>http://www.driveway.com/            (500MB max file size) 
>http://www.filefactory.com/         (300MB max file size) 
>http://www.megashares.com/          (10GB max file size) 
>http://www.sendspace.com/           (300MB max file size) 
>http://www.spread-it.com/           (500MB max file size) 
>http://www.transferbigfiles.com/    (1GB max file size) 
>http://zshare.net/                  (500MB max file size) 
>http://www.zupload.com/             (500MB max file size) 
>
>If it is sensitive content and when storing it online in a public storage
>area or to guard it against whomever operates the online storage service,
>remember to encrypt it.

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

System Administrator wrote:

> I agree.  I have instructed the employees at SWAP not to send emails
> larger than 2MB and to use the FTP server for large file or groups of
> files distribution.  However, SWAP has some clients, consultants, and
> contractors that are not very computer savy and don't know how to use
> FTP.  Thus, some large files must be sent via email.  However, that is
> rare.
> 
> Personal correspondents are an entirely different matter.  Some can be
> instructed as you say and may comply, but not all.  It is just too
> easy to forward an item received, not even knowing or caring how large
> it is, to a group of correspondents.  Having to save the item and then
> placing it into an online depository would just be too much effort.

Some of the online solutions that I provided are extremely simply and
require just a few clicks and key taps.  If your senders can't figure out
how to use those sites, they also don't know how to flush a toilet.  You'll
have to decide if you want them leaving turds in your toilet or stop
inviting them over to your place.