Telnet

telnetでメールを送信する方法としてこれまで2つのエントリで方法を紹介してきました。 - [コマンドプロンプトだけでメールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/03/26/%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E3%81%A0%E3%81%91%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%92%E9%80%81%E4%BF%A1%E3%81%99%E3%82%8B/) - [telnetで日本語メールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2012/01/04/telnet%e3%81%a7%e6%97%a5%e6%9c%ac%e8%aa%9e%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%92%e9%80%81%e4%bf%a1%e3%81%99%e3%82%8b/) 前回の方法でとりあえず日本語メールが遅れているのですが、もうちょっときちんとしたヘッダを付けてメールを送信する方法を紹介したいと思います。 まず、SMTPで日本語を(も)取り扱うための規格としてMultipurpose Internet Mail Extensions(MIME)があります。 - [Multipurpose Internet Mail Extensions - Wikipedia](http://ja.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions) これによってUS-ASCII以外の文字や添付ファイルなどが扱えるようになっています。今回はきちんとMIMEを使って日本語メールを送ってみようと思います。 ヘッダとボディ これからMIMEの説明をするにあたっては、まずヘッダとボディをきちんと認識する必要があります。前回送信したメールで説明すると以下のようになります。 dataコマンドでデータを送信することを指定した後でメールのヘッダとボディを連続して書き込んでおり、ヘッダとボディの区切り目は空行によって表現されているわけです。MIMEヘッダの記述はヘッダ部分に行っていきます。 MIME-Version MIMEのバージョンを区別するためのヘッダです。現在1.0しかありませんので必ず以下のような記述になります。 M i m e - V e r s i o n : 1 . 0 Content-Type メッセージ(ボディ部分)の形式を指定するヘッダです。様々なものがありますが、日本語メールを送りたい場合にはここはtext/plainになります。さらにtext/plainの場合にはその文字コードを表すcharsetが追加されます。具体的には以下のような記述になります。 C o n t e n t - T y p e : t e x t / p l a i n ; c h a r s e t = " i s o - 2 0 2 2 - j p " ; ...

telnetでメールを送信する方法について以前紹介しました。 - [コマンドプロンプトだけでメールを送信する | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/03/26/%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%97%E3%83%AD%E3%83%B3%E3%83%97%E3%83%88%E3%81%A0%E3%81%91%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%92%E9%80%81%E4%BF%A1%E3%81%99%E3%82%8B/) 今回はtelnetから日本語でメールを送信する方法を紹介してみようと思います。もちろん実用性はほぼ無いのですが、メールの仕組みを理解するためには結構良い練習になると思います。是非この記事を見ながら、自分のアドレスにメールを送信してみてください。 (※注意※ 昨今はSPAM対策でプロバイダによってはそもそもSMTPでの接続を許可していないところが多いです。初めのメールサーバーへの接続の段階でうまく接続できなかったら残念ですが、別途勉強のためにSMTPサーバーを立ててそこに対してメールを送信してみるなどしてみてください。) とりあえず日本語で入力してみる まずはtelnetでメールサーバーに接続します。(ここでは私の自宅のメールサーバーに接続しています。) 前回紹介した方法で、メールの送信元、送信先を入力します。 まず、ヘッダ部分を入力します。メールヘッダとメールボディの間には空行が1行必要です。 さて、ここで日本語を入力してみましょう。Alt + 全角半角キーを押して、えいやと。「日本語のテストメールです。」と入力してみます。 おや？なんだか、入力しているそばから文字が化けていきますね…。 とりあえず送信を完了します。送信の最後は「.」です。「改行.改行」ですね。 さて、とりあえずメールは送ってみました。どうなったでしょうか?着信したメールをgmailで確認してみます。 おお！文字化けせずにきちんと日本語が見えますね。本当は記事を書く前にはここでは文字化けすることを想定していたのですが、Windows7からgmailへの送信では化けませんでした。gmailは優秀ですね！ gmailでは化けませんでしたが、結構な数のメールシステムではこの送信方法では文字化けが発生すると思います。自分のシステムで試してみてください。 到着したメールのチェック せっかく文字化けせず送信できましたので、中身をもうちょっと見てみましょう。gmailではメッセージのソースを見ることができます。ソースを見てみましょう。 ソースの状態でもきちんと日本語が見えてますね。それではこの状態でエンコードを確認してみます。 ちょっと見づらいですが、Shift-JISになっていることがわかると思います。これで確認できましたが、先ほどは日本語をShift-JISで送信したのでした。そして、メール本文をShift-JISで記述してそのまま送信するのはRFC違反であり、文字化けする可能性が結構高くなってしまいます。 日本語をメールで送信する際には文字コードにJIS(ISO-2022-JP)を使用するのがお約束になっており、これであればまず文字化けしません。なので、telnetから日本語メールを送信する場合もJISで送信すべきです。(このあたりの細かい話はまた別エントリで…) telnetのcodesetを設定する さて、それでは今度はきちんとtelnetの設定をおこなって、RFC的に正しいメールを送信してみましょう。 まず、telnetを起動します。引数無しでtelnetだけですね。 まず、現在の設定を確認してみます。displayコマンドを入力します。 codeset = 漢字コードセット は設定されていない状態になっています。helpを表示するとset codesetコマンドで漢字コードセットの設定ができることがわかりますので、JIS Kanjiに設定しましょう。 この漢字コードセットの設定は保存されますので、一度telnetを終了しても再度設定する必要はありません。さて、それではこの状態でもう一度メールを送ってみましょう。openコマンドで接続を開始できます。 今度は telnet上でも日本語がきちんと見えるようになりましたね。(※ただ、終端の改行.改行が意図したとおりになりませんでした。これは私も原因がよくわからない…というか.になってないからなのは確実なのですが、ちょっと変な挙動のように思います。telnetのバグ?) とりあえずgmail側で確認してみましょう。 今度もきちんと日本語が表示されました。ソース、文字コードも確認しましょう。 ソース上では日本語がそのままは読めません。エンコードはShift-JISになっています。これを「日本語(ISO-2022-JP)」に変更します。 きちんと日本語が読めるようになりました。これできちんとJISで送信できていたことが確認できました。この形式であればほぼ間違いなく、すべての日本語メール環境でメールが読めるはずです。 細かいところはひとまずおいておきましょう。メールでは日本語はJIS(ISO-2022-JP)で送るという事をまずは抑えておいてもらえればと思います。

今回はWeb、その中でもHTTPの部分の話です。世の中にはさまざまなブラウザがあり、非常に高機能なものが多いです。でも、それらが提供している機能のうち一番の基礎となる通信部分に関してはかなりシンプルです。 HTTPとは まず、はじめにHTTPとは何か?という点に関してです。HTTPはHyper Text Transfer Protocolの略で、Hyper Textを転送するための手続きだ、というわけですね。Hyper Textというのはテキストを超えるものだ、ということです。そして、Hyper Textを書く手段がHTMLで、そのHTMLを伝える手段がHTTPなわけです。このあたりはWikipediaに説明を譲ります。 - [Hypertext Transfer Protocol - Wikipedia](http://ja.wikipedia.org/wiki/HTTP) - [ハイパーテキスト – Wikipedia](http://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%91%E3%83%BC%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88) - [HyperText Markup Language – Wikipedia](http://ja.wikipedia.org/wiki/HyperText_Markup_Language) 要は世の中に沢山あるWebサーバーから情報をひっぱってこようとおもったら、HTTPでおしゃべりすればいい、ということです。 Webページを取得してみる それでは実際にやってみましょう。やってみると簡単ですよ。簡単なページが良いので、いつものようにGoogleのページを引っ張ってきてみましょう。 まずは、googleのWebサーバーであるwww.google.co.jpに接続します。WebサーバーはTCPの80番で動作していますので80番に接続します。 1 : C : \ > t e l n e t w w w . g o o g l e . c o . j p 8 0 接続に成功すると何も表示されない状態になります。それで正常です。この状態でWebサーバーに対してページを要求します。以下のように入力します。 1 : G E T / H T T P / 1 . 1 ...

「インターネットに繋がらない」 - 初級編では直接、インターネットに接続されている環境での処理の流れを見てもらいました。今度は別のバリエーションとして、直接はインターネットに接続されておらず、Proxyを経由してインターネット上のWebサイトを閲覧するようなケースを考えてみます。 一般家庭でProxyを利用しているようなケースは極稀でしょうけれども、企業では様々な理由からProxyを利用しないとWebサイトの閲覧ができないように構成していることもあります。特にセキュリティに気を使っている企業ではProxyの利用は当たり前です。あとは、サイトを閲覧する際に実IPを隠すためにあえてProxyを利用するようなケースもあるかとは思いますが今回はそのあたりに関しては扱いません。例の如く別エントリにて解説予定です…。 Proxy接続の場合には通常の直接インターネットへ接続(Webサイトの閲覧)をする場合と比較すると以下のようなプロセスの違いがあります。 直接 Proxy経由 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 5．DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 6．該当のWeb Serverに接続する 7．Web Serverからコンテンツを得る 8．ブラウザにコンテンツを表示する 5．Proxyサーバーに接続する 6．Proxyサーバーからコンテンツを得る 7．ブラウザにコンテンツを表示する 大きな違いは以下の2点です。 DNSを使用した”名前解決”を実行しない(必要ない) 接続するのは常にProxyサーバー Proxyサーバーを利用する場合には、Proxyサーバーに実際のコンテンツの取得をお願いする形になります。つまりProxyサーバーは「直接」の場合の5,6,7の動作を行い、その結果をPCに渡してくれるわけです。 トラブルシュートの方法 トラブルシュートとしては、Proxyサーバーの設定およびProxyサーバーへの接続があります。 Internet Explorerの場合には「ツール」→「インターネットオプション」→「接続」タブ→「LANの設定」からProxyの設定を行います。 Proxyへの接続がきちんとできているかを確かめるには、「telnet Proxyサーバー ポート番号」を実行するとよいでしょう。コマンドを実行して、画面が真っ暗になれば接続できています。 「ローカルアドレスにはプロキシサーバーを使用しない」の意味 Proxy環境の場合によく問題になるのは「ローカルアドレス」という言葉の意味です。普通に「ローカルアドレス」と聞くと同一セグメントのIPアドレスなり、プライベートアドレスなりといったものを連想すると思いますが、これはそういう意味ではなくて「名前に.(ドット)が含まれていないもの」という意味になっています。通常WindowsネットワークではPC名のみで近くのサーバーへの接続(名前解決)ができるため、このような判断基準になっているのだろうと思います。 具体例をあげましょう。Proxyサーバーを利用し、かつ「ローカルアドレスにはプロキシサーバーを使用しない」のチェックが入っているとします。 pcname(ホスト名) pcname.test.local(FQDN) 192.168.1.1 上記の3つが全く同じホストを指している場合、1はホストに対して直接のアクセス、2と3はProxyサーバー経由のアクセスということになります。単純に.(ドット)が含まれているかどうかが判断基準です。 よく2や3の場合でも同じサブネットなんだからProxyサーバー経由ではなく直接接続してくれると勘違いしてしまうケースがあるので、きをつけてください。 2や3の入力方法でも直接接続させたい場合には除外設定を行えばよいです。 そもそもProxy接続をしなければいけないことをどのように知るのか Proxy接続が必要な環境であること自体を知る、あるいは直接接続はできないと判断するにはどうすればいいでしょうか。これはDNSの確認とHTTPポートでの接続の可否で判断できます。 外部のホスト名の名前解決ができるか まず、DNSに関して。DHCPなり固定IPなりできちんとしたDNSを割り振られていることを前提とします。この状態でnslookupにて外部ホストの名前解決ができるかどうかを確認します。 上記のように名前解決ができるようであれば、自らWebサイトへの接続が試行できるので、Proxyは必要ない環境の可能性が高いです。逆にここで名前解決ができないようであればProxyが必須の環境であるということがわかります。あるいは完全にインターネット上のホストへのアクセスができないか、です。 外部のホストに接続できるか 名前解決ができる環境であれば直接Webサイトへの試行を行うことができます。Webサーバーへの接続はtelnetでHTTPポートへの接続で試すことができます。 名前解決ができても外部ホストに接続できない場合や逆に名前解決ができなくても外部ホストに接続ができる場合などもあり得ます。ですが基本的には両方うまくいかなければProxy接続が必要な環境だ、ということがいえます。 Proxyの設定に関する注意点 ちなみにWindows上のアプリケーションの場合にはインターネットアクセスの際にIEのProxyの設定を参照するものも結構あるので注意が必要です。特に規定のブラウザをIE以外のブラウザに変更しているときには注意が必要です。IEのProxy設定にも設定を入れておきましょう。 また、サービスで動作しているプロセスがProxy設定を必要とするケースがあります。この場合には該当アカウントのプロファイル上でIEのProxy設定を行う必要があるものもあるので注意が必要です。 さらに、IEのProxyを見ないでWinHTTPの設定を見るアプリケーションもあります。さらにはIEでアクセスするくせにWinHTTPの設定を見るようなものも存在していますので(Microsoft Update等)、proxycfgコマンドでの設定が必要なケースもあります。このあたりには注意が必要です。 参考：How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site ...