管理者は朝が早い。こっちに居るときは、朝食を食べて、新聞受けから新聞を取って大学に出勤する。大学でコーヒーを飲みながら新聞を読むということにしているわけだ。勤務時間開始より早い時間だから文句を言うな。しかし、忙しいときは新聞を読むことなどできず、机の上に放置していると、毎日来る某女性職員あるいは某女性准教授がまず最初に読む訳だ。ときどき持参しないと両者とも「新聞は！！」と文句を言う。
ま、これとは別に、催すとトイレに持参して読むことがある。朝だからな。
あっちに居るときは、朝食のあと、コンビニによって新聞を買って大学に出勤する。ここでもコーヒーを飲みながら新聞を読むことになる。あっちでは部屋に入って新聞を要求する女性なんかいない。こっちとおなじように催すとトイレに新聞を持って出かける。
こっちの学系棟のオフィス棟のトイレは、何年か前、再構築され、ヒトがいるときに照明が自動点灯するようになっている。あっちの大学も同様の自動点灯トイレがある。こっちのトイレで新聞を読んでいると時間がくると照明がきえちゃう。個室にヒトがいるかどうかを検出していない。通路にヒトがいることを検知しているようだ。センサーと思える部分の角度を個室に向けたがだめだ。じっとしているからかもしれないので、動いてみるがだめだ。新聞を読めなくなる。しかしあっちのトイレはそういうことがない。新聞をゆっくり読む時間がある。センサーが個室のヒトを検知しているのか、それとも点灯時間を長く設定してあるのかはわからない。
つまり、あっちのほうがトイレで新聞を読む余裕をあたえているのに、筑波の医学は新聞を読むなんてもってのほかなのだ。ゆったりしたほうが当然好きだ。

au とか docomo が許していた／いるメアドで「@の前の文字列にドットが連続してあってはいけない、@の直前にドットがあってはならない」（SHOULD NOT）というRFC規則に引っかかるメアドを許している件である。auもdocomoも新規に作るメアドではRFCに準拠したものでないと許可しないようになったが、以前に作成したメアドはそのまま使っていいことになっている。
多くのパソコンで使うメールソフトはRFC規則に沿っていないメアドをはじくようになっているので、途中のSMTPサーバや最終的に受信するauとかdocomo のサーバが受け付けていても、メールを送ることができない。メールソフトはアドレスの入力間違いとしてはじいてしまうのだ。
しかし、RFC2821の2.3.10 では@前の文字列であるloca-part の意味の解釈および割り当ては、そのアドレスのドメイン部で指定されているホストによってのみ行われなければならない(MUST)。とあるのでau とかdocomoの勝手であってなんら問題はないはずである。
RFCのどこに、上記のような規則が書いてあるのか、調べてみるが、よくわからない。
結論からいうとメールアドレスの書式というページに書いてあることのようだ。
このページの最後に個人的な雑感というのがあって、この感想に賛成だ。RFCの文書のどこにこのような規則があるのかよくわからない。
メールソフトで、この規則にのっとっていないメアドを ”  ”  でくくって送ると届くはず。”　”内は文字列として文法上の記号等があっても無視できるからである。
事実、Thunderbird でこのようなメアドから来たメールのヘッダーを見ると、
From: “xxxxxx..yyyyy”@ezweb.ne.jp とFrom欄を解釈し、 ” ” でくくっていて、単純に返信すると
To: xxxxxx..yyyyy@ezweb.ne.jp
に送信している。問題なく送受信できている。Outlook なんかはだめなようだ。
mailman もだめなようで、このようなメアドを登録すると、さきに書いたように届かない。
mailman では登録すらできない。” “でくくると登録ができるが、どうやらとどかないようだ。送信エラーもこない。送られたのだがau とか docomo が捨てちゃうのだろうか？届かないと学生は言うがとどいているのかもしれない。もし捨てちゃうようだったらauやdocomoはものすごくたちが悪いことになる。
パソコンからThunderbirdで
“xxxxxx..yyyyy”@ezweb.ne.jp　あるいは
xxxxxx..yyyyy@ezweb.ne.jp　で送付すると届く。ということはauは” “をちゃんと解釈してくれているようだ。
しかしmailmanからだと
“xxxxxx..yyyyy”@ezweb.ne.jp　は登録できるが、届かない。
xxxxxx..yyyyy@ezweb.ne.jp　は登録ができない。
mailmanの設定かな？ ちがったPostfix のせいだ。ためしたのはハイフンで始まるメアドだったからだ。
http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#allow_min_user　によると；
allow_min_user (デフォルト: no)
受信者アドレスが最初の文字として `-‘ を持つことを許可します。コマンドラインでEメールアドレスを渡すソフトウェアでの事故を避けるため、デフォルトではこれを認めません。そのようなソフトウェアは悪意のあるアドレスと正しいコマンドラインオプションを区別できないでしょう。これは “–” オプションターミネータをコマンドラインに入れることで防げますが、一貫して全体に強制するのは困難です。
で、デフォルトの設定だからだ。
mike (MacOSX)の場合、しかしながら
/etc/postfix/main.cf　にallow_min_user　の記述がない。

au とか docomo は携帯メールアドレスのユーザ名の文字列に　.　(period/ドット）を連続してもいいとか、＠の前につけてもいいとかにしてあった。最近は禁じているようだが。
しかし、以前からのユーザのユーザ名がRFCの規則に接触していてもそのまま許している。こういうアカウントに対してはメールが送付できない。
管理者が担当している卒研の学生への連絡を行うため、メーリングリストを立ち上げた。学生にメールアドレスをよこせといったら、まず送ってきたアドレスはすべて携帯のメアド。一括して登録してしまった。
メールを送ってから、特定の学生にとどかないことが判明した。そのメアドを見たら . が２つ連続している。使えないのだからメーリングリストから削除しようと思って、mailman の管理画面から削除しようとしたが、削除できない。

この退会のチェックボックスをチェックして変更を送信しても消去されないのだ。何故かはわからん。メールでリストの一覧を取得しても残っている。ちゃんとしたアドレスの場合、このチェックボックスで削除できる。
あまりつかわないのだが、リストに登録しているメアドを得るのは；

リストに登録してあるメールアドレスとメモ欄に記入した情報が書いたメールが返ってくる。ここに記載されたままなのだ。
悩んでいたのだ。
まとめて退会　というのがあるのに気がついた。まとめなくても１つだけでもできるかな？とおもって退会メアドのリストに１行だけ、該当アドレスを記入して、変更を送信したら消えてくれた。へんなの。
しかし、au とか docomo は規則に従わないメアドは使えないようにしてくれよな。携帯のメールを使うのは若者で、めちゃめちゃなアドレスを使うんだから。happyponpon とかchunkなんちゃら、fight_the_future とか pride_before_crushとかかふざけた名前が多いからな。

医学のサーバのWebメールであるsquirrel mail で、届いたメールに対して転送あるいは返信を選択すると引用部分が文字化けする。
SquirrelMail バージョン 1.4.21だ。どうやら文字コードが明示されていないときに生じ易い。つまりサーバからのレポートとかで生じ易いようだが、一般のメールでも起こるらしい。しつけの悪いメールソフトからなのだろうか。
例えばNASのレポートのような場合だ。
############
バックアップログ報告
バックアップタスク1を開始しました。
[TeraStation PRO情報]
TeraStation PRO名称: T-STATION21 (TS-HTGL/R5)
時刻: 2011/08/25 03:00:02
設定画面: http://192.168.100.5/
############
というメールに返信しようとすると
############
> ????????????????????
> ??????????????????1????????????????
> ????????????????: ????????
> [TeraStation PRO????]
> TeraStation PRO????: T-STATION21 (TS-HTGL/R5)
> ????: 2011/08/25 03:01:15
> ????????: http://192.168.100.5/
############
となるわけだ。
squirrelmailの設定オプションに
$lossy_encoding        = true;
があって、マニュアルによると
SquirrelMail supports the $lossy_encoding option since 1.4.4 and 1.5.1,
which allows charset conversions when the output charset does not
support all symbols used in the original email charset.
とあり、これを読む限りはtrueにした方がよさそうに見えるのが、ど
うも日本語文字コード間の変換と相性が悪いようで、こちらを”false”にすると文字化けが解消する。
と、本年度から委託した業者から連絡があった。
mike (MacOSXServer)の場合
/etc/squirrelmail/config　に
config.php　があってこの２８行目に
$lossy_encoding        = false;
となっている。デフォルトでfalseになっていた。なぜkibanではtrue になっていたのかはわからない。