My outlook outbox is stuck on send

[meowsicat]

I think I asked my outlook to send a file that was too big. It has been
stuck "sending" for 24 hours now and I can not delete it, stop it or do
anything with it. Any ideas?

 

[VanguardLH]

I think I asked my outlook to send a file that was too big. It has been
stuck "sending" for 24 hours now and I can not delete it, stop it or do
anything with it. Any ideas?

Delete an item stuck in the Outbox folder:
- Load Outlook.
- Put Outlook in offline mode (File -> Work Offline: enable).
- Exit Outlook.
- Load Outlook in its safe mode ("outlook.exe /safe").
- Delete the stuck item in the Outbox folder. If you don't want the
item to move into the Deleted Items folder, use Shift+Del to
permanently delete the item.
- Put Outlook in online mode (File -> Work Offline: disable).
- Restart Outlook in its normal mode.

E-mail is NOT a reliable file transfer mechanism. It wasn't intended or
designed for that. 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.

Stop using 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 recipient's e-mail provider disk space and bandwidth. 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. Stop
being rude. 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.

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.rapidupload.com/ (300MB 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.

 

[M]

E-mail is NOT a reliable file transfer mechanism.

Horsepucky. I have been using email to send/receive small and large
attachments for over 12 years and not one has arrived corrupted or
otherwise different than when it was sent.

M

 

[Peter Foldes]

Horsepucky

You are plain wrong or very lucky.

 

[M]

Horsepucky

You are plain wrong or very lucky.

Peter

No such thing as luck in file transfers via email. It either works or it
doesn't. I have conducted this "test" for over 12 years and you have
tested nothing.

M

Horsepucky. I have been using email to send/receive small and large

attachments for over 12 years and not one has arrived corrupted or
otherwise different than when it was sent.

 

[VanguardLH]

Horsepucky. I have been using email to send/receive small and large
attachments for over 12 years and not one has arrived corrupted or
otherwise different than when it was sent.

Where is the CRC check to ensure the contents have not been corrupted?
Where is the resume function if the e-mail transfer errors?

No one is going to cite or care about your sole experience as a
precedent on defining the operation of e-mail. What worked for you has
no bearing on how the e-mail protocol is defined or how messages are
tranferred.

 

[M]

Where is the CRC check to ensure the contents have not been corrupted?
Where is the resume function if the e-mail transfer errors?

No one is going to cite or care about your sole experience as a
precedent on defining the operation of e-mail. What worked for you has
no bearing on how the e-mail protocol is defined or how messages are
tranferred.

12 years of flawless transfers (both receiving and sending) isn't enough
for you to classify it as a scientific experiment? If so, I have
nothing more to say to you or Peter.

M

 

[Bob I]

12 years of flawless transfers (both receiving and sending) isn't enough
for you to classify it as a scientific experiment? If so, I have
nothing more to say to you or Peter.

Congratulations, I and most of people I know that use e-mail have not
had any where near that kind of luck.

 

[M]

Congratulations, I and most of people I know that use e-mail have not
had any where near that kind of luck.

Note, I only send Word and image files. Occasionally I send MP3s.

M

 

[VanguardLH]

Note, I only send Word and image files. Occasionally I send MP3s.

Oh, I thought your 12-year claim was for you both sending and RECEIVING
e-mails laden with attachments (and by omission would means ALL types of
attachments). Did anyone here ever claim that you couldn't reliably
*send* e-mails with attachments (as long as you are within the quotas
established for your e-mail account)? Your mail server accepts whatever
it gets during the DATA command. It doesn't care if that data has been
corrupted. It won't know. It doesn't care. None of that data sent
during DATA has anything to do with routing your e-mail. Your client
send RCPT-TO command to specify the recipients and then sends DATA to
transfer whatever you want as the content of your message (your client's
headers, blank delimiter line, and body). The mail server doesn't care
about what is the data but that's what it going to deliver. When you
hand off a package to the UPS or FedEx, do they actually tear apart your
package to inspect the contents are all what you claimed they would be?
No, they take the entire package and deliver whatever is inside to the
addressee.

Sending is not a problem (outside of the mail session errors between the
client and mail server, like exceeding quotas for max size for an e-mail
- but then you never did get to send that e-mail so e-mail as reliable
file transfer mechanism isn't an issue yet). The focus is on RECEIVING
e-mails with attachments, especially for large-sized e-mails. Your
reliability in sending has nothing to do with the reliability in
reception. I can toss china plates out a 20-story window and they'll be
in pristine condition as they go out the window but they won't be
delivered in that same condition.

Your experience is of sending 15KB to 150KB Word files attached to puny
sized e-mails compared with others that are sending 10MB to 20MB, or
even larger, e-mails. Tiny e-mails have a far greater chance of not
getting truncated, altered (by AV scanners), or having bits corrupted
during transfer than for e-mails that are 600 to 1200 times, or more,
larger in size. The entire e-mail protocol and system was designed for
transferring SMALL messages and that's why you've had such good luck.
It was NOT designed as a file transfer scheme for huge files. You
trying to carry a teaspoonful of water in your cupped hand will work
well. You trying to carry a cupful of water in your two cupped hands
pressed together doesn't work nearly as well and there is far more
chance of spillage so what you deliver isn't what you started with.

 

[M]

Oh, I thought your 12-year claim was for you both sending and RECEIVING
e-mails laden with attachments (and by omission would means ALL types of
attachments). Did anyone here ever claim that you couldn't reliably
*send* e-mails with attachments (as long as you are within the quotas
established for your e-mail account)? Your mail server accepts whatever
it gets during the DATA command. It doesn't care if that data has been
corrupted. It won't know. It doesn't care. None of that data sent
during DATA has anything to do with routing your e-mail. Your client
send RCPT-TO command to specify the recipients and then sends DATA to
transfer whatever you want as the content of your message (your client's
headers, blank delimiter line, and body). The mail server doesn't care
about what is the data but that's what it going to deliver. When you
hand off a package to the UPS or FedEx, do they actually tear apart your
package to inspect the contents are all what you claimed they would be?
No, they take the entire package and deliver whatever is inside to the
addressee.

Sending is not a problem (outside of the mail session errors between the
client and mail server, like exceeding quotas for max size for an e-mail
- but then you never did get to send that e-mail so e-mail as reliable
file transfer mechanism isn't an issue yet). The focus is on RECEIVING
e-mails with attachments, especially for large-sized e-mails. Your
reliability in sending has nothing to do with the reliability in
reception. I can toss china plates out a 20-story window and they'll be
in pristine condition as they go out the window but they won't be
delivered in that same condition.

Your experience is of sending 15KB to 150KB Word files attached to puny
sized e-mails compared with others that are sending 10MB to 20MB, or
even larger, e-mails. Tiny e-mails have a far greater chance of not
getting truncated, altered (by AV scanners), or having bits corrupted
during transfer than for e-mails that are 600 to 1200 times, or more,
larger in size. The entire e-mail protocol and system was designed for
transferring SMALL messages and that's why you've had such good luck.
It was NOT designed as a file transfer scheme for huge files. You
trying to carry a teaspoonful of water in your cupped hand will work
well. You trying to carry a cupful of water in your two cupped hands
pressed together doesn't work nearly as well and there is far more
chance of spillage so what you deliver isn't what you started with.

Good to know, thanks.

M