EXE to TXT Coverter

  • Thread starter Thread starter Eduardo Hercos Rodrigues
  • Start date Start date
E

Eduardo Hercos Rodrigues

Hi,

Is there a freeware that converts EXE to "TXT" and "TXT" to EXE?
I would like to post a EXE file in the e-mail body, cheating by this way
servers that do not allow attachments.

Thank you very much
 
Eduardo Hercos Rodrigues said:
Hi,

Is there a freeware that converts EXE to "TXT" and "TXT" to EXE?
I would like to post a EXE file in the e-mail body, cheating by
this way servers that do not allow attachments.

Why don't you put it in a zip file? Or simply change the ".exe"
extension to ".txt"? The recipient only has to change it back to
".exe" to make it work...

Regards,
Wald
 
Rich_on 8-Sep-2005, Eduardo Hercos Rodrigues
Is there a freeware that converts EXE to "TXT" and "TXT" to EXE?
I would like to post a EXE file in the e-mail body, cheating by this way
servers that do not allow attachments.

It is possible but probably more trouble than it is worth. A small app
which will do the converting is UUd32win at http://www.marks-lab.com/ this
will UUencode/decode or even better yencode. Then it would be a copy and
paste job into the body of the email. The problem comes as to the size of
the resulting email. Traditionally an email was only 56 kb max, this has
largely gone out the window but your ISP still probably has some limit on
the size of an individual email so the encoded .exe file will have to be
split into usable parts - see pricelessware site for a file splitter, then
email each part emailed separately. This process would have to be reversed
at the receiving end. Essentially this is what a mail client does
automatically when posting binaries to a newsgroup.
This is my first thought on the subject and I am sure someone will come up
with one app. which does this for you. An alternative would be to FTP the
..exe file to one of the free file hosting organizations such as
www.rapidshare.de and email the link to the recipient
 
Hi,

Is there a freeware that converts EXE to "TXT" and "TXT" to EXE?
I would like to post a EXE file in the e-mail body, cheating by this way
servers that do not allow attachments.
Yes there is... it's called RENAME...

--
Venlig hilsen / Best regards
Thore Sorensen - DK2700 Brønshøj / DK2620 Albertslund

(Erstat evt. AT med @ i mailadressen hvis du mailer direkte)
Min hobbyside: www.RacePhoto.dk
 
Nope.. the rename won't work!!
I have tried sending .exe using gmail, and it would say illegal
attachment..

So.. I thought this rename would work, and I made a .bat file along
with it so that the user can rename it with ease as if he is installing
using a double click.

file named 'install.bat'
rename file_name.txt file_name.exe

but even as a text file, it recognized it, and said illegal
attachment.. I guess it previews the attachment, and not just by an
extension check!
 
Eduardo Hercos Rodrigues said:
Hi,

Is there a freeware that converts EXE to "TXT" and "TXT" to EXE?
I would like to post a EXE file in the e-mail body, cheating by this way
servers that do not allow attachments.


Hi ,

Do not have a link right now ,
try a search on the keyword "uuencode"
 
Nope.. the rename won't work!!
I have tried sending .exe using gmail, and it would say illegal
attachment..

So.. I thought this rename would work, and I made a .bat file along
with it so that the user can rename it with ease as if he is installing
using a double click.

file named 'install.bat'
rename file_name.txt file_name.exe

but even as a text file, it recognized it, and said illegal
attachment.. I guess it previews the attachment, and not just by an
extension check!
The same thing happens if you have a fn.exe file inside a fn.zip file,
however if you were to rename the fn.zip file to fn.zip.gma it will
accept the attachment, so maybe if you rename the fn.exe to fn.exe.gma
gmail will also accept that attachment.
 
Eduardo said:
Is there a freeware that converts EXE to "TXT" and "TXT" to EXE?
I would like to post a EXE file in the e-mail body, cheating by this way
servers that do not allow attachments.

WARNING: email messages are not always transmitted without change. Very
specifically, I had a major problem with text email last year: a line
starting with a "." sometimes had an extra "." prefixed, or showed a
couple of other problems. This happened intermittently with 3 different
ISPs. The cause of the problem is to do with SMTP transmission, which
sometimes needs to prefix an extra dot at one end, and remove it at the
other; bugs in the ISP's software cause this problem. (This is not a
full explanation; if anyone is interested in the details I can look up
some references).

With text messages this doesn't matter. I was obliged to use Outlook
Express to send database updates which OE insisted on sending in
quotable-printable (qp) format, instead of base64. This worked fine for
years, until we started having corruption. After much work we found that
the qp file being transmitted happened to have a "." after a CRLF, and
an extra "." was being prefixed. ISP's helplines were pathetic, refusing
to believe until overwhelming proof was suppled, then promising to look
into it and ... nothing.

If anyone wants to experiment, emailing the following text shows the
problem immediately, if present:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

12-line test message, ending with "End of test"
Following line has two dots, followed by end-of-line
...
Following line has five dots, followed by end-of-line
......
Following line has one dot. It is not the last line
..
Now some lines with leading dots:
..This line begins with one dot
...This line begins with two dots
This is the line before the last
End of test
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So don't use text email to send messages which must be received 100%
correctly (e.g., renamed executable files). It took us weeks to find why
our database was corrupting.


Best wishes,
 
rich said:
which will do the converting is UUd32win at http://www.marks-lab.com/ this

My apologies UUd32win is of course only a decoder.

Another app. is yenc32 - www.yenc32.com . This does encode and decode and
will also split the coded message into chunks. I used to use this to decode
newsgroup binaries a couple of years ago and from memory it was very good.

On possible to look at is peer2mail http://www.peer2mail.com/ . Not
tried this one but here is the blurb.
<quote>
Peer2Mail is the first software that let you store and share files on your
web-mail account. If you have a web mail account with large storage space,
you can use P2M to store files on it. Web-mail providers such as Gmail
(Google Mail), Walla!, Yahoo and more, provide storage space that ranges
from 100MB to 3GB.
P2M splits the file you want to share/store zips and optionally encrypts it.
P2M then sends the file segments one by one to your account. Once P2M
uploaded all file segments, you can download them and use P2M to merge the
segments back to the original file.
<unquote>
 
WARNING: email messages are not always transmitted without change. Very
specifically, I had a major problem with text email last year: a line
starting with a "." sometimes had an extra "." prefixed, or showed a
couple of other problems. This happened intermittently with 3 different
ISPs. The cause of the problem is to do with SMTP transmission, which
sometimes needs to prefix an extra dot at one end, and remove it at the
other; bugs in the ISP's software cause this problem. (This is not a
full explanation; if anyone is interested in the details I can look up
some references).

With text messages this doesn't matter. I was obliged to use Outlook
Express to send database updates which OE insisted on sending in
quotable-printable (qp) format, instead of base64. This worked fine for
years, until we started having corruption. After much work we found that
the qp file being transmitted happened to have a "." after a CRLF, and
an extra "." was being prefixed. ISP's helplines were pathetic, refusing
to believe until overwhelming proof was suppled, then promising to look
into it and ... nothing.

If anyone wants to experiment, emailing the following text shows the
problem immediately, if present:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

12-line test message, ending with "End of test"
Following line has two dots, followed by end-of-line
..
Following line has five dots, followed by end-of-line
.....
Following line has one dot. It is not the last line
.
Now some lines with leading dots:
.This line begins with one dot
..This line begins with two dots
This is the line before the last
End of test
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So don't use text email to send messages which must be received 100%
correctly (e.g., renamed executable files). It took us weeks to find why
our database was corrupting.


Best wishes,

If you're trying to drive us dotty it didn't work here. All dots
appear as described.
 
fr.comp said:
Hi ,

Do not have a link right now ,
try a search on the keyword "uuencode"

and I throw out any .exe file that is attached to an e-mail because
it may be a virus.
 
Very Funny!

So, let's see if I've got this:
The server won't allow a .txt attachment, but it will allow an .exe
attachment?

Now, guess what I do with unexpected attachments that are .exe files,
and why. It's important to know this.

Richard
 
I wrote about corruption of email by prefixed spurious dots, and
included the content of a test file.

David responded:
If you're trying to drive us dotty it didn't work here. All dots
appear as described.

I've never had dot corruption in a Usenet posting, only in email. I'm
100% certain it did happen intermittently with at least 3 ISPs. They
were the only 3 I was using for qp-encoded data; I would expect it's
quite a common occurrence, but usually harmless.

This only really matters if added dots are a problem. It doesn't affect
attachments using binary (base64, etc.) encoding, as the binary encoding
formats don't use the dot character, specifically to avoid this type of
problem.

Best wishes,
 
Richard said:
So, let's see if I've got this:
The server won't allow a .txt attachment, but it will allow an .exe
attachment?

Now, guess what I do with unexpected attachments that are .exe files,
and why. It's important to know this.

Richard

I would expect that the OP wants to automatically, without user
intervention: rename "MYPROG.EXE" to "MYPROGEXE.TXT"; send this file as
an attachment, which won't be rejected by any email program; at the
receiving end, rename back to "MYPROG.EXE". Presumably the recipient is
a party to all this, and knows that the file is from a trusted source.

The idea of getting round email programs' rejection of EXE files is not
necessarily bad; I often send non-computer-literate users who are set up
to accept them EXE files (often self-extracting archives) with text like
"here is the update you phoned me about last Friday; just open it from
this message. Please don't open this type of file if you're not 100%
sure it's from me". I expect others will point out the risks; but it
works for me.

But I don't think renaming to .TXT is a good idea.

Best wishes,
 
Michael said:
I wrote about corruption of email by prefixed spurious dots, and
included the content of a test file.

David responded:



I've never had dot corruption in a Usenet posting, only in email. I'm
100% certain it did happen intermittently with at least 3 ISPs. They
were the only 3 I was using for qp-encoded data; I would expect it's
quite a common occurrence, but usually harmless.

This only really matters if added dots are a problem. It doesn't affect
attachments using binary (base64, etc.) encoding, as the binary encoding
formats don't use the dot character, specifically to avoid this type of
problem.

Best wishes,
Go review the RFCs that discuss SMTP.

You will find that it is actually a problem with some (mainly Microsoft)
MUAs.

They don't do the well-defined and well-known and, frankly, old, thing
when it comes to lines that start with a '.'.

Sigh.

That said, over the years I've seen that many variations on corruption
of transmitted files that I insist that anything which is not pure ASCII
be either zipped or preferably tar'red and the gzip'ped.

Cheers,
Gary B-)
 
I wrote about corruption of email by prefixed spurious dots, and
included the content of a test file.

David responded:

I've never had dot corruption in a Usenet posting, only in email. I'm
100% certain it did happen intermittently with at least 3 ISPs. They
were the only 3 I was using for qp-encoded data; I would expect it's
quite a common occurrence, but usually harmless.

This only really matters if added dots are a problem. It doesn't affect
attachments using binary (base64, etc.) encoding, as the binary encoding
formats don't use the dot character, specifically to avoid this type of
problem.

Best wishes,

Thanks, Michael. I have never experienced the problem so I cannot
assist you further.
 
Go review the RFCs that discuss SMTP.

You will find that it is actually a problem with some (mainly Microsoft)
MUAs.

They don't do the well-defined and well-known and, frankly, old, thing
when it comes to lines that start with a '.'.

Sigh.

That said, over the years I've seen that many variations on corruption
of transmitted files that I insist that anything which is not pure ASCII
be either zipped or preferably tar'red and the gzip'ped.

Cheers,
Gary B-)

You didn't mention the feathers. ;-)}}}
 
David wrote, re email corruption:
Thanks, Michael. I have never experienced the problem so I cannot
assist you further.

I wasn't asking for help, but pointing out a non-obvious pitfall!

The only workaround (if you are forced to send vulnerable files via an
ISP to be received with POP3) is to use a responsive ISP, and phone them
when the problem occurs. With an unresponsive ISP, you're stuffed.

Thanks for the message pointing out that the cause is usually an MUA
problem.

Best wishes,
 
Back
Top