552-5.7.0 でメールが受信できない現象はＺｉｐかも

添付ファイルがある場合、
先に、添付ファイルメールを送信して、その後で、そのファイルのパスワードを送信する、あるあるのパターンで、

 

パスワードのメールだけが受信されることがあります。

 

パスワードのメールだけ・・・？？受信側は困惑しますよね。
「あのお、パスワードだけ届いてるんですけど・・・」と電話

 

送信側の回答は、二通り

 

Ａ．あ、すみません、エラーで送れていません！
この場合のエラーメッセージは、相手がＧｍａｉｌだと

 

Ｂ．え？送れていますけど？
この場合は、受信側が、本来のサーバーからｇｍａｉｌ等のセキュリティー強化されている先に転送設定をしている場合で、契約サーバー上のメールを見ると、そのメールは受信されていて、その後でGmailに転送する際のエラーメッセージとして、上記のものが残っている。

 

なんですか？ 552-5.7.0？？これ？

 

私は、受信側なので、パスワードだけ届いている場合は、元のメールサーバーを見に行けば良いのですが、不便です。

このケースは、おそらく、Ｚｉｐファイルが二重になっている、というか、拡張子を変更したＺｉ_フォルダーだとしても、そのフォルダーの中にさらにフォルダーがあってその拡張子がＺｉｐとなっているので、セキュリティーの高い受信側ではブロックされたのだ、と思います。

 

メール送信の際に、自動的にファイルをＺｉｐ化パスワード生成する機能を使う場合、その前にファイルをＺｉｐにしていたら、添付ファイルの中にＺｉｐがあるということで、特にGmailでは受信することができないようです。

 

解決方法としては、そもそもＺｉｐ形式ではなく、個別ファイルにパスワードをかけて再送信することが一番簡単だと思うけれど、
送信側の規則・システム上、それはできない、ということであれば、
送信側では、そのまま裸の複数ファイルのままで自動機能を利用して、　「Ｚｉ＿　」ファイルの中に裸のPdfやワードファイルがそのまま入った状態で送信することなのでしょうか。

 

まあ、私の場合は、受信したものを転送して閲覧することが多いので、元サーバーを見に行けば良いだけなのですが・・・この原因にたどり着くまでには時間がかかりました。

とはいえ、パスワード付きＺｉｐファイルは、受信側にとっては怖いです。
拡張子が変更されて受信が可能となっても、受信側の恐怖は変わりませんので、事前通知なく添付メールが届いたら、その内容を電話で確認することになります。

 

便利なようで不便ですが、エモット恐怖の時代、受信側のリスクを避けるためには、コストもかからずに容易にできる防御策です。

 

私個人は、以前からＺｉｐ・いわゆるＰＰＡＰ廃止派です。大容量の資料をメールに添付することはありませんし、逆に、受信側もテレワークで解凍設備が無い場合や、スマホで受信される場合に、圧縮形式で添付したら怒られそうです。
エモットが社会問題にまで発展したことをきっかけに、私は、原則パス付Ｚｉｐを使用しない旨をお知らせしております。内容が重要な場合は、ＰＤＦファイル自体にパスワードをかけますので、不便はありません。

 

まあ、これだけＺｉｐ問題が騒がれている中で、しかもＺｉｐは使用しないと宣言をしている私から突然Ｚｉｐが送られてくることがあったら、異常事態が発生したと、クリック前に電話をいただけるはず、と思っております。