[2021-08-07-1] にデフォルトブラウザを Firefox に変えて、3 ヶ月くらい続いている。 昔と違って、基本的な使い勝手や見た目は Chrome と違いがない。当たり前だけど Chrome と比べて良い点も悪い点もある。総合的に割と良い選択をしたと思っている。※ 変化できないことやロックインされることを、最近極端に恐れるようになった事情あり。 ...
よく “–” で区切られれていますが、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. ...
[2004-02-09-1] の HTTP 版です。 Web ブラウザは HTTP リクエストを送信し、返ってきたステータスコード や、生の HTML 等を解析するのが仕事です。 HTTP リクエストは簡単なので、人間が telnet で接続しサーバとお話しす ることもできます。 ...
２つの制限 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. ...
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 |を標準に選ぶ可能性はあったということです。 ...
[2003-03-01-2] のメモにあった URL から一部抜粋。 🔗 Message-ID はどこで生成されるのか？ MTA としての本来の役割を考えてみると、エンヴェロープの情報に基づきホストからホストへメッセージを配送するのが仕事であり、基本的には（経路情報のヘッダーを付ける以外）メッセージそのものには関与しない。MTA が Message-ID を付けるということはヘッダーを解析し、Message-ID がすでにあるかどうか調べるということであり、余計な処理が必要になるということである。つまり、MTA としての役割から見た場合、（親切な行為なのか余計なお世話なのかはともかくとして）必要なこと以上のことを行っているのである。（中略）なお、RFC821 の改定案 の"6.3 Compensating for Irregularities"では受け取ったメッセージが Message-ID や Date を欠いていれば MTA でそれらを追加してよい"MAY"となっている。ただし、そのようなメッセージを生成した MUA を"these weak SMTP clients"と呼んでいることからも、本来は MUA で生成すべきだという考えが読み取れると思う。また、将来的には欠いているヘッダは Message Submission Agent (MSA) で補完されるようになるかも知れない（RFC 2476 “Message Submission” を参照）。 ...
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という３つのアドレスが書かれているメールがあった場合、それをメールソフトが「RCPT-To: A」と書いたメール、そして「RCPT-To: B」、さらに「RCPT-To: C」と書いた３つのメールに分け、それを順々に１通１通、配送プログラムに渡している。 ...
電子メールの書式は RFC822 で定義されています。 改定版は RFC2822で、RFC822は obsoleteとなりました。 URL: http://www.mew.org/Newsletters/1.html
C-c C-aでファイルを添付した後、T で、ファイルの種類を決められる。 Message/Rfc822が、いわゆる転送メール。