コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

2022年時点のメールアドレスの最大長は色々な仕様を鑑みると254文字

メールアドレスって最長どれくらいなの?という問いに対するひとつの指針。

先にまとめ

  • メールアドレスのフォーマットだけの仕様を取り上げると64+254=318文字が最大長と解釈できる。
  • ただし、SMTPの仕様で送り先を指定するforward-pathが256文字という定義もある。
    • そちらに加えてDNSの名前解決の仕様上、メールアドレスに合わせて最初と最後に区切り文字列を付与する必要があるため、実質254文字が限界

RFC5321(SMTP)の仕様

アドレス自体の定義

まずはメールアドレスの構成要素に関する定義だが、こちらはRFC5321に以下の記述がある。

As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term "mailbox" refers to that depository. The two terms are typically used interchangeably unless the distinction between the location in which mail is placed (the mailbox) and a reference to it (the address) is important. An address normally consists of user and domain specifications. The standard mailbox naming convention is defined to be "local-part@domain"; contemporary usage permits a much broader set of applications than simple "user names". - RFC 5321 - Simple Mail Transfer Protocol

addressmailboxを資料内で互換性のある表現であることを書きつつ、 mailboxlocal-part@domain という命名規則である旨が書いてある。

そして後半のパートで local-partdomain の文字数の言及がある。

4.5.3.1.1. Local-part The maximum total length of a user name or other local-part is 64 octets. 4.5.3.1.2. Domain The maximum total length of a domain name or number is 255 octets. - RFC 5321 - Simple Mail Transfer Protocol

上記のような記述があるのでオクテット(≒文字数)は…

  • local-part(@より前)は64オクテット
  • domain(@より後)は255オクテット

となります。

ただしdomainの部分はここでは割愛しますが、他の仕様との兼ね合いで実質2文字少なく、253文字が限界となります。

送信仕様である部分の記述

アドレスの仕様は上記の通りだが、送る手順であるSMTP側の手続きの記述として以下のような内容がある。

RCPT TO:<forward-path>

上記の forward-path のアドレスに対してメールを送るという命令のフォーマットであるが、このforward-path に関して以下のような文字数制限の仕様がある。

4.5.3.1.3. Path The maximum total length of a reverse-path or forward-path is 256 octets (including the punctuation and element separators).

このため、実質的にドメインの定義の長さとは関係なく、送信をするSMTPの仕様として256文字が限界ということになる。

ただし、including the punctuation and element separators とあるように区切り文字などの記述を含むため、メールアドレスの区切りを示す <> が必要になるので実質は254文字が限界となる。

参考サイト

余談

仕様上は254文字を確保しておけば盤石だが、セールスフォースでは80文字を限界値として設定しているとのこと

Maximum Size of an address: Per RFCs, an email address can be 256 characters in length. Most email address fields in Salesforce are currently limited to 80 characters. This is generally large enough to cover most email addresses. - Email Address Validation

なので世の中のアドレスは80文字に満たないケースのほうが大多数と思われるので、補足の知見として。

2022年時点のでRailsの強みがまとまっているスライド『RubyとRailsの何が強いのか』

対象のスライド

speakerdeck.com

みどころ

Rubyのコミッタである武者さんがRailsと他の言語やフレームワークなどに関してまとめられており、Railsの強みを再認識できる。ActiveRecordに関しては多くの場面で語られて活きているのだが、MigrationやRailsコンソールに関しては離れてみて実感できる部分だと私自身も非常に共感できた。

仮にRails以外の選択肢を行う場合にRailsの強みを認識していないと選択がブレてしまうので、そういうときに見返したい資料だと思いました。

関連リンク

CookieのSecure属性の必要性に関してざっくりまとめる

自分の知識の再整理も含めてまとめる

CookieのSecure属性とは

MDN曰く以下のような説明になっている

Secure 属性がついた CookieHTTPS プロトコル上の暗号化されたリクエストでのみサーバーに送信され、安全でない HTTP では決して送信されないため、中間者攻撃者が簡単にアクセスすることはできません。(URL に http: を含む) 安全でないサイトは、 Secure 属性を使用して Cookie を設定することができません。 - HTTP Cookie の使用 - HTTP - Cookie へのアクセス制限 | MDN

このようにSecure属性をつけておくことでブラウザはHTTPS以外のアクセスのときには該当のCookieを送信しなくなるので、通信経路の途中でCookieを見られる心配がなくなる。

よくある間違い

HTTPSだけで構成されたサイトであればSecure属性は不要なのではないか?

上記で書いたように、中間者攻撃への対策が主体なので「HTTPSだけで構成されたサイトであればHTTPへのアクセスはないので問題はないのではないか」という誤解があるが、実はそんなことはない。

Cookieの送信自体はブラウザが行い、ドメインが同じであれば送信を行う。例えば https://watashi.example.com にてSecure属性なしで登録したCookieドメインが同じ http://watashi.example.com でも送信される。

このため、悪意のあるユーザが http://watashi.example.com へのaタグをおき、その時のRequestHeaderを監視すればかすめ取ることができてしまう。

80番ポートを塞げばいいのではないか?

上記の流れで「HTTPでのリクエスト自体が成立しなければそもそもブラウザが送らないのではないか」という話もあるが、実際はそうではなくポートが空いている空いていないに関わらずCookieが送信されるタイミングがある。詳しくは下記徳丸先生のYoutubeを参照のこと。

TCP/IPを理解している人ほど間違いやすい 常時SSLでもCookieのSecure属性が必要な理由 - EGセキュアソリューションズ株式会社

関連リンク

アイメッセージ、ユーメッセージをフィードバックの観点でざっくりまとめる

言葉の意味と使い分けをざっくりとまとめる

言葉の意味

  • ユーメッセージとは You Message のことで「相手(あなた)」が主体のメッセージのこと。
  • アイメッセージとは I Message のことで「自分」が主体のメッセージのこと。

例文

自分がAさんに対して「いまの状態だと厳しいのでより協力してほしい」ということを伝えるときに

  • ユーメッセージだと「あなたもっと協力してほしい」
  • アイメッセージだと 「協力してもらえると私は助かる」

アイメッセージをフィードバックでは有効に使う

例文だと分かりづらかったが、例を変えて「何度いってもなおらないことに関しての感想」という内容にすると

  • ユーメッセージだと「あなたはいくら言ってもなおらないのでちゃんと覚えてほしい」
  • アイメッセージだと 「私はちゃんと覚えてほしいと思っている」

というような言い方となる。

これはアイ・メッセージを組み立てるときに自分が主語となるため、言葉選びが変わるのと、文章の構成としても相手をストレートに責める言い回しがしづらくなるのでマイルドにすることができます。

このようにフィードバックなどを行うさいの言葉選びとして意識するとネガティブなことばを削ぎ落としやすい。

ユーメッセージだと苦手なもの

逆に明確に指示を出す場合はアイメッセージは依頼者が主体だと文章的にわかりづらくなるため、その場合はユーメッセージのほうが適していることがある。

関連リンク

ハイフネーション(hyphenation)に関してざっくりまとめる

ハイフネーションという概念に関して理解が浅かったのでざっくりまとめる。

語源

英語版のWikipediaによると

The hyphen is a punctuation mark used to join words and to separate syllables of a single word. The use of hyphens is called hyphenation. - Hyphen - Wikipedia

これをざっくり和訳すると

ハイフンは、単語を結合したり、ひとつの単語の音節を区切ったりするために使用される句読点です。ハイフンを使用することをハイフネーションと呼びます。

となり、ハイフンを使用すること全般をハイフネーションと呼ぶ。

Webにおけるハイフネーション

ハイフネーションはハイフンを使うこと全般を指すが、ことWebにおいて多くハイフネーションが行われるのが、改行時の単語の分割時の話が多く、以下のように説明されている。

ハイフネーションとは、主にヨーロッパ系言語をワープロで記述する際に用いられる表記法で、単語が行末で尻切れの状態になって改行を含んでしまう状態になった場合に、改行で分割された単語にハイフン(-)を挿入することによって、それがひと続きの単語であると表示することである。 - ハイフネーションとは (hyphenation): - IT用語辞典バイナリ

単語を分割するハイフネーションのルール

このハイフネーションだが、長い単語が文末に来たときに発生するが、どのように単語を分割するかもいくつか考え方がある。

このようなハイフネーションのルールをハイフネーションアルゴリズムと呼び、いくつかのパターンが提唱されている。

ハイフネーションに関するWebの仕様

ハイフネーションに関するWebの仕様に関してはCSShyphens が存在しており、こちらでハイフネーションを実施するかを設定することができる。CSSの詳細はMDNのサイトを確認していただきたい。

hyphens - CSS: カスケーディングスタイルシート | MDN

参考リンク

アイランドアーキテクチャ(Islands Architecture)に関してざっくりまとめる

フロントエンド界隈のフレーズに疎いのでメモとしてまとめる

出典

Islands Architecture - JASON Format

上記のブログにて Katie Sylor-Miller 氏によって考案されたものという話。

用語の意味

Webページの構成要素をサーバーサイドでレンダリングされる部分と単体で動くウィジェットのような形式の部分を分けて構成するやり方です。

Single Page Applicationではすべてのページをコンポーネント化しますが、アイランドアーキテクチャでは一部の部分をJSのコンポーネントなどで設置する方法です。

どのような問題を解決させたいのか

出典記事では「個別にロードされる」「他のものとは干渉させない」ということを基調においており、原則は別々にロードされ干渉されないようにすることを前面に出している。

また、SSRではハイドレーションを行う際にJSのコンポーネントが操作できるまでの時間がかかる問題に関しても、すべてをJS化するのではなく必要な部分をJS化すればいいよねというアプローチになる。

使われているフレームワーク

Astro | Build faster websites がアイランドアーキテクチャを提供するフレームワークとして提唱している様子

参考リンク

JavaScript関係におけるハイドレーション(Hydration)とはなにかざっくりまとめる

平然とハイドレーションというフレーズが出てきてしまい、機械和訳だと「水分補給」になってしまうのでのでざっくり調べる

出典

Hydration (web development) - Wikipedia)

言葉の意味

SeverSideRendering(SSR)に関連する用語で、サーバサイドである程度ReactなどのDOMを構築して、ブラウザ側に返却するがその際にイベントリスナーなどを行わないといけないので、そのような活きた状態に活性化する処理をハイドレーションという。

下記の説明がわかりやすかったので転載します。

SSR にはHydration という処理をどうしても挟む必要があります。ページ中に存在する全てのコンポーネントソースコードを DL して、それを実行して、(onClick プロパティなどで渡された) イベントリスナーを DOM に登録していきます。(中略)イベントリスナーが設定されないと、ユーザがクリックしてページに変化を起こすことはできないですし、コンポーネントソースコードを DL しないと、イベントリスナーの実装や、コンポーネントを再レンダリングした時に、どんな DOM へと書き換えるべきかの情報も得られません。そのため SSR では Hydration がどうしても必要な操作になってきます。 - qwik の発明、及びマイクロフロントエンドへの活用について - mizdra's blog

関連リンク