More from: 電子メール

EdMaxで添付ファイルがデコードできない

フリーのメーラー「EdMax Free」を使っていて時折添付ファイル付きのメールのデコードが出来ないことがある。
先日もその件で相談を受けたのだけど、見るときちんとデコードされず本文中にエンコードされた文字列が並んでいる。
ファイル名の文字コードがutf-8となっているので、探して見付けた「EdMimeDecode」というプラグインを試したが結果は変わらず。
うーん、どうしたものか・・・

この「EdMimeDecode」というプラグインはメール本文の表示時に動作し、改行コードがCR+LF以外(CRのみorLRのみ)の場合にはCR+LFに変換してMailbox中に書き戻してくれるようでその際にちょっと動作が重くなるが、改行無し(に見える)メールがきちんと改行されて読みやすくなるので、その点では有効だと思われる。

←クリックしてくれると嬉しいです。

誤送信かよ・・・

ユーザーが「メールアドレスを間違って送信してしまったが、エラーが返ってきていない」と言って来た。
メールサーバーのログを確認するとステータスは”Sent”になっていた。
つまり無事に送信出来たということで一見問題無いように思えるが、実は大問題orz。
タイプミスしたメールアドレスが実在して本来の受信者とは別の人のアドレス宛にメールが送られたということだ。
送信してから20時間以上も経っているし、そもそも送信の取り消しは出来ないから”無かったこと”には出来ない。
さて、どうするか・・・(汗)

←クリックしてくれると嬉しいです。

まだ送信エラーになる?

先週末にGmailのアドレス宛のメールがようやく送られるようになったが、logを見ていて今日になってもまだエラーが出ているのを見つけた。
まだどこか設定が足りないところがあるのか?と思って焦ったが、エラーの種類が違っていて私の方では手の施しようが無かった(汗)。
エラーは
「452-4.2.2 The email account that you tried to reach is over quota.」と
「550-5.1.1 The email account that you tried to reach does not exist.」
の二つ。
上は相手先のサーバーの空き容量が足りないというエラーで一時的なもので相手に受信メールを削除して貰うなりして空き容量を確保して貰うか、送るメールに付けている添付ファイルの量を減らすかの対策が必要。
下は相手先のアドレスが存在しないという永続的なものなので、送信者が間違ったアドレスを指定していると思われるのでアドレスの再確認&訂正が必要。
と言うわけで、セキュリティ絡みでのエラーでは無いので一安心だな(汗)。

←クリックしてくれると嬉しいです。

なんとかなった・・・かな?

Gmail宛にメールが送れなくなっていた件はサーバーを弄ってDKIM対応にしたところなんとか解決した・・・と思われる。
設定作業自体は難しいものではないんだけど、なにせ初めてだったので設定ファイルの弄り方が良く判らず、いろんなサイトを参考にしながら作業した。
途中で参考にしたサイトの設定ファイルの内容が正しく無かったり、他人がやってくれた部分に修正ミスがあったりで手間取りはしたが、なんとかGmail側に弾かれずにメールが届くようになったと思われる。
少なくとも自分の持っているGmailのアドレス宛に送ったメールのヘッダーを見る限りSPF認証もDKIMも”PASS”となっているので大丈夫かな。
一番困っていたユーザーさんも無事にメールを送ることが出来た(maillogでもstatusが”sent”になった)ので、これで安心して明日は休めそうだ(汗)。

←クリックしてくれると嬉しいです。

Gmailは厳しくなったなぁ、、、

ユーザーがGmail宛にメールを送ったが必ずエラーになって送れないと連絡してきた。
先日までは時折エラーにはなるものの、再送することで送れていたが、今週に入ってからは全く送れなくなったとのこと。
サーバーのログを見るとGmail側からヘッダーに異常があるとして弾かれている。
試しに別のメールソフトを使って送信してみると辛うじて送信され相手先のアドレスに届くのだが、
「Gmail では、このメールが本当に xxxx.yy.zz から送信されたものであることを確認できませんでした。」
との警告付きで、ヘッダーを見るとSPF認証に失敗している。
DNSサーバーでのSPFレコード設定はしてあるものの、送信元サーバーが何故か別のIPアドレスになっているので、そのために認証できないと思われる。
さらにDKIMに対応していないので、先ずはDKIMに対応させるべくサーバーを弄っている最中(汗)。
これでなんとか解決できれば良いんだけどなぁ(汗)。

←クリックしてくれると嬉しいです。

メールボム攻撃を受けた

ユーザーから「メールを受信したら途中で止まってしまう」との連絡が来た。
部下がリモートで入って見ると確かにメール受信が最後の1通の所でとまってしまう。
もしかして大容量メールが来たのかと思ってサーバー側を見ると50MB以上のファイルを添付したメールが来ていたorz。
ユーザーからは削除して良いと言われていたので問答無用で削除したが、問題は同じメールが他のアカウント宛にも来ていたことで、それら宛も全て削除した。
業者からのメールだったんだけど、相手の迷惑も考えずに送ってくる業者(の一担当者)だし、必要ではないデータらしいので今後は出してこないで欲しいなぁ・・・
やっぱり一通当たりの容量制限を復活させようかなぁ・・・

←クリックしてくれると嬉しいです。

メールの配送漏れ?

ユーザーから昨日届くはずのメールが届いていないとの連絡があった。
なんでも特定の時間帯のメールが少なくて、ちょうどその時間帯に送られたメールがあるけどPCで受信できないとのこと。
”そんな筈は・・・”と思ってサーバーのログを見ると届いていない筈のメール(送信元のアドレス等で判断)は配信されたことになっている。
/var/spool/mail下にあるスプールを見てもちゃんと入っている(後で気付いたがこの時点で勘違いしていた)。
そこで自分のPCで同じアカウントを設定して受信させてみると受信できない(ユーザー側は一定期間サーバーに残す設定にしてあるので私のところでも受信できる筈)。
スプールにあるのに受信できない原因を探している途中で気付いたが、このサーバーはpostfixでmaildir形式で構築してあり、先のスプールファイルには配信されずユーザー毎のディレクトリ(~/Maildir下)に配信される筈だった(汗)。
とにかく受信できないメールをなんとか受信出来るようにするのが先決なので色々調べてformailコマンドで配信することにして実行したところ、今度は
: mail forwarding loop for hoge@hogehoge.dom
というエラーメールがrootに送られてくるだけで配送されない。
ループになるような原因としてはaliases以外に考えられなかったので/etc/alisesファイルを何度も修正し、最後には転送設定を削除までしたが結果は変化しないorz。
となると転送設定の問題では無いだろうということでエラーメッセージでググるとヒントが見つかった。
それは送られてきたメールヘッダーの
Delivered-To:
に受信者と同じメールアドレスの記述があるとMTA(postfix)がメールループだと判断してしまうということらしい。
なぜDelivered-To:に同じアドレスが入っているかを調べる時間が勿体ないので、とにかくスプールファイルを直接(もちろんバックアップを取ったうえで)編集し、Delivered-To:に書かれているアドレスを若干変更して保存。
そうした後にformailコマンド
# formail -s sendmail -v -t -oiee < ./hoge を実行したところ無事にmboxに配信された。 あとは特定の時間帯にだけこの現象が起きた原因を探らなければ(汗)。

←クリックしてくれると嬉しいです。

”サーバーを介しているから遅くなる”?

ユーザーが業務用のメールのことを電話で話していて、その会話の中で「ウチはサーバーを介しているから受信まで多少時間がかかる」と言っていた。
いや、あの、今の電子メールって必ずメールサーバーを介するんだけど(呆)。
サーバーから端末にプッシュ配信される携帯のキャリアメールだって同じくサーバーを介してやり取りをしているんだけどなぁ・・・
今はサーバー同士の通信にかかる時間はそれほどなく、受信までにかかる時間はPCのメールソフトが定期的にサーバーからメールを受け取る間隔に左右される程度なんだけどねぇ(汗)。
電子メールが一般的になってからずいぶん経つけど、大まかな仕組みを知らなくても使えてしまうからなぁ、、、

←クリックしてくれると嬉しいです。

誰が付けた?

某コンピューター販売会社(元SONY)からの営業メールのタイトルに”[SPAM]”と付いていた。
送信側が付ける筈も無いので、私が使っているPCのセキュリティ対策ソフトが付けたのだろうけど、根拠も無く付けるわけが無いからSPAMの発信元としてRBLとかに登録されたのかな?(笑)

←クリックしてくれると嬉しいです。

またメールか・・・

ユーザーの偉いさんからまたまたメールに関して言ってきた。
今度はとある従業員が自分宛てに出したメールがエラーになって返ってしまい、自分に届かないので調べて欲しいとのことだ。
その”とある従業員”のところにどんなエラーが返っているのかを知らないと原因は判らないが、生憎と外出中でPCを見て貰うことも見せて貰うことも出来ない。
仕方が無いのでメールサーバーのログを調べてみても、その人から偉いさん宛てに送信されたメールの形跡が見当たらないorz。
しばらくしたら戻って来たので問題のエラーメールを見せて貰うとすぐに解決(というか原因判明)。
メールサーバーはローカル用とグローバル用の2台を利用していて、お互いの間で送受信は出来ないようにしてある。
ところが”とある従業員”はローカル用サーバーを使ってグローバルのメールアドレス宛に出そうとしていたので、smtpサーバーが”そんなドメインは知らない”とエラーを返していたわけだ。
判ってみれば単純なミスだったけど、先日はグローバルのメールに関してトラブったので今回もそっちかと思っていてローカルのサーバーをチェックする考えは無かったよ(汗)。

←クリックしてくれると嬉しいです。