たまにSPAMメールを振り分けているフォルダを見るのだけど、久々に見ると差出人が「スイス銀行」というメールがあった（笑）
知っての通り「スイス銀行」という銀行は実在しないんだけど、それを騙るとはアホな送信者だねぇ。
More from: メール
←クリックしてくれると嬉しいです。
mailboxが満杯だなんて（苦笑）
現場から「メールを送ったらエラーで返ってきた。」との連絡があった。
エラーの内容はエラーメールに書かれていることが多いので読み上げて貰ったがあまり要領を得ないので転送して貰った。
届いたエラーメールを見るとエラーの内容は
maildrop: maildir over quota.
550 5.0.0 <個人名@組織名.com>… Insufficient permission
というもので、これは相手のメールボックスが満杯で配信出来ないというものだ。
ドメインは相手の組織の独自ドメインなので、プロバイダの容量制限とかではなくレンタルサーバとかで独自に設定した制限（もしくはシステムの制限：Linuxのsendmailでは1ファイル2GB）と思われる。
つまり送った相手はメールを受信していないか、受信してもサーバからメールを削除していないかのどちらかだと思われる（またはメールボムを喰らった可能性も）。
受け取れるようにして欲しくてもメールでは連絡できないし、しばらくは放置かな？（苦笑）
あとは管理者のアドレスを調べて通知するとかだけど、そこまでする必要があるかなぁ？
←クリックしてくれると嬉しいです。
こんなので引っかかる人がいると思っているんだろうか？
とあるメールアドレス宛に”楽天銀行”を騙るメールが来た。
以下はそのヘッダと本文
Return-Path:
Delivered-To: hoge@hogehoge.jp
Received: (qmail 6540 invoked by uid 6021); 24 Jul 2013 12:51:22 +0900
Delivered-To: hoge@hogehoge.jp
Received: (qmail 6538 invoked for bounce); 24 Jul 2013 12:51:22 +0900
Received: from unknown (HELO re02.leadsrv.com) (219.235.31.143)
by 0 with SMTP; 24 Jul 2013 12:51:22 +0900
Received: from ist.jp.net (unknown [114.112.20.228])
by re02.leadsrv.com (Postfix) with ESMTP id E35E3815E7
for
Received: from localhost (server175 [127.0.0.1])
by ist.jp.net (Postfix) with ESMTP id 9A7066A0326
for
Date: Wed, 24 Jul 2013 12:50:41 +0900 (JST)
From: 楽天銀行
To: hoge@hogehoge.jp
Message-ID: <3359379.157608231374637841633.JavaMail.root@server175>
Subject: [楽天銀行]出金が完了致しました。
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
[楽天銀行]出金が完了致しました。
[メッセージをみる]
http://ocmes.info/xxx.yyy.zzz
[マイページ]
http://ocmes.info/xxx.yyy.zzz
[換金をする]
http://ocmes.info/xxx.yyy.zzz
メーラで見ると差し出し人（From:）が楽天銀行となっているが、アドレス（ドメイン）が全く違うので誰が見ても本物とは思えないと思う。
未だにこんなメールを出して引っかかる人がいると思っているんだろうか？
それとも未だに引っかかる人がいるんだろうか？
そのままではアクセス出来ないように、引用したメールのヘッダ内の受け取り側のメールアドレス、本文中のURLは加工しているが、差出人のほうは無加工（笑）
←クリックしてくれると嬉しいです。
三日前に出したメールがようやく・・・・・・
先週末に踏み台にされたサーバがようやく通常の状態に復旧した模様。
日曜日の昼間に出したメールが今日の未明になってようやく届いていたので、大量に滞留していたメールの処理がようやく終わったものと思われる。
いやぁ、久々に大きなトラブルだったなぁ、、、、、、、
←クリックしてくれると嬉しいです。
拡張子「.dat」のファイルが添付されたメールが来た
ユーザーから
「お客さんから来たメールに添付されてきたファイルの拡張子が.datなんだけど、どうやったら開けるのか？」
という問い合わせが来た。
正直に
「送って来たお客さんにどのソフトで作ったファイルなのか問い合わせてください。」
と答えておいた（笑）。
だって、「.dat」という拡張子だけでは判断が付かないからねぇ。
話の内容では添付ファイルは画像データとのことなので、一度ファイルを保存して拡張子を変更すれば見れるかもしれないけどね。
ググって見るとマイクロソフトのOutlookとかOutlookExpressでリッチテキスト形式で作られたメールを非対応のメールソフトで受信すると拡張子が「.dat」のファイルが添付されたように見えることもあるそうだけど、もしそうならプレーンテキスト形式で送りなおしてもらわないと駄目だし、それなら最初からファイルの中身を教えてもらった方が早い。
全く迷惑なソフトを作ってくれる会社だなぁ・・・・・・・・
添付されてきたファイルの名前が「Winmail.dat」なら、「Winmail Opener」というフリーソフトで開けるかも？
ググッたらダウンロードサイトがあった→「Winmail Opener 1.4 日本語版 無料 ダウンロード- Jp.Downpanda.com」
←クリックしてくれると嬉しいです。
「,」（カンマ）と「.」（ピリオド）
「メールを送ろうとするとエラーが出るんですけど？」
という問い合わせが来た。
部下が対応したが原因は送信先のメールアドレス中にある「.」（ピリオド、ドットと呼ばれることも多い）が全て「,」（カンマ）になっていたのとのこと。
ところが問い合わせてきた当人はそれらの区別が付いていないという・・・・・・
おっかしいなぁ、こんなの中学校の英語の授業で最初の内に習うはずなんだけどねぇ（苦笑）。
結局「尻尾付きの点」「尻尾の無い点」という区別の仕方を教えて解決した。
小学生じゃ無いんだから、この程度の知識は持っていて欲しいものだよ。
←クリックしてくれると嬉しいです。
メーラーがハングするなんて・・・・・・
職場のPCの一台が特定のメールを受信するとメーラが止まってしまい受信が完了しない状況になった。
タスクマネージャで見るとメーラーのプロセスがCPUを100%近くまで使っている。
CPU負荷が多少変動することと、時折HDDのアクセスランプが点滅しているところを見ると完全にはハングしているわけでは無さそうだが、何分待っても処置が終わる気配が無い。
メールサーバ側のログを見るとpopログインはするもののログアウトはしていない（メーラー自身が処理を終了していないので当たり前だが）。
試しに他のPCで他のメーラーを使って問題のメールを受信してみると添付ファイルの数が129個もあった（汗）。
恐らく受信後に添付ファイルの分割＆保存処理に異常に時間がかかっているものと思われ、実際に受信動作させたまま放っておいたらその内に受信処理が終わっていた。
＃後でサーバ側のログを見てみるとpopログインからログアウトまで9分以上もかかっていた。
PC自体のスペックが低いこともあるが、ソフトの作りにも問題が有るのかもしれないな。
それにしても129個もファイルを付けて送ってくるなんてねぇ、、、、、、、、新手の業務妨害の手段なのか？（笑）
←クリックしてくれると嬉しいです。
今回は２千通弱だった
時々頼まれてサーバ上に残してあるメールを削除しているが、今日は約２ヶ月振りにやることになった。
いつもは先方から依頼されて実行するのだが、今回はこちらから削除が必要かどうかを尋ねたところ、
「是非やって欲しい！」
と言われた。
それだけならいつものように
fetchmail -Fv
で取得済みのメールを削除するのだけれど、今回は
「古いのだけを消して貰えないか？」
と言われてしまった。
ところが-Fvオプションを付けてfetchmailを実行すると、サーバ上にあるメールのほぼ全てを削除してしまうので、それは出来ないと答えた。
まぁそれでも良いとのことだったので早速実行して２千通弱のメールをサーバ上から削除した。
ヘッダー形式がRFCに則っていない数通が取得されずにサーバ上に残ってしまったが、全てSPAMだったのでnPopを使って削除した（先に「ほぼ全て」と書いたのはこのようなメールが残るため）。
後から考えたら.fetchidsファイルを加工してから実行すればサーバ上にメールを残すことが出来るかな？と思ったが、.fetchidsに書かれていないメールは再取得されるだけなので、やはり選択的にメールを削除するのは困難だということに気付いた。
うーん、なんか良い方法は無いかなぁ？
←クリックしてくれると嬉しいです。
メールが送れない って・・・・・・・
「メールの送信が”おかしい”んですけど？」
という問い合わせ。
どんなエラーが出てますか？と訊くと、
「消しちゃったので判りません」
とのこと。
エラーの内容が判らなければ対処のしようも無いので再度送信を試してもらい、出たメッセージを読んでもらうと送信時のメールサイズオーバーが原因と判明した。
ファイルを4つ添付していて、全部で20MB弱ということなので1つずつ送れば大丈夫かと思ったが、4つの内二つがそれぞれ8MBと10MBとのこと。
おいおい、そんな大きなのを送ったら相手にも迷惑だろ？と思ったけど、とにかく小さくして送って下さいなということをお願いした。
そうすると圧縮の方法が判らないとのこと、、、、、、、
結局メンバーの1人を現地に行かせて対応することにした。
一昨日はこちらがメールボムを食らったが、今度は相手にメールボムを送ることになるところだったよ・・・・
現在の回線環境を考えると10MB単位のメールでも送受信に時間がかからないから、特に目くじらを立てる必要も無いのかもしれないけど、出来るだけ小さくするのがマナーじゃないのかな？
それともこんなことを思う自分が古いのかなぁ？
←クリックしてくれると嬉しいです。
久々にメールボムを喰らった・・・・・・・
「同じメールが何通も繰り返し届くんだけど、なんかおかしくない？」
という問い合わせが来た。
調べてみると3MB～10MB弱のメールが数通届いていて、それをfetchmailで代行受信しようとしてタイムアウトを起こしていた。
問題のアカウントはfetchmailのオプションでタイムアウト時間（-t）を指定していなかったので、デフォルトの300秒では全てを受信できなかったようだ。
タイムアウトを起こすのでサーバ側のメールを削除しないものだから、何度も同じメールを受信してしまっていた。
早速サーバ側に残っている大きなサイズのメールを削除し、fetchmailのタイムアウト時間も延ばしておいたから、しばらくは大丈夫かな？
それにしても以前から無駄に大きなファイルを添付してくる業者だったけど、また業務妨害をしてくるなんてなぁ、、、、、いっそのこと受信拒否をかけてやろうか？（爆）
←クリックしてくれると嬉しいです。