ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク
SIOS "OSSよろず"ブログ出張所はサイオスが新たにオープンしました「SIOS Tech.Lab」ブログに移設します。 新サイトのURLは下記となります。引き続きのご愛読をよろしくお願いします。 https://tech-lab.sios.jp/ サイオステクノロジー 鎌田です。今回は Postfix で SPF 認証に対応する方法について紹介したいと思います。 SPF でググると、一番トップに来るのは Sun Protection Factor (紫外線防御指数) の話が出てきますが、今回の話はもちろん Sender Policy Framework のことです。 SPF を一言で表すとなりすましを防止する技術の一つですが、詳細な説明は以下の URL が詳しいです。 なりすましメール撲滅に向けたSPF（Sender Policy Framework）導入の手引き http://www
名前¶ Email::Valid::Loose - アットマークの前にドットを許す Email::Valid 概要¶ use Email::Valid::Loose; # same as Email::Valid my $addr = 'read_rfc822.@docomo.ne.jp'; my $is_valid = Email::Valid::Loose->address($addr); 説明¶ Email::Valid::Loose is a subclass of Email::Valid, which allows . (dot) before @ (at-mark). It is invalid in RFC822, but is commonly used in some of mobile phone addresses in Japan (like docomo.ne.
UTF-8で作成されたメール本文をMIME::Lite及びEncodeを使用してメールを送信をする。 そこで問題となってくるのが下記の3点。 １．チルダ（全角）等の文字化け（"〜 ‖ − ¢ £ ¬ "） ２．機種依存文字が含まれていた場合の対応 ３．MIME::Lite で smtp送信する場合、Return-Pathが有効にならない 1.チルダ（全角）等の文字化け（"〜 ‖ − ¢ £ ¬ "）に関する解決方法： これは有名らしいのですが、Encode::JPが採用している UnicodeConsortium の写像表 に問題があるとかで、 一部の文字が化けます。チルダとか。 しようがないので こんな風に対応しておきました。 my %map = ( "\x{ff5e}" => "\x{301c}", # 〜 (1-33, WAVE DASH) "\x{2225}" => "\x{201
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く