こんにちは、VASILYバックエンドエンジニアの塩崎です。 社会人2年目にも突入し、優秀な後輩たちに抜かされないかと日々ひやひやしています。 さて、今回は1ヶ月程前に完了した、メールサーバーのSendGrid移行について紹介したいと思います。 移行のきっかけ そもそも、なぜVASILYでメール配信の自社管理をやめてクラウドサービスであるSendGridに移行する必要がでたのでしょうか？ 以前から使用していたpostfixサーバーではなぜダメだったのでしょうか？ それは、大量のメールマガジンを遅延なく配信する必要が生じたからです。 昨年の11月頃からiQONでは、ユーザーさん一人一人にオススメのアイテムを送る、リコメンドメルマガを開始しました。 それにあたり、数万人のユーザーさんに対してそれぞれ内容の少しずつ異なるメールを送る必要が出ました。 このような処理を自社管理のpostfixサーバー
コマンドライン上でGmail(smtp.gmail.com)にアクセスしてメール送信してみる。 サイトで検索してみるとやり方は見つかるが上手く動かない記事が多かったのでメモしてみる。 telnetコマンドではなくopenssl s_clientコマンドを使います。 SMTPアカウント情報は以下の場合とする。 ユーザー: test@gmail.com パスワード: abcde12345 SMTPサーバー: smtp.gmail.com 認証時にユーザー/パスワードをBase64エンコードしたものが必要になるのであらかじめ用意しておく。 フォーマットは「\000{ユーザー}\000{パスワード}」となり、エンコードにはサクッとprelを利用する。 $ perl -MMIME::Base64 -e ‘print encode_base64(“\000test\@gmail.com\000abcd
2011年2月21日(月) ■ st とか ly とか _ うちで使っている .st という TLD って DNSSEC 対応するつもりあるんだろうか、と調べてみたんだけど、どうなんだかわからんかった。それはともかく、調べてるうちにサントメ・プリンシペという国についてまったく何も知らないことに今さらながら気がついた。 _ 島国だというのは知ってたのでカリブ海あたりの中米の小国かなと思ってたんだけど、ぜんぜんそうではなく、西アフリカらしい。で、 ここを見てみると、サントメ・プリンシペに割り当てられた IPv4 アドレスの数は、ゼロ…。なんつーか、いろいろ申し訳ない気持ちになった。.st ドメインって実はけっこう高いんだけど(取得したときは酔ってたのでそんなことはぜんぜん考えてなかった)、このうちどのくらいの額がスウェーデンのレジストリ運営会社にピンハネされることなくサントメ・プリンシペ本国に
2011年2月1日(火) ■ ちょっとトイレットペーパー買い占めてくる _ 一般向けの記事も出てるぐらいなんで別にいまさら書く必要もない気がせんでもないが、自分が後で思い出したくなったときのためにメモ。 _ ipv4 がめでたく売り切れました。厳密にはまだ /8 が5個残ってるけど、これは RIR に自動的に分配される分なので、おばちゃんおかわり、と言ってもごめんねーごはんもうないんだわ、となる。 _ 最後のおかわりは、大方の予想どおり APNIC に2ブロック。この APNIC の在庫も年内には枯渇するはず。ほとんど中国が使っちゃうのかなー。 _ 2003年8月の記事。 RIR exhaustion of the unallocated address pool would occur in 2022. 2003年の時点で、RIR の枯渇が2022年の予想。文中では言及されてないけど、
after:2006/03/31 before:2006/04/1 ※世界標準時。日本の日付とズレる。
－不用意なセキュリティ対策がトラブルの種に－ この記事では、現役のメールサーバ管理者が体験したさまざまな「ヒヤリハット体験」を紹介していく。中には「トホホ」な事例も含まれているが、セキュアで安定したメールサーバの運用を実現していく際の手助けになれば幸いだ。 佐藤潔、内田雅生、飯村直弘、加藤雅彦 2008/3/3 子供から高齢者まで、ありとあらゆる人が普通に使うコミュニケーションメディアとなった感のある電子メールだが、それを配送するメールサーバの運用についていえば、やはりプロの仕事であり、そう間単な作業ではない。そこには、利用者からはうかがい知れない、涙ぐましい努力が隠れていたりするのだ。 この記事では、現役のメールサーバ管理者が体験したさまざまな「ヒヤリハット体験」を紹介していく。中には、原因が分かってみればあっけないトラブルやケアレスミスに起因する「とほほ」な事例もあるが、それだけに、現
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
● postfix でメールのバックアップ 今どこらへんかと言うと、Pマーク取得がマイブームの上司から、会社で利用する受信メールのバックアップ依頼が来た。要件および背景はこんな感じ。 ● 要件 全てのユーザの受信メールをバックアップする バックアップの目的はデータの二重化でなく、会社の記録としての受信メール保管 会社は各ユーザを信じないものとする (＝各ユーザは都合の悪い私用メールを消しうる) 特定の管理者は各ユーザの過去全ての受信メールをチェックできる 過去メールのチェックはユーザ単位で指定することができる (管理者ごとに参照できるユーザが決まる) 保存期間は5年とか10年とかの結構長いスパン 各ユーザが利用するMUAは Outlook 系 この要件6およびメールの退避と復元を容易にするためにも、 Mailbox 形式でなく Maildir 形式にする という要件も必然的に追加されるだろ
qmail のダブルバウンスのお話。元は postfix-jp ML に投げた質問。 そもそもダブルバウンスって何？ qmail のダブルバウンスのどこが問題なの？ じゃあどうすればいいの？ まとめ そもそもダブルバウンスって何？ これは初心者向けではなく、メールサーバ管理者を対象に書いているつもりなので、いちおう解説はするが、手短に済ませる。知っていれば読み飛ばし可。知らなければ恥じること。 宛先メールアドレスが存在しないとか宛先サーバ障害で長期間配送できないとかいう場合、メールは送っても届かない。届かないのでメールシステムが「届けられなかった」というメールを送信元に送る。このメールは一般的にはエラーメールと呼ばれることが多いが、メール屋の専門用語では「バウンス」と呼ぶ。 バウンスメールの特徴としては、どこか他から送られてくるのではなく、メールシステム自身が送信するメールであるということ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
