imgburn question

[Default] On Tue, 8 Mar 2016 15:51:19 -0600, in
microsoft.public.windowsxp.general VanguardLH wrote:

Paul wrote on 2016/03/08:

Encryption is your friend :-(

Not sure if you meant that as a joke, especially since you next describe
how to use encryption (not for privacy but to circumvent automatic
scanning of e-mail content).

I don't think my friend woudl have been able to handle unencryption.
And though it appears now that the length of the file was not the
problem, I doubt he would have been able to handle putting a
multi-part file back together.

https://support.google.com/mail/answer/6590

"File types that can't be sent or received

.exe ...

Aha. Thank you, Paul.

.zip ...
"

In other words, they don't want you sending malware.

Your response makes it appears that Google will not permit sending or
receiving both .exe and .zip files. They will block executable
filetypes, like .exe, but .zip is allowed; however, it is an archive
format so they can peek inside to check its payload. What they actually
said was:

You can't send or receive the following file types:

.ade, .adp, .bat, .chm, .cmd, .com, .cpl, .exe, .hta, .ins, .isp,
.jar, .jse, .lib, .lnk, .mde, .msc, .msp, .mst, .pif, .scr, .sct,
.shb, .sys, .vb, .vbe, .vbs, .vxd, .wsc, .wsf, .wsh

A better list. Thank you, Van.

I had jumped to the conclusion that length was the problem because I
felt guilty sending such a long file. (even though I'd done it
before.)

Messages containing the types of files listed above will be bounced
back and returned to the sender automatically. Gmail won't accept
these file types even if they're sent in a zipped format. Here are
some examples of zipped formats:

.zip, .tar, .tgz, .taz, .z, .gz, .rar

That does not say they do anything more than check what filetype(s) are
stored within a .zip file. They don't even indicate that they inspect
the content of an attached .exe file. Extracting an attachment would
take a lot of processing power. Looking for the text strings that
identify the filetype for a MIME part for the attachment is easy, quick,
and very low-powered. So it seems all you need to do is rename the
attachment from .exe to .exx or to whatever filetype you want and tell
the recipient to rename the attached file (after extracting it) to the
correct extension. That's an old trick to get around e-mail providers
that block MIME parts (attachments) in e-mails in a blocklist.

Rename the executable file from .exe to .exx or .com to .cmm.
Then attach the renamed file to your e-mail.
Tell the recipient to rename the extracted file.

And that's what I did. I waited some to see if I'd get another bounce
notice.

I'm not positive he can even rename a file, but that seems the easiest
for him and he hasn't called me.

Thanks, and thanks everyone.

Micky wrote:

VanguardLH wrote:

Paul wrote:

Encryption is your friend :-(

Not sure if you meant that as a joke, especially since you next
describe how to use encryption (not for privacy but to circumvent
automatic scanning of e-mail content).

I don't think my friend woudl have been able to handle unencryption.
And though it appears now that the length of the file was not the
problem, I doubt he would have been able to handle putting a
multi-part file back together.

I never mentioned slicing a file into parts. Encryption/decryption
handled by e-mail clients is automatic (after you install a cert).
Encryption is by invite: you would send a digitally signed e-mail to
your friend who saves you in their contact list (so your public key gets
saved) and if they want to send you an encrypted e-mail then they use
their contact to use your public key to encrypt their e-mail.

Get a cert (no more difficult than registering to use a web forum),
install the cert, configure to always digitally sign your outbound
e-mails. Done. Those who get your e-mail can decide if they encrypt
their e-mails sent to you. If they want you to send them encrypted
e-mails, they get a cert and digitally sign their outbound e-mails.

The digital signature includes your public key. Anyone can use it to
encrypt e-mails they send to you but only you have the private key to
decrypt. No having to someone provide an alternate method than e-mail
to give someone a password for a password-encrypted e-mail. Paul's
method (that carries the password along with the encrypted e-mail)
wasn't really to secure your encrypted e-mail but to circumvent typical
automated interrogation by your e-mail provider. Even if not using
Paul's method, how hard can it be for someone to receive your e-mail
with an encrypted .zip file attached and given the password in the
unencrypted body of your e-mail? They would have to extract your
attached file, anyway, and when they attempt to unzip they get asked for
the password which you gave them in your e-mail.

I had jumped to the conclusion that length was the problem because I
felt guilty sending such a long file. (even though I'd done it
before.)

Although you might assume the recipient has an always-on broadband
Internet connection, there are still users that use dial-up. Plus not
everyone wants their account's disk quota used up with big e-mails. It
can take just one huge e-mail to eat up the remaining disk quota which
results in that account rejecting any further incoming e-mails. They
get a huge e-mail and then their account goes dead until they delete
that huge e-mail (retrieving it into a local e-mail client may not
[immediately] delete it).

It is considered polite to keep e-mails small. Besides the above
problems, it lets the recipient get their e-mails more quickly (their
e-mail client will appear more responsive). In e-mail, there is no
resume feature. There is no check on the validity of attachments (that
they have not been corrupted) - unless you encrypt your e-mail (AND do
*not* use an e-mail provider that appends spam tags onto your outbound
e-mails since that is corruption and the recipient will get notified
that your encrypted e-mail got altered). E-mail was never intended nor
designed as a file transfer protocol. Put the large file on [free]
online storage, encrypted if it contains sensitive data, and send the
hyperlink to the file via e-mail, with a password if the file was
encrypted, so the recipient (not you) can decide if and when they will
retrieve the big file.

Rename the executable file from .exe to .exx or .com to .cmm. Then
attach the renamed file to your e-mail. Tell the recipient to rename
the extracted file.

And that's what I did. I waited some to see if I'd get another
bounce notice.

I'm not positive he can even rename a file, but that seems the
easiest for him and he hasn't called me.

How old is this recipient? Kids 4 years and older and my 78-year old
aunt have no problems using e-mail, clicking on links, or entering a
password when prompted. You cannot get around someone, any age, that
has decided to refusie using computers or are technophobes.

In message , Micky
writes:
[Default] On Tue, 8 Mar 2016 15:51:19 -0600, in
microsoft.public.windowsxp.general VanguardLH wrote:
[]
And that's what I did. I waited some to see if I'd get another bounce
notice.

Have you heard whether he's got it yet?

I'm not positive he can even rename a file, but that seems the easiest
for him and he hasn't called me.

The F2 key is probably the easiest way.

Thanks, and thanks everyone.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Charity sees the need not the cause. -German proverb

[Default] On Tue, 15 Mar 2016 20:07:52 +0000, in
microsoft.public.windowsxp.general "J. P. Gilliver (John)"
wrote:

In message , Micky
writes:
[Default] On Tue, 8 Mar 2016 15:51:19 -0600, in
microsoft.public.windowsxp.general VanguardLH wrote:
[]
And that's what I did. I waited some to see if I'd get another bounce
notice.

Have you heard whether he's got it yet?

No, but the two bounce notices I got before (for 2 different reasons)
came within 2 hours, and it's been over 2 days.


I'm not positive he can even rename a file, but that seems the easiest
for him and he hasn't called me.

The F2 key is probably the easiest way.

Good point. He hasn't called yet.

Thanks, and thanks everyone.