サービス側にメールアドレスを公開しない方法を調べた(Firefox Relay や 1Password + Fastmail のお話)

[2021-08-07-1] にデフォルトブラウザを Firefox に変えて、3 ヶ月くらい続いている。 昔と違って、基本的な使い勝手や見た目は Chrome と違いがない。当たり前だけど Chrome と比べて良い点も悪い点もある。総合的に割と良い選択をしたと思っている。※ 変化できないことやロックインされることを、最近極端に恐れるようになった事情あり。 なにかの通知で Firefox Monitor から、自分のメールアドレスやパスワードの流出を確認できることを知った。1Password でも出来るやつね。 その Firefox Monitor 経由で Firefox Relay も知った。リリース当時のニュースは見ていたと思うので、「思い出した」が正確だと思うけど。 無料でアカウント作成時に使える捨てメアドを自動生成して本来のメールアドレスを守る「Firefox Relay」レビュー - GIGAZINE ということで、せっかくなので軽く調べてみた。流れで、類似サービスである 1Password+Fastmail や Apple のやつも。 Firefox Relay https://relay.firefox.com 無料だと 5 つまでランダムなメールアドレスを作れる。 日曜日はそれ以上作れなかったので、ベータリリースから 1 年以上経ってまだ正式リリースされてないんだ?と改めてログインして確認したら、Premium⁩ プランが現れていた・・・! PayPal 払いの $0.99⁩/month。本格的に使うとなるとロックインされるのは確か。さてどう判断するか。 メールエイリアスを 5 つ作ったから Premium プランが現れたのか、ログイン後数日経ったから現れたのか。どっちだろう? オフィシャルで Add-on があるので、割と簡単に作れそう。 Firefox Relay – 🦊 Firefox (ja) 向け拡張機能を入手 追記(2021-11-18): なんとびっくり!このタイミングでの正式リリースでした。メールエイリアスのドメインも relay.firefox.com から mozmail.com に変わってた。 Firefox上でサービス登録用の捨てメアドを無限に自動生成して管理してくれる「Firefox Relay Premium」が登場 - GIGAZINE 1Password + Fastmail https://1password....

2021-11-17 (Wed) · masutaka

メールフッタのセパレータ "-- "

よく “–” で区切られれていますが、RFC 3676 的には最後に半角スペースを加えた “– " が正しいです。sig-dashes と呼ぶらしいです。 https://www.ietf.org/rfc/rfc3676.txt There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using “– " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed....

2018-12-17 (Mon) · masutaka

telnet で直接 web サーバとお話しする。

[2004-02-09-1] の HTTP 版です。 Web ブラウザは HTTP リクエストを送信し、返ってきたステータスコード や、生の HTML 等を解析するのが仕事です。 HTTP リクエストは簡単なので、人間が telnet で接続しサーバとお話しす ることもできます。 存在するページを指定すると、200 ステータスコードとともに、生の HTML コードが出力されます。 % telnet www.example.com 80 Trying 208.77.188.166... Connected to example.com. Escape character is '^]'. GET /index.html HTTP/1.0 #<= 入力後、Enter×2回 HTTP/1.1 200 OK #<= ステータスコード 200 が返ってきた。 (以下省略) 存在しないページを指定すると、404 ステータスコードが出力されます。 % telnet www.example.com 80 Trying 208.77.188.166... Connected to www.example.com. Escape character is '^]'. GET /hoge.html HTTP/1.0 #<= 存在しないページを入力後、Enter×2回 HTTP/1.1 404 Not Found #<= ステータスコード 404 が返ってきた。 (以下省略) オプション(HTTP ヘッダ)を指定すると、環境変数として CGI に渡ります。 この例だと分かりませんが、簡単な CGI のプログラムで確認出来ます。...

2009-05-16 (Sat) · masutaka

電子メールでの一行の制限

2つの制限 SMTP プロトコルが定義された RFC 5321 によると、“4.5.3.1.6. Text Line” に一行は(英文字で) 1000 文字までと制限されている。 原文 The maximum total length of a text line including the is 1000 octets (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions. 日本語訳 <CRLF> を含むテキスト行の最大長は 1000 オクテットです(透過性のために付けられた複製した先頭のドットはカウントしません)。この数値は SMTP サービス拡張の使用によって増加するかもしれません。 URL: http://www.hde.co.jp/rfc/rfc5321.php 実際はユーザが意識する必要はなくて、MUA(メーラ) が適切に処理してくれる。例えば Mew は長い行があるとエンコード方法を訊いてくる。 Lines are too long. Input encoding (base64):...

2009-03-14 (Sat) · masutaka

メール本文に ISO-2022-JP を利用することになった背景

mew-dist 355 (古い…) から一部抜粋。 |仕様では通常、シンタックスとセマンティクスを定義します。 | |RFC822 では、ヘッダのセマンティクスもボディのセマンティクスも ASCII と |定めています。ASCII とは、0-127 の範囲を ASCII 表にある文字として解釈 |するというセマンティクスです。ただ、RFC822 の執筆当時 Dave が気が付い |ていた犯しやすいシンタックス上の問題点(単一の CR など)は明確に排除しま |した。 | |日本で本文に ISO-2022-JP を入れたのは、シンタックス上は問題ありません |が、セマンティクスを破っています。ASCII 文字列中に ESC シーケンスが現 |れても、それは単なる ESC シーケンスですから、日本語として取り扱われま |せん。また、ヨーロッパでは、本文に 0-255 までを許し、これを Latin-1 と |解釈することにしました。これはシンタックスもセマンティックスも破ってい |ます。しかし、所詮、日本で ISO-2022-JP を利用しようとした背景は、ヨー |ロッパが 8bit 領域を使っていたからにほかなりません。日本でも EUC Japan |を標準に選ぶ可能性はあったということです。 シンタックスは「構文」、セマンティクスは「データの意味」のことらしい。へぇ〜。 Gartner Column:第11回 そもそも「セマンティクス」とは何だろう? が参考になるかも。 追記(2009-04-05): 関連する話題があったので、貼り付けておきますね。 (URL: 日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か - スラッシュドット・ジャパン ) 個人的には ISO-2022-JP で表現できない内容なら、Unicode で送るのはまっ たく問題ないと思います。ただ上の記事にあるように、本文に 8bit 目を 使うのはシンタックスを破ることになるので、base64 符号化は必須です。...

2008-02-28 (Thu) · masutaka

Message-Id や Date は誰が付けるべきか?

[2003-03-01-2] のメモにあった URL から抜粋、一部修正。 |MTA としての本来の役割を考えてみると、envelope の情報に基づきホストから |ホストへメッセージを配送するのが仕事であり、基本的には(経路情報のヘッダー |を付ける以外)メッセージそのものには関与しない。MTA が Message-ID を付け |るということはヘッダーを解析し、Message-ID がすでにあるかどうか調べると |いうことであり、余計な処理が必要になるということである。つまり、MTA と |しての役割から見た場合、(親切な行為なのか余計なお世話なのかはともかくと |して)必要なこと以上のことを行っているのである。 | |なお、RFC821(SMTP の仕様書)の改定案の “6.3 Compensating for |Irregularities” では受け取ったメッセージが Message-ID や Date を欠いて |いれば MTA でそれらを追加してよい “MAY” となっている。ただし、そのよう |なメッセージを生成した MUA を “these weak SMTP clients” と呼んでいるこ |とからも、本来は MUA で生成すべきだという考えが読み取れると思う。また、 |将来的には欠いているヘッダは Message Submission Agent (MSA) で補完され |るようになるかも知れない(RFC 2476 “Message Submission” を参照)。 URL: http://www.emaillab.org/essay/message-id.html#where

2007-11-16 (Fri) · masutaka

In-Reply-To は複数の Message-Id を指定できる

In-Reply-To:って複数の Message-Id:を指定できるみたい。知らなかった。[mew-dist 23085] Essays about Internet Mail [RFC2822] message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF 仮にccヘッダに、A、B、Cという3つのアドレスが書かれている メールがあった場合、それをメールソフトが「RCPT-To: A」と書いた メール、そして「RCPT-To: B」、さらに「RCPT-To: C」と書いた3つの メールに分け、それを順々に1通1通、配送プログラムに渡している。 ↓RFC822 に規定されているヘッダは全て説明しているのでいいかも。 http://www2.luice.or.jp/~deai/backn/master/index.html

2003-03-01 (Sat) · masutaka

電子メールの書式

電子メールの書式は RFC822 で定義されています。 改定版は RFC2822で、RFC822は obsoleteとなりました。 URL: http://www.mew.org/Newsletters/1.html

2002-10-03 (Thu) · masutaka

Mew の添付ファイルの種類

C-c C-aでファイルを添付した後、T で、ファイルの種類を決められる。 Message/Rfc822が、いわゆる転送メール。

2002-02-18 (Mon) · masutaka