次に示す特別のURL文字列を使うと一部のブラウザーでその設定値を確認する事ができます。

Debianは、Java (ソフトウエアープラットフォーム)やFlashのみならず、MPEGやMPEG2やMPEG4やDivXやWindows Media Video (.wmv)やQuickTime (.mov)やMP3 (.mp3)やOgg/VorbisファイルやDVDsやVCDs等を取り扱えるブラウザーのプラグインコンポーネントを提供します。Debianではnon-freeのブラウザープラグインパッケージをcontribかnon-freeのコンポーネントのブラウザープラグインとしてインストールできます。

ウェッブサイトによっては使っているブラウザーのユーザーエージェント文字列によって接続を拒否します。こういう状況はユーザーエージェント文字列を誤魔化すことで回避できます。例えば、これは次の内容を "~/.gnome2/epiphany/mozilla/epiphany/user.js"か"~/.mozilla/firefox/*.default/user.js"といったユーザー設定ファイル追加すればできます。

user_pref{"general.useragent.override","Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)"};

こうする代わりに、URLに"about:config"を入力して表示画面内容を右クリックしてこの変数を追加や再設定することでもできます。

スパム(望みも頼みもしないe-mail)問題を封じ込めるために、多くの消費者用インターネット接続を提供するISPは対抗措置を実施しています。

メールシステムを設定したりメール配達問題を解決する際には、こうした新たな制約に配慮しなければいけません。

このような敵意のあるインターネットの状況と制約を考慮して、Yahoo.comやGmail.com等の独立インターネットメールISPはトランスポートレイヤーセキュリティー(TLS)やその前駆者であるセキュアーソケットレイヤー(SSL)を使ってインターネット上のどこからでも接続できるセキュアーなメールサービスを提供しています。

最も簡単なメール設定は、MUA(「メールユーザーエージェント(MUA)」参照)自身がISPのスマートホストにメールを送信しISPのPOP3サーバーからメールを受信する設定です。この設定タイプは機能が充実したicedove(1)やevolution(1)等のGUIのMUAでよく使われます。メールを種類毎にフィルターする必要がある際にはMUAのフィルター機能を使う必要があります。このような場合にはローカルのMTA(「メールトランスポートエージェント(MTA)」参照)はローカル配送のみをする必要があります。

これに代わるメール設定は、ローカルのMTA経由でISPのスマートホストにメールを送信しISPのPOP3サーバーからメール取得プログラム(「リモートメールの取得および転送ユーティリティー」参照)によってローカルのメイルボックスに受信する設定です。メールの種類毎にフィルターする必要がある場合には、フィルター付きのMDA(「フィルター付きのメールデリバリーエージェント(MDA)」参照)を使って別々のメイルボックスにフィルターします。このタイプの設定は、どんなMUAで設定することができるのですが、単純なmutt(1)やgnus(1)等のコンソールのMUA(「メールユーザーエージェント(MUA)」参照)でよく使われます。がある際にはMUAのフィルター機能を使う必要があります。このような場合にはローカルのMTA(「メールトランスポートエージェント(MTA)」参照)はスマートホストへの配送とローカル配送の両方をする必要があります。

スマートホスト経由のインターネットメールに関しては、exim4-*パッケージを次のように(再)設定します。

$ sudo /etc/init.d/exim4 stop
$ sudo dpkg-reconfigure exim4-conf

"スマートホストでメール送信; SMTP または fetchmail で受信する"を選択します。

"送出スマートホストの IP アドレスまたはホスト名:"を"smtp.hostname.dom:587"と設定します。

"DNSクエリの数を最小限に留めますか(ダイヤルオンデマンド)?"に次の内のひとつの返答をします。

" /etc/exim4/passwd.client"を編集しスマートホストのためのパスワードエントリーを作成

$ sudo vim /etc/exim4/passwd.client
 ...
$ cat /etc/exim4/passwd.client
^smtp.*\.hostname\.dom:username@hostname.dom:password

次のようにしてexim4を起動します。

$ sudo /etc/init.d/exim4 start

"/etc/exim4/passwd.client"中のホスト名はエリアスであってはいけません。真のホスト名は次の様にして確認できます。

$ host smtp.hostname.dom
smtp.hostname.dom is an alias for smtp99.hostname.dom.
smtp99.hostname.dom has address 123.234.123.89

エリアス問題を回避するために"/etc/exim4/passwd.client"の中に正規表現を用いています。もしISPがエリアスで示されるホストを移動させてもSMTP AUTHがきっと動きます。

スマートホスト経由のインターネットメールに関してはpostfix文書と重要マニュアルページを読むことから始めるべきです。

postfixとsasl2-binパッケージを次のように(再)設定します。

$ sudo /etc/init.d/postfix stop
$ sudo dpkg-reconfigure postfix

"スマートホストを使ってインターネット"を選択します。

"SMTP リレーホスト (なければ空):"を"[smtp.hostname.dom]:587"と設定します。

$ sudo postconf -e 'smtp_sender_dependent_authentication = yes'
$ sudo postconf -e 'smtp_sasl_auth_enable = yes'
$ sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
$ sudo postconf -e 'smtp_sasl_type = cyrus'
$ sudo vim /etc/postfix/sasl_passwd

スマートホストのパスワードエントリーを作成します。

$ cat /etc/postfix/sasl_passwd
[smtp.hostname.dom]:587     username:password
$ sudo postmap hush:/etc/postfix/sasl_passwd

次に記すようにpostfixを起動します。

$ sudo /etc/init.d/postfix start

dpkg-reconfigureダイアログと"/etc/postfix/sasl_passwd"の中で"["と"]"を使うことでMXレコードを確認せずに指定されたhostnameその物を直接使うように確実にします。"usr/share/doc/postfix/html/SASL_README.html"の中の"Enabling SASL authentication in the Postfix SMTP client"を参照下さい。

メールのトランスポートとデリバリーとユーザーのエージェントが使うメールアドレス設定ファイルが少々存在します。

通常"/etc/mailname"ファイル中のmailnameはホストのIPの一つとして解決できる完全修飾ドメイン名(FQDN)です。解決できるIPアドレスのあるホスト名を持たない可動ワークステーションの場合には、このmailnameを"hostname -f"に設定します。(これはexim4-*とpostfixの両方に有効な安全な選択肢です。)

mailnameを"hostname -f"と設定した時には、次によってMTAで発信元メールアドレスを誤魔化すことが実現できます。

postfixの場合、次に記す追加ステップが必要です。

# postmap hash:/etc/postfix/generic
# postconf -e 'smtp_generic_maps = hash:/etc/postfix/generic'
# postfix reload

フィルターを次の様にして確認します。

基本的なMTA操作が存在します。その一部はsendmail(1)互換性インターフェース経由で実行する事もできます。

vimと組み合わせてmuttをメールユーザーエージェント(MUA)として使うように"~/.muttrc"を使って次に示すようにカスタム化します。

# use visual mode and "gq" to reformat quotes
set editor="vim -c 'set tw=72 et ft=mail'"
#
# header weeding taken from the manual (Sven's Draconian header weeding)
#
ignore *
unignore from: date subject to cc
unignore user-agent x-mailer
hdr_order from subject to cc date user-agent x-mailer
set hostname=spoof.example.org
set from="First Last <username@example.org>"
....

HTMLメールやMSワードのインラインのアッタチメントを表示するように、"/etc/mailcap"か"~/.mailcap"に次に記す内容を追加します。

text/html; lynx -force_html %s; needsterminal;
application/msword; /usr/bin/antiword '%s'; copiousoutput; description="Microsoft Word Text"; nametemplate=%s.doc

getmail(1)の設定はgetmail文書に記載されています。次に示すのがユーザーとして複数のPOP3アカウントにアクセスする著者の設定です。

"/usr/local/bin/getmails"を次のように作成します。

#!/bin/sh
set -e
rcfiles="/usr/bin/getmail"
for file in $HOME/.getmail/config/* ; do
  rcfiles="$rcfiles --rcfile $file"
done
exec $rcfiles $@

次のように設定します。

$ sudo chmod 755 /usr/local/bin/getmails
$ mkdir -m 0700 $HOME/.getmail
$ mkdir -m 0700 $HOME/.getmail/config
$ mkdir -m 0700 $HOME/.getmail/log

各POP3アカウント毎に"$HOME/.getmail/config/pop3_name"設定ファイルを次のように作成します。

[retriever]
type = SimplePOP3SSLRetriever
server = pop.example.com
username =  pop3_name@example.com
password = secret

[destination]
type = MDA_external
path = /usr/bin/maildrop
unixfrom = True

[options]
verbose = 0
delete = True
delivered_to = False
message_log = ~/.getmail/log/pop3_name.log

次のように設定します。

$ chmod 0600 $HOME/.getmail/config/*

"/usr/local/bin/getmails"が15分毎にcron(8)により実行されるようにスケジュールするために、"sudo crontab -e -u <user_name>"と実行して次に記すユーザーのcronエントリーを追加します。

5,20,35,50 * * * * /usr/local/bin/getmails --quiet

fetchmail(1)を設定するには、"/etc/default/fetchmail"や"/etc/fetchmailrc"や"$HOME/.fetchmailrc"を設定します。"/usr/share/doc/fetchmail/examples/fetchmailrc.example"中の例を参照下さい。

maildrop(1)の設定はmaildropfilter文書に記載されています。次に"$HOME/.mailfilter"の設定例を示します。

logfile $HOME/.maildroplog
# clearly bad looking mails: drop them into X-trash and exit
if (    /^X-Advertisement/ ||\
        /^Subject:.*BUSINESS PROPOSAL/ ||\
        /^Subject:.*URGENT.*ASISSTANCE/ ||\
        /^Subject: *I NEED YOUR ASSISTANCE/ )
    to "$HOME/Maildir/X-trash/"

# Delivering mailinglist messages using automatically generated mailbox
if (    /^Precedence:.*list/ || /^Precedence:.*bulk/ )
{
    if ( /^List-Id:[ <]*([^<>]*)[ >]*/)
    {
        MAILBOX="$MATCH1"
    }
    else
    {
        if ( /^X-Loop: *(.*)@(.*)/)
        {
            MAILBOX="$MATCH1.$MATCH2"
        }
        else
        {
            if (    /Return-Path:.*\.debian\.org/ )
            {
                MAILBOX="automatic.debian.org"
            }
            else
            {
                MAILBOX="unknown-list"
            }
        }
    }
    `test -d $MAILROOT/$MAILBOX`
    if ( $RETURNCODE == 1 )
        `maildirmake $MAILROOT/$MAILBOX`
    to "$MAILROOT/$MAILBOX/"
}
to "$HOME/Maildir/Inbox/"
exit

procmail(1)用の"$HOME/.procmailrc"を使う同様の設定を次に記します。

MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/Inbox/
LOGFILE=$MAILDIR/Maillog
# clearly bad looking mails: drop them into X-trash and exit
:0
* 1^0 ^X-Advertisement
* 1^0 ^Subject:.*BUSINESS PROPOSAL
* 1^0 ^Subject:.*URGENT.*ASISSTANCE
* 1^0 ^Subject: *I NEED YOUR ASSISTANCE
X-trash/

# Delivering mailinglist messages
:0
* 1^0 ^Precedence:.*list
* 1^0 ^Precedence:.*bulk
* 1^0 ^List-
* 1^0 ^X-Distribution:.*bulk
{
:0
* 1^0 ^Return-path:.*debian-devel-admin@debian.or.jp
jp-debian-devel/

:0
* ^Resent-Sender.*debian-user-request@lists.debian.org
debian-user/

:0
* ^Resent-Sender.*debian-devel-request@lists.debian.org
debian-devel/

:0
* ^Resent-Sender.*debian-announce-request@lists.debian.org
debian-announce

:0
mailing-list/
}

:0
Inbox/

もしあなたのホームディレクトリーが一杯になりprocmail(1)がうまく機能しなかった場合には、"/var/mail/<username>"からホームディレクトリー内の仕分けられたメールボックスの中に手動でメールを配達しなければいけません。ディスク空間を確保した後に、次を実行します。

# /etc/init.d/${MAILDAEMON} stop
# formail -s procmail </var/mail/<username>
# /etc/init.d/${MAILDAEMON} start

SSHには2つの認証プロトコルがあります。

詳細は、"/usr/share/doc/ssh/README.Debian.gz"とssh(1)とsshd(8)とssh-agent(1)とssh-keygen(1)を参照下さい。

次に示すのがキーとなる設定ファイルです。

次に示す内容は、クライアントからssh(1)接続をスタートします。

もしローカルとリモートで同一ユーザー名を使う際には、"username@"とタイプするのを省略できます。たとえローカルとリモートで異なるユーザー名を使う際にでも、"~/.ssh/config"とタイプするのを省略できます。例えばDebian Aliothサービスでのユーザー名が"foo-guest"という場合には、"~/.ssh/config"が次を含むように設定します。

Host alioth.debian.org svn.debian.org git.debian.org
    User foo-guest

ssh(1)はユーザーにとってより賢明でよりセキュアーなtelnet(1)として機能します。telnetコマンドと異なり、sshコマンドはtelnetエスケープ文字(初期デフォールト CTRL-])に出会うことで中断される事がありません。

sshを通してlocalhostのポート4025からremote-serverのポート25へと、localhostのポート4110からremote-serverのポート110へと接続するパイプを設定するには、ローカルホスト上で次のように実行します。

# ssh -q -L 4025:remote-server:25 4110:remote-server:110 username@remote-server

このようにするとインターネット経由でSMTP/POP3サーバーへとセキュアーに接続できます。リモートホストの"/etc/ssh/sshd_config"中の"AllowTcpForwarding"エントリーを"yes"と設定します。

"RSAAuthentication" (SSH-1プロトコル)もしくは"PubkeyAuthentication" (SSH-2プロトコル)を使うと、リモートシステムのパスワードを覚える必要が無くなります。

リモートシステム上の"/etc/ssh/sshd_config"中に"RSAAuthentication yes"か"PubkeyAuthentication yes"という対応する設定をします。

次に示すように、ローカルで認証キーを生成しリモートシステム上に公開キーをインストールします。

$ ssh-keygen
$ cat .ssh/identity.pub | ssh user1@remote "cat - >>.ssh/authorized_keys"

$ ssh-keygen -t rsa
$ cat .ssh/id_rsa.pub | ssh user1@remote "cat - >>.ssh/authorized_keys"

$ ssh-keygen -t dsa
$ cat .ssh/id_dsa.pub | ssh user1@remote "cat - >>.ssh/authorized_keys"

他のプラットフォーム上で使えるフリーなSSHクライアントがいくつかあります。

SSHの認証キーをパスフレーズで保護する方がより安全です。もしパスフレーズが設定されていない場合には"ssh-keygen -p"で設定できます。

上記のようにパスワードを使って接続したリモートホスト上の"~/.ssh/authorized_keys"中にあなたの公開SSHキー(例えば"~/.ssh/id_rsa.pub")を設定します。

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/<username>/.ssh/id_rsa:
Identity added: /home/<username>/.ssh/id_rsa (/home/<username>/.ssh/id_rsa)

次に示すように、今後リモートパスワードは必要ありません。

$ scp foo <username>@remote.host:foo

ssh-agentのセッションを終了するのに^Dを押します。

Xサーバーの場合、通常のDebianの起動スクリプトは親プロセスとしてssh-agentを実行します。だからssh-addは1回だけ実行される必要しかありません。詳細はssh-agent(1)and ssh-add(1)を参照下さい。

You need to protect the process doing "shutdown -h now"(「システムをシャットダウンする方法」参照)を実行しているプロセスをat(1)コマンド(「タスク1回実行のスケジュール」参照)を使って次のようにしてSSHが終了することから守る必要がある。

# echo "shutdown -h now" | at now

"shutdown -h now"をscreen(1)(「screenプログラム」参照)セッション中で実行しても同様のことができます。

問題に出会ったら、設定ファイルのパーミッションを確認し、sshを"-v"オプションとともに実行します。

rootでファイアーウォールと問題を起こした場合には、"-P"オプションを使いましょう; こうするとサーバーポートの 1 — 1023 を使うのを回避します。

リモートサイトへのssh接続が急に動作し無くなった際は、システム管理者による変更、特に可能性が高いのはシステムメンテナンス中に"host_key"が変更された結果かもしれません。実際にこういう状況で誰も洒落たハックでリモートホストとしてなりすまそうとしていないことを確認した後に、"host_key"エントリーをローカルホストの"~/.ssh/known_hosts"から削除すると再び接続できるようになります。