2012-08-06 (月)

Gmail に来た全てのメールをスパム判定しないフィルタリングルール [E-mail][Google]

「条件」に from:(@) を指定し、「処理」に「迷惑メールにしない」を
指定するだけ。
image/gmail-nospam

From がないメールは条件に一致しませんが、さすがに無視できる数でしょう。

Gmail の転送機能って、転送する前にスパム判定するのですよね。
Gmail から Gmail に転送していると、二重にスパム判定することになり、
たまに誤判定されるので設定しています。

追記(2012-11-10):
from:(.*) はダメでした。実際に検索して、全てのスレッドが引っかかる
か試せば分かることでしたね。。検索条件を from:(@) に変えました。
これなら大丈夫なはず。

追記(2013-03-28):
http://ziddy.japan.zdnet.com/qa8009043.html で引用されていたので追
記。from:(@) でもダメなことがありました。半年で4件程度。完璧な方法
はないのかしら。。

2009-05-16 (土)

telnet で直接 web サーバとお話しする。 [Apache][E-mail]

[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 のプログラムで確認出来ます。

% telnet www.example.com 80
Trying 208.77.188.166...
Connected to example.com.
Escape character is '^]'.
GET /index.html HTTP/1.0         #<= 入力後、Enter×1回
User-Agent: Telnet [ja] (Linux)  #<= 適当な User-Agent を入力後、Enter×2回

HTTP/1.1 200 OK                  #<= ステータスコード 200 が返ってきた。
(以下省略)



まとめ


200: OK -> 正常にアクセスできた。
404: Not Found -> ページが見つからなかった。


参考情報: Wikipedia - Http
参考情報: Wikipedia - HTTPステータスコード
参考情報: telnetでブラウズ(HTTP)

こうして確認してみると、HTTP のデータ構造は電子メール(RFC2822)とそっ
くりだということが分かります。両方ともヘッダは複数の

フィールド名: 内容

で構成され、最後は空行で終わります。

あと、[2003-06-08-1] にも書きましたが、例で使っている example.com
は、予約ドメインとして RFC2606 に定義されています。実際にアクセスす
ることも出来ます。

この記事に言及しているこのブログ内の記事

2009-03-14 (土)

電子メールでの一行の制限 [E-mail][Mew]

SMTP プロトコルが定義された RFC 5321 によると、"4.5.3.1.6. Text
Line" に一行は(英文字で) 1000 文字までと制限されている。

原文

The maximum total length of a text line including the <CRLF> 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):


ではメーラが適切に処理しなければどうなるのか? MTA(転送プログラム)
が適切に処理してくれる。例えば sendmail の標準的な設定では、990 文
字目に !<cr><lf> が挿入される。

もっとも、メーラは RFC 5321 を意識しているわけではなく、RFC 2822(電
子メールの仕様) に則って実装されている。"2.1.1. Line Length
Limits" によると、1 行は(英文字で) 78 文字以下であるべきで、998 文
字以下でなければならないと定められている。

原文

There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.


日本語訳

この標準では1行中の文字数に2つの制限がある。それぞれの行の文字はCRLF
を除いて、決して998文字以下でなければならず(MUST)、78文字以下であるべ
きである(SHOULD)。


(URL: http://www.puni.net/~mimori/rfc/rfc2822.txt)


RFC 3676 による Text/Plain の拡張

一方、RFC 3676 で Text/Plain が拡張され、送信元のメーラが対応してい
ればユーザは長い行を気軽に書いてもよくなった。そのようなメールのヘッ
ダ部分には "Text/Plain" のパラメータとして "format=flowed" が設定さ
れ、長い行の途中には適度に「半角スペース+改行」が挿入される。これに
より連続した行が折り返されたものか、本当に改行されたものかが分かる。
そのため、受信者側のメーラは適度に改行して表示できるようになった。

Content-Type: Text/Plain; charset=us-ascii; format=flowed


上記は英語本文の場合だが日本語本文の場合、以下のような値となる。

Content-Type: Text/Plain; charset=iso-2022-jp; format=flowed; delsp=yes


"delsp=yes" とは何か?英語本文は単語の途中で折り返されることはない
ため、折り返された行を連結したい時は行末のスペースをそのまま単語の
区切りに使えばよい。しかし、日本語本文でそれをやると単語の途中で半
角スペースが現れ、みすぼらしい文章になる。よって、連結する時は行末
の半角スペースを削除してねというお願いが "delsp=yes" というわけ。

Mew のデフォルトでは "format=flowed" は OFF だが、以下の 2 種類の方
法で ON にすることが出来る。

;;送信メールは常に "format=flowed" を ON にする。
(setq mew-use-format-flowed t)



;;現在作成しているメールの "format=flowed" を ON にする。
draft-mode で C-c C-f



Mew は "format=flowed" でないメールは、何も加工せずに表示する。
Summary-mode で `_' することによって、折り返された行、長い行、通常
の行の順に行の表示を変えることが出来る。

それに対して、"format=flowed" なメールは一度 `_' された状態で表示される。

※ Mew での長い行の扱いについては、Info の longline の項に記載されている。

2008-02-28 (木)

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

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 符号化は必須です。

Shift-JIS や EUC-JP を base64 符号化せずに送るのは 8bit 目を使って
いるので論外ですが、じゃあ Shift-JIS+base64 や EUC-JP+base64 なら良
いの?と言われるとこれも NO です。ISO-2022-JP で送れば素直なプレー
ンテキストになるのに、無駄な符号化をしているので。

2007-11-16 (金)

Message-Id や Date は誰が付けるべきか? [E-mail]

[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)

2003-03-01 (土)

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

In-Reply-To:って複数の Message-Id:を指定できるみたい。知らなかった。[mew-dist 23085]
[RFC2822]
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
<http://www.emaillab.org/essay/index.html>
仮に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>

この記事に言及しているこのブログ内の記事

2002-10-03 (木)

電子メールの書式 [E-mail]

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

2002-02-18 (月)

Mew の添付ファイルの種類 [E-mail][Mew]

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

最終更新時間: 2017-04-22 12:29

検索
最近の話題
- 2017-04-16
  CircleCI 2.0 で capistrano デプロイしてみた
- 2017-04-15
  CircleCI 2.0 をローカルで実行できる circleci コマンドとは何者か
- 2017-04-13
  Rails リポジトリに CircleCI 2.0 を導入した
- 2017-04-08
  PS4 Pro と LG の 4K テレビ 43UH6500 で nasne は使えるのか?
- 2017-04-02
  オムロンの低周波治療器が肩こりにだいぶ効く
- 2017-03-21
  ローカル環境を出来るだけ Dockerize した
- 2017-03-12
  JAWS UG 2017 に行ってきた #jawsdays
最近追記された記事
- 2017-04-13-1 (6日前)
- 2017-04-13-1 (8日前)
- 2017-03-02-1 (50日前)
- 2017-02-25-1 (55日前)
- 2017-02-21-1 (59日前)
- 2015-06-07-1 (65日前)
- 2016-10-19-1 (74日前)
- 2016-01-01-1 (86日前)
- 2015-01-04-1 (95日前)
- 2015-06-07-1 (115日前)
カテゴリ
- Anthy (3)
- Apache (11)
- Apple (1)
- ATOK (4)
- au (3)
- AWS (17)
- Bazaar (1)
- Berkshelf (2)
- BigQuery (1)
- BitBar (3)
- Book (85)
- Boxen (2)
- Bugsnag (1)
- C (26)
- capistrano (4)
- chalow (56)
- ChatWork (1)
- Chef (17)
- Chrome (3)
- Chromecast (1)
- CircleCI (10)
- Comics (2)
- Cooking (10)
- cvs (15)
- cygwin (12)
- D3.js (1)
- Debian (55)
- Docker (3)
- E-mail (8)
- elasticsearch (4)
- Emacs (219)
- Emacs講座 (10)
- English (4)
- feedforce (7)
- fetchmail (3)
- Firefox (20)
- Fluentd (4)
- ftp (1)
- Game (20)
- Gem (5)
- Git (9)
- GitHub (15)
- Go (5)
- Google (1)
- gpg (4)
- GrowthForecast (7)
- Health (3)
- Heroku (9)
- Homebrew (10)
- HTML (6)
- iBook (1)
- iPhone (15)
- IRC (1)
- Jenkins (8)
- JS (1)
- Karabiner (1)
- KeySnail (3)
- Kibana (1)
- Kindle (1)
- Langrich (7)
- LDAP (6)
- Life (19)
- Linux (5)
- Mackerel (1)
- Mew (18)
- MongoDB (1)
- Mozilla (19)
- Music (1)
- MySQL (1)
- NAS (4)
- nginx (6)
- NHK (1)
- Node (1)
- ntp (4)
- OOP (1)
- OpenID (2)
- openssl (1)
- Opera (2)
- OSX (41)
- Perl (14)
- PHP (19)
- PostgreSQL (1)
- procmail (4)
- Programing (3)
- Puppet (1)
- Python (2)
- Rails (12)
- Rake (2)
- RaspberryPi (1)
- RedHat (29)
- Redmine (3)
- Rspec (1)
- Ruby (48)
- samba (3)
- screen (7)
- sed (5)
- serverspec (6)
- sh (8)
- Slack (2)
- Solaris9 (22)
- Spring (2)
- ssh (4)
- StatusNet (21)
- svn (12)
- Swift (1)
- Tablet (1)
- tdiary (3)
- Twitter (14)
- Twmode (6)
- Ubuntu (5)
- UNIX (102)
- vagrant (8)
- Video (21)
- vim (1)
- Wercker (9)
- Windows (29)
- Wine (3)
- XML (11)
- XP (1)
- zsh (25)
- インストールメモ (33)
- クイックシェイプ (12)
- ネタ (15)
- 勉強会 (14)
- 携帯 (6)
- 正規表現 (4)
過去ログ
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
2003 : 01 02 03 04 05 06 07 08 09 10 11 12
2002 : 01 02 03 04 05 06 07 08 09 10 11 12
2001 : 01 02 03 04 05 06 07 08 09 10 11 12
Google+