Google Mail and blocked attachments
little helper Perl-script
Subject:
Since Oct 24. 2017 I noticed changes in GMail behaviour on attachments.
What was the starting point?
Some years ago I had the requirement to send me or a colleague some
files. These files did include executables, which is impossible as
GMail attachment. Gmail blocks this for security reasons. I know that
there are other ways like Dropbox or other Cloud services. But in this
case e-mail was prefered for some reasons.
I'm working on Windows OS. So there may be better solutions under
Linux systems. The goal was to set up a script for comfortable
handling these mail attachments which means simple encrypting and
decrypting for sending in GMail. Also it should self set some
preferences as the destination filename in encrypting. And it should
recognize if it was an already encoded file on it's file-extension
(.b64). Besides this it further should cover and change known
file-extensions such as *.zip, *.bat, *.cmd, *.exe in replacing last
character with "_" (*.zi_ and so on). This did work fine with simple
base64 encrypting till the Oct 24 2017. The base64 encoded files could
be attached without any issues on a GMail e-mail.
What did happen? / What is the solution?
On the named date it did not work any longer. It seems Google did
recognize base64 encoded files. I thought on a simple solution to keep
the process running. The idea was that Google should not _see_ that it
was base64 .. and look into if there are zip's or executables. I
simply added a following ROT13 character shift in encoding. The
file-ext for encoding was set to *.b64.r13 .
The script runs with a Perl installation. On missing destination file
name it automatically sets an file-ext for destination. It recognizes
an already encrypted file on it's extension *.b64.r13 and does a
decode in this case. The base64 and ROT13-encoded files can be
attached without any difficulty to a GMail e-mail. The call on an
encrypted file does the reverse. The call of the Perl-script is done
with a batch-file wich should be able to found through PATH-variable.
An possibly overwrite is recognized and can be avoided.
The help message states:
Subject:
Since Oct 24. 2017 I noticed changes in GMail behaviour on attachments.
What was the starting point?
Some years ago I had the requirement to send me or a colleague some
files. These files did include executables, which is impossible as
GMail attachment. Gmail blocks this for security reasons. I know that
there are other ways like Dropbox or other Cloud services. But in this
case e-mail was prefered for some reasons.
I'm working on Windows OS. So there may be better solutions under
Linux systems. The goal was to set up a script for comfortable
handling these mail attachments which means simple encrypting and
decrypting for sending in GMail. Also it should self set some
preferences as the destination filename in encrypting. And it should
recognize if it was an already encoded file on it's file-extension
(.b64). Besides this it further should cover and change known
file-extensions such as *.zip, *.bat, *.cmd, *.exe in replacing last
character with "_" (*.zi_ and so on). This did work fine with simple
base64 encrypting till the Oct 24 2017. The base64 encoded files could
be attached without any issues on a GMail e-mail.
What did happen? / What is the solution?
On the named date it did not work any longer. It seems Google did
recognize base64 encoded files. I thought on a simple solution to keep
the process running. The idea was that Google should not _see_ that it
was base64 .. and look into if there are zip's or executables. I
simply added a following ROT13 character shift in encoding. The
file-ext for encoding was set to *.b64.r13 .
The script runs with a Perl installation. On missing destination file
name it automatically sets an file-ext for destination. It recognizes
an already encrypted file on it's extension *.b64.r13 and does a
decode in this case. The base64 and ROT13-encoded files can be
attached without any difficulty to a GMail e-mail. The call on an
encrypted file does the reverse. The call of the Perl-script is done
with a batch-file wich should be able to found through PATH-variable.
An possibly overwrite is recognized and can be avoided.
The help message states:
baserot.pl - Benutzung/Usage:
[perl] baserot.pl [-e|-d] [-o] (quelldatei/source) [(zieldatei/destination)]
-e encode (default)Project is on Github: https://github.com/toohoo/base64rot13
-d decode
-o overwrite existing
-h|help diese Hilfe/this help
ext(encode) = .b64.r13 (if no dest set)
source ext .b64.r13 = action: decode
Labels: attachment, gmail, googlemail, helper, perl, windows
0 Kommentare:
Kommentar veröffentlichen
Abonnieren Kommentare zum Post [Atom]
<< Startseite