新人Web担当が今さら聞けないホームページのあれこれ。その2

[著]
メール基礎知識

どうもココマッチのAwayaです。前回はhtmlとサーバーに注目して書きましたが、今回は【メール】についてです。

「Webやホームページに詳しいの?じゃあ、メールもわかるよね?」とよく言われるか、これから言われると思います。筆者も1からサイト制作する場合は大抵メールアドレスの作成と設定がセットになったりします。昔は夜中の3時に「メールが動かない」と、呼び出されたことも。。。

【メール】と【html】はあまり関係ないですが、前回書いたようにWebサーバーを借りるとメールサーバも付いてくるので、ここはWeb担当者としては切り離せないとあきらめましょう(笑)

今回も基礎的な部分からさらに突っ込んだ話ですが、後半ではweb運用に関わる事にも言及しますので是非参考にしてください。

メールの代表的なプロトコル

レンタルサーバーを借りると大抵コンパネからメールを追加できて簡単ですが、それでも【POP】と【SMTP】は知っておく必要があると思います。この二つの単語の末尾についている「P」、前回の記事を読んでいただいた方はわかると思いますが、そう「プロトコル」の事です。

前回記事「新人Web担当が今さら聞けないホームページのあれこれ。

SMTP wiki
https://ja.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

POP wiki
https://ja.wikipedia.org/wiki/Post_Office_Protocol

どちらも似たような感じがしますが、メールメッセージに対してのプッシュとプルの違いのようなものです。つまり【SMTP】の送信はプッシュ、【POP】の受信はプルと考えることができます。

そしてもう一つ重要になる、メールサーバーにアクセスするためのユーザーIDとパスワードです。このアカウントがSMTPサーバーのアカウントなのか、POPサーバーのアカウントなのかわかりづらいですが、実はこの2つのを動かしている、サーバーOSが管理しているユーザーアカウントになることが一般的です。つまり、どちらのアカウントでもあるわけですね。

ですので、システム的にはこのアカウントでサーバーにログインも出来るのですが、通常はセキュリテのためにログイン出来ない用制限されています。そのかわりtelnetなどを使うとログインしてメールを送る事が出来る場合があります。(大規模サーバーでは当然分けてる事があります。ここでは前回同様、中小規模前提です。)

smtp_pop

メールの構造を知る

特にSMTPは「Simple Mail Transfer Protocol(簡易メール転送プロトコル)」と言われるように、ごくごくシンプルな文章を送る為のプロトコルだったようです。昔は日本語の対応も無く、ファイルを添付する機能なんかもプロトコル自体は対応していませんでした。現在は日本語対応の文字コードを件名に埋め込んだり、マルチパートメールという形で対応しています。

例えば日本語の件名の場合は件名の中にエンコード方法を直に書き込んでいます。

例:件名が「テスト」の場合
Subject: =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?=

この「iso-2022-jp」(JISの事です)がエンコードを指定している部分です。メーラーはこれを元に「GyRCJUYlOSVIGyhC」の部分を日本語に変換して、「テスト」という文字を表示させます。

試しに下記サイトで、「GyRCJUYlOSVIGyhC」をJISでデコードしてみください。Base64 Decodeの所に「テスト」と出るはずです。

エンコードマニアックス
http://encodemaniax.com/

さて「マルチパート」という言葉が出てきましたが聞きなれないと思います。先ほども書いたようにSMTPは単純な文章を送る為の規格なので、文章の中で、メール本文や複数の添付ファイルを分けなければなりません。そのために特定の決まった文字列を使って文章内でそれぞれ区切って区切るようにしました。それが「マルチパートメール」であり、区切られたそれぞれの事を「パート」と呼びます。

と、まあ、シンプルメッセージといいつつ、今の時代に合った使い方が出来るようにメールメッセージの中は結構複雑なんですね。

MIME(マルチパートメールについて) wiki
https://ja.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions

POPコマンド

POPの方はもう少しシンプルです。メールサーバーにあるメッセージを確認して、メッセージがある場合、自分のPCにコピーして、サーバーにあるメッセージを削除しておしまいです。この一連の流れが「メールが来ている」というやつですね。

ちなみにこれをPOPで使うコマンドで表現すると、
STAT(メールが来ているか確認) → LIST(メッセージ一覧を取得) → RETR(指定されたのメッセージを受信) → DELE(指定されたメッセージを削除)
となります。

参考RFC1939 日本語
http://jbpe.tripod.com/rfcj/rfc1939.j.sjis.txt

各コマンドの説明
http://www.atmarkit.co.jp/fnetwork/rensai/netpro07/pop3-commands.html

POPコマンド

POPコマンドの最後でメールを削除していますが、実は削除しないで残す事もできます。そうすると他PCやパソコンを再インストールした時に、サーバーに残ったメールをもう一度受信できますので便利ですが、ただ、これだとサーバーのメールBOXがいっぱいになって新しいメールを受信できないなんて事になりかねないので注意が必要です。

それでもいいから、メールをサーバーに残したいという方、、、朗報です。【IMAP】というサーバーにメールを残す事を前提とした方式があります。

IMAP wiki
https://ja.wikipedia.org/wiki/Internet_Message_Access_Protocol

クラウド時代にあったIMAPという方式

最近のメールソフトはだいたいPOPかIMAPを選ぶことが出来ます。IMAPはサーバーにあるメールを閲覧する方式なので、自分のメーラーにダウンロードしません。なので、他のPCからももちろん見れますし、再インストール後も閲覧可能です。

POPでサーバーに残した場合、別PCでメールを見る場合再度ダウンロードなので、場合によっては、何年も前のメールやスパムメールを何千件もダウンロードするなんて事にもなるかもしれませんが、IMAPならそれもありません。まるでGmailのような使い方ができるんですね。ちなみにGmailはIMAPの利用を推奨してるようです。

参考:「IMAP と POP3 の開始方法」 → 「POP と IMAP」 の違い
https://support.google.com/mail/troubleshooter/1668960?hl=ja

ただ、IMAPの場合サーバーの閲覧なので、サーバーに繋げることが出来ない場合は見れないというデメリットも有ります。また、サーバーがIMAPに対応している必要もあります。

IMAPのような使い方が便利なのはわかると思いますが、わざわざPOPから変更するのは大変かもしれません。ただ、それでもIMAP方式をおすすめしたい場合があります。

「一つのアカウントのメールを転送ではなく複数の端末で受信出来ないか?」以前、実際にこんな質問をいただく機会がありました。こちらのお客様はホームページ上でメールフォーム以外に問い合わせ用メールアドレスも分かりやすいように表記していました、メールフォームからは【Cc】で担当者と社長宛て送っていたのですが、直接問い合わせ用メールアドレスに送信された時にも担当者と社長のPCでも受信できないかというのが質問の発端でした。

まさにこんな時にはIMAPは適していると思います。POPでやる場合、上記の通りの問題がありますが、IMAPなら可能なわけです。ただ、私のお客様の場合残念ながらサーバーでIMAPが使えなかったりその他諸般の事情等でIMAPは見送りましたが、今後はIMAPの使用も視野に入れたいと考えています。

そもそもメールフォームがある場合、お問い合せ用アドレスは必要?

すこし脱線しますが、お客様の話が出たので、サイト運用にかかわる部分も書きたいと思います。

筆者的には、そもそもメールフォームがあるなら、別途お問い合せ用アドレスを表記する必要は無いと考えていました、特に営業メールやスパムの為のメールアドレス収集のターゲットにされたりする場合もあります。ただ、お客様としては多くのお問い合わせが欲しい訳なのでメールアドレスも併記という事にしました。

そんな中、お客様の所に訪問した際、「メールがお問い合せ用アドレスだけに来て、担当者と社長に来ない場合があるのですがなぜですか?」ということがありました。

cyotto_R

原因はお問い合せ用アドレスだけに来るメールがフォームから送られた物ではなく、アドレスに直接送信されたメールだからという事でした。稀にフォームではなく直接送られるメールがあったせいで勘違いなされたということでした。結果的にお問い合せメールは受け取れていますし、お客様にご納得いただければ問題はないのですが、運用サイドとしてはやはり、メールアドレスとフォームの同時併記はあまりよくないのかもしれないと感じた事案でした。

特に、web運用している方なら分かると思いますが、お問い合わせがあった時にそのコンバージョンを測定するのは当たり前ですが、それがメールを直に送られてしまうとコンバージョンが測定できません。さらに言うと、直にメールを送られてしまうと、社名や担当者名を書かないで送られてしまったりとあまり良いことは無いでしょう。

メールフォームとお問い合せ用アドレスの表記をするかどうかは、お客様と自分たちの都合といろいろと話し合った上で判断したいところです。

まとめ

少し長くなってしまいましたが、メールは未だお客様との重要な接点の一つなので、運用をしていく上で切っても切り離せないと思います。特にサイトリリース後は比較的トラブルが多い部分です。また色々な質問、設定をお願いされることもあると思いますので、基礎的な部分を抑えておいたほうが良いと思います。


10万いいね!目指してます。

   

   

コメントを残す

*

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>