イノベーション エンジニアブログ 株式会社イノベーションのエンジニアたちの技術系ブログです。ITトレンド・List Finderの開発をベースに、業務外での技術研究などもブログとして発信していってます！
running-dog.net。しかし、自分が一番落ち着かない。かけまわっている子犬のような状態。そんな毎日をブログで綴ってみました。 FreeBSD・MacOSX・UNIX・PC・プログラム・iPhone(iOS)・Android ネタなど技術的・趣味的なネタについて色々書いてみたいと思います。 フツーに書くとタイトルがずいぶんと長いモノになってしまうのでタイトルは省きました。省かない場合のタイトルはどうなるだ？ というと・・。 「au の フィーチャーフォンで送受信している ezweb.ne.jp のメールを SoftBank の iPhone6 で送受信できるようにする。」 ってのが今回のお題目です。 僕的な携帯電話の環境は SoftBank の iPhone6 と au の GRATINA を持ち歩いています。 au の GRATINA はプラン SS と EZWeb を契約してい
AWSのSESを使ってメール配信を行っていると、時々Gmailのヘッダーに amazonses.com経由 と表示されます。 メールが別のメール サービス経由で送信されたことを示しています。つまり、送信者がサードパーティのメール サービスを使ってこのメールを作成した可能性があることを示しています。たとえば、ソーシャル ネットワーキング サイトのメール機能を使って送信されたメールや、登録しているメーリング リストから送信されたメールなどが考えられます。 Gmail でこの情報を表示する理由は、代理でメールを送信するサービスの多くで、送信者が指定した名前がメール アドレスと一致するかどうかの確認が行われないためです。Google では、知り合いを装ったメールからユーザーを保護しようと努力しています。 送信者名の横に詳細情報が表示される理由 - Gmail ヘルプ とまぁ、理由はこんな感じなんで
Quipper、日本オフィスができて半年以上達ち、このブログでも改めて色々発信してみようと思ってはいるのだけど、一度間が空いてしまったブログの再開はなかなか難しい(本人以外誰も気にしていない現実を知りつつ)。この状況を打破するために、軽いのをまず書いてみる。本当はQuipperの開発について色々書きたいんだけど、それはまた次回。 最近出会った mailtrap.io というサービスがWebシステム開発にとてもいい感じなので紹介してみる。 メール送信は、ある程度テストを自動化したとしても、繰り返し、手で実行して目で確認することも多い。テストするときは、送信先アドレスを自分にして、送信して、自分のメールボックスを開いて確認する、とか。めんどくさい。何か問題を発見したら、関係者にメールをフォワード、とかもめんどくさい。ステージング環境では実際に送らずに、ログに出すという方法もあるけど、これだと、
Did you ever get an email and wondered where it came from, or who really sent it? Surprisingly, a lot of that information can be obtained from the metadata in the email header. The header is a part of every email that most people never even see. It contains a ton of data that seems like gobbledygook to the average user. Besides, most email clients hide the metadata, often making it difficult to ac
Twitter / dnobori: ファイルをZIPで暗号化し、まずZIPをメールで送り、しばら ... https://twitter.com/dnobori/status/346488232537632768 Daiyuu Nobori ファイルをZIPで暗号化し、まずZIPをメールで送り、しばらくして別メールで8文字程度の乱数パスワードを送るという謎のプロトコルが日本企業で流行っているが、ZIPのパスワードは総当たりでかなり高速に解析できるし、そもそもパスワードをメールで送っているので効果が疑問。 僕も昔そのように送られてきて同じ疑問もったことあります。 はてブコメントみると、 2度送ることであて先ミスによる添付からの情報漏れを防ぐという効果はそこそこ期待できる。 誤送信による一撃死を免れるためのプロトコル。 まぁでも実際メールやFAXの誤爆とかよくある事なわけで。 暗号の強度では
Erlang の国内での活用事例として 1 時間あたり300万通のメール配信するメール配信サーバー というのがよく知られています。ですがこれ 1 秒あたりにすると 833 通なので一見全然凄くなさそうに見えます。 833 通ならスクリプト言語のスレッドでも十分に達成可能やで。 しかしメール配信の本質というのはそこではありません。国内においてメール配信とは携帯電話のキャリアメール宛てに行なうものです。携帯電話のキャリアメールには 同一 IP アドレスから大量にメールを送るとハネる 同一ドメインから送るとハネる とかそういうのがあります。それを越えるのは複数拠点（物理的な距離が離れている必要はありませんが要件上ネットワーク的な距離は離れることになります）に大量のマシンを用意しそれを連携してメールを送信する必要があります。 そういう環境で大量のマシンを連携させて一つのシステムとして動作させるには
Cronic A cure for Cron's chronic email problem By Chuck Houpt The Disease: 0 1 * * * backup >/dev/null 2>&1 The Cure: 0 1 * * * cronic backup Cronic is a shell script to help control the most annoying feature of cron: unwanted emailed output, or "cram" (cron spam). If the Unix Haters list was still active, I would submit the rant below to gain membership. (feedback to: chuck@habilis.net) The Disea
▼ [雑] メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる JANOG31 のページをつらつら見てたら気になるセッションがあった。 「メールアドレスの国際化(JANOG25からの変更点)」というものだ。（多用されているかはともかく）Web で使われるドメイン名では国際化が進んでいたけど、メールアドレスに関してはほとんど進んでいなかった印象だったのに、どうも RFC での標準化がほぼ完了したらしい。 セッションページからダウンロードできる「IETF 85 報告 DNS, 国際化関連」という資料を見てみたら、次のような記述があった。 ほとんどすべてのメールヘッダにUTF-8を許可 – メールアドレス部 <ローカルパート@ドメイン名> – Display-name, (コメント), SubjectヘッダにもUTF-8 (従来はMIME) 資料には具体例も記載さ
一つのGmailアドレスで出来る「登録制サイトのアカウントを複数取得する」３つの方法 2012 年 1 月 23 日 13 時 0 分 インターネット・IT アドレスの@のまえにピリオド入れたら別のアドレスと認識されるから他サイトで複垢量産するときに捗る。 たとえば、GMAILはnews@gmail.comとnews.@gmail.comってアドレスを同一のものだと認識する。ところが他のサイト、たとえばニコニコはnews@gmail.comとnews.@gmail.comってアドレスを別物だと認識する。だから一つのアカウントを用意しとけばいくらでも会員登録制の複垢を作れる。 ■どういうこと？ 具体的には、 「example@gmail.com」というアドレスを持っていた場合、 「exam.ple@gmail.com」でも、 「example…..@gmail.com」でも、
KDDIは12月6日、「○○@auone.jp」のメールアドレスを使ったWebメールサービス「au oneメール」を、来年9月30日に終了すると発表した。利用者が減少しているためという。新規申し込み受け付けは3月31日に終了する。 Googleと提携し、Gmailの機能をau向けにカスタマイズして提供していたサービスで、2007年にスタートした。保存容量は当初最大2Gバイト、現在は6Gバイトで、発表時には「100年分のメールを保存できる」とうたっていた。 サービス終了後は、au oneメールアドレスでのメール送受信や、送受信済みメールの確認ができなくなる。過去に送受信したメールをPCに保存したり、新規に受け取ったメールを別のメールアドレスに転送する方法は、Webサイトで案内している。 同社は来年上期、携帯メール（○○@ezweb.ne.jp）をPCでも利用できるようサービスを拡張するなど「
Is it time for password-less login? Logging in to web sites is ironically one of the most difficult tasks put before our users. Usernames and passwords are hard to remember, and harder than ever to type on the tiny on-screen keyboards of mobile devices. Even large, successful websites report that they receive an outsized number of support requests pertaining to login problems. We need something be
NoPassword means you don't need a password or a complicated OAuth scheme. Just email. Most web sites ask for a password when you register. After logging in, you can access the site until your session expires. When you forget your password, you can request an email with a link to a password change form. NoPassword factors out the password from this process. You register with an email address and re
シックス・アパートは、今年からUSで営業を再開しています。 現地採用のアメリカ人社員もおりまして、彼とこちらとの連絡方法はもっぱらメールです。 また、Movable Type の海外コミュニティや、アメリカ国内のパートナー企業とも日常的にやり取りを交わしています。 使う言語は、もちろん英語。 幸い、シックス・アパート社内には留学経験者や外資系企業経験者が多数いるので、英語でのコミュニケーションに困ることはあまりありません。 きちんと数えたわけではないですが、6〜7人に1人の割合で英語を使える社員がいる感じ。 一般的な企業よりは、英語力がある人の比率が高い気がします。 そこで、社内の英語が堪能な人たちから、「英文メールを書くときに注意していること」をヒアリングしてみました。 文章は、人間関係や、置かれた状況・立場等によって千変万化するものなので、「これが正解だ」と断言はできませんが、長年の経
IMAP Upload is a tool for uploading a local mbox file to IMAP4 server. The most stable way to migrate to Gmail. Read messages stored in mbox format which is used by many mail clients such as Thunderbird. Upload messages to IMAP4 server. Preserve the delivery time of the message. (support date time in From_ line / “Received:” field / “Date:” field) Automatic retry when the connection was aborted wh
CentOS 6.x で、yum の更新をメールでお知らせしてくれるようにする方法です。CentOS 5では、yum-updatesd で yum の更新をメールで通知するをご覧ください。 CentOS5 の yum-updatesd は CentOS 6 では yum-cron に変わっています。 インストール # yum install yum-cron 設定 初期設定では、更新通知ではなく自動でアップデートパッチを適用する設定となっています。これをチェックとダウンロードのみに変更します。 # vim /etc/sysconfig/yum-cron # yum コマンドで使用するパラメータ。特定のリポジトリを含めたり、除外するなど。 YUM_PARAMETER='--enablerepo rpmforge' # 初期設定では no になっているが、自動更新まではしないので yes に。
お仕事のやり取りでたまに遭遇しつつ気になっていたのが、メールでファイルをやり取りする際にパスワードを設定し、そのパスワードを「メールで別途送ります」というやりとり。ファイル開くのに手間がかかるばかりで、セキュリティ的にもさほど高いとはとても思えず、でもこのやり方がビジネス上時折発生するのを不思議に思っておりました。 そんなことをわーわー騒いでいたら周囲の人がいろいろ意見をいただいたのでこのエントリーで簡単にまとめ。とはいえ、今のところ「パスワードはメールで別途送ります」のメリットが全然見えてなかったりもするのですが……。 1.誤送信防止のため 「パスワードは別途送ります」の理由として最初に教えられたのがこれ。1通だと間違えて送ってしまった場合にやり直しが効かないけれど、2通に分けて送ることで誤送信を対処できるとの理由だったんですがこれがどうにも腑に落ちない。 そもそも「宛先を間違う」ことを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
