[ 新規に投稿する ]
サーバー本体の引っ越し５月２０日No.01423
秀まるお2 さん　22/05/17 08:49　[ コメントを投稿する ]
　 　うちのWebサーバー、コミュニテックス、メールサーバーの引っ越しを、５月２０日金曜日の早朝に実行することにします。

　一応、早朝に引っ越し作業して、９時頃には引っ越し完了状態でアクセスできるようになると思います。

　早朝（たぶん６時頃）にコミュニテックスを保守モードにしてデータを新サーバーに引っ越しし、DNSのIPアドレスを新サーバーに書き換えてコミュニテックスも再開させます。旧サーバーにアクセスが来た場合には「引っ越ししました」の案内表示をします。

　ニュース掲載とコミュニテックスフォーラム管理者への案内も今日中に行います。
[ △ ]
RE:01423 サーバー本体の引っ越し５月２０日No.01424
陸 さん　22/05/17 08:57　[ コメントを投稿する ]
　 　こんにちは。

　了解しました。

　1つだけアドバイスです。
　できるのであれば、AレコードのTTLを60秒とか、短くしておくとよいと思います。
　その分DNSサーバーに頻繁にアクセスが発生しますが、DNSが新サーバーに向くのに最低限の時間だけでよくなるはずです。
　切り替えが完了して、2・3日経ってから今と同じ値に戻すとよいと思います。
　現在は600秒（10分）になってるようなので、これでも十分かとは思いますが。

　それでは。
[ △ ]
RE:01424 サーバー本体の引っ越し５月２０日No.01425
秀まるお2 さん　22/05/17 09:17　[ コメントを投稿する ]
　 　陸さんいつもアドバイスありがとうございます。

　TTLは、残念ながら僕では書き換え出来ないです。カゴヤジャパンのコントロールパネルでDNSの書き換えが可能なんですが、いろいろ制限があって、TTLは書き換え不可のようです。

　DKIMを設定する用に「s._domainkey.maruo.co.jp」のようなTXTレコード追加もしようとしたんですが、これも不可でした。サポートに確認してもダメって言われました。

　一応、引っ越し前のサーバーにアクセスが行ったら、そこに「引っ越し中です」って案内を出しつつ、引っ越し先のサーバーに別ホスト名でアクセスできるようにはします。さらには旧サーバーにメールによる書き込みがなされても、それも新サーバーに転送されてちゃんと書き込みされるような仕組みも作りました。

　あと他に不安点として、コミュニテックスのユーザーさんの設定の「メール転送」をONにしてて、会議室の発言をメールで転送するのがちゃんと届くかどうかの不安はありますが・・・・、一応SPFレコードも設定したしSpamhHausの解除申請も通ったので大丈夫だろうと思います。
[ △ ]
RE:01425 サーバー本体の引っ越し５月２０日No.01428
秀まるお2 さん　22/05/20 07:44　[ コメントを投稿する ]
　 　一応ここにテストも兼ねて書き込みさせていただきます。

　コミュニテックスの引っ越し＆DNS書き換えは午前６時頃に完了したつもりでしたが、会議室のHTML形式ファイルの再生成って作業をやるの忘れてました。気づいたのが７時２０分頃でした。それまで会議室の発言が見られませんでした。

　今は大丈夫になりました。
[ △ ]
RE:01428 サーバー本体の引っ越し５月２０日No.01429
でるもんたいいじま さん　22/05/20 11:11　[ コメントを投稿する ]
　 でるもんた・いいじまです。


> Subject: hidesoft.1:01428| RE 01425 サーバー本体の引っ越し５月２０日
>
> 　一応ここにテストも兼ねて書き込みさせていただきます。

> 
> 　コミュニテックスの引っ越し＆DNS書き換えは
> 午前６時頃に完了したつもりでしたが、

> 会議室のHTML形式ファイルの再生成って作業をやるの忘れてました。

> 気づいたのが７時２０分頃でした。

> それまで会議室の発言が見られませんでした。

> 
> 　今は大丈夫になりました。


おつかれさまです。

でもちょっと、変な挙動らしきものがあります。


さきほど
https://www.maruo.co.jp/turukame/3/x10794_.html#10797
を投稿したのですが、なぜか、不必要な改行が入っています。


スクショ↓

http://e231.tokyo/@/20220520-maruo-hikkoshi/

別件の都合でメーラーの設定をUTF-8にしているのですが、

もしかしてその影響でしょうか？


とりあえずもういちど、UTF-8で投げてみます。
[ △ ]
RE:01428 RE01425 サーバー本体の引っ越し５月２０日No.01430
でるもんたいいじま さん　22/05/20 11:13　[ コメントを投稿する ]
　 でるもんた・いいじまです。
念のためISO-2022-JPでも投げてみます。

> Subject: hidesoft.1:01428| RE 01425 サーバー本体の引っ越し５月２０日
>
> 　一応ここにテストも兼ねて書き込みさせていただきます。
> 
> 　コミュニテックスの引っ越し＆DNS書き換えは
> 午前６時頃に完了したつもりでしたが、
> 会議室のHTML形式ファイルの再生成って作業をやるの忘れてました。
> 気づいたのが７時２０分頃でした。
> それまで会議室の発言が見られませんでした。
> 
> 　今は大丈夫になりました。

おつかれさまです。
でもちょっと、変な挙動らしきものがあります。

さきほど
https://www.maruo.co.jp/turukame/3/x10794_.html#10797
を投稿したのですが、なぜか、不必要な改行が入っています。

スクショ↓
http://e231.tokyo/@/20220520-maruo-hikkoshi/

別件の都合でメーラーの設定をUTF-8にしているのですが、
もしかしてその影響でしょうか？

UTF-8のメールは投げましたので、今度はISO-2022-JPで投げてみます。
[ △ ]
RE:01430 サーバー本体の引っ越し５月２０日No.01431
陸 さん　22/05/20 11:23　[ コメントを投稿する ]
　 　こんにちは。

　毎回毎回、メールの件で申し訳ないんですが、今回も1つだけ気になったので。
　フォーラムのメールが送信されているサーバーですが、できれば逆引きレコードを設定したほうがいいと思います。
　移行前は「www.maruo.co.jp」が指定されていたので、こちらを指定しておくとよいかと思います。
　Windowsプランでできるのかわからないんですが、インスタンスのページを開き、「逆引き設定」のところにある「編集」ボタンをクリックして、「www.maruo.co.jp」を指定するといいかと思います。
　ちなみに、今はカゴヤのデフォルトの逆引きレコード「v133-18-225-194.vir.kagoya.net」が指定されています。

　参考：逆引き設定の追加
https://support.kagoya.jp/vps/manual/index.php?action=artikel&cat=40&id=51&artlang=ja

　以上、ご検討いただけると幸いです。

　それでは。
[ △ ]
RE:01430 RE01425 サーバー本体の引っ越し５月２０日No.01432
秀まるお2 さん　22/05/20 11:36　[ コメントを投稿する ]
　 　スクリーンショット確認しました。引用行に余計な改行が入ってるみたいですが、たぶん前々からおかしかったんだろうと思います。

　ぼちぼち調べてみます。
[ △ ]
RE:01431 サーバー本体の引っ越し５月２０日No.01433
秀まるお2 さん　22/05/20 11:37　[ コメントを投稿する ]
　 　逆引きの設定があるのは分かってましたが、何もいじってませんでした。www.maruo.co.jpに設定してみます。
[ △ ]
RE:01432 RE01425サーバー本体の引っ越し５月２０日No.01434
でるもんたいいじま さん　22/05/22 09:34　[ コメントを投稿する ]
　 でるもんた・いいじまです。
＃このメールはISO-2022-JPで投げています。

> スクリーンショット確認しました。
> 引用行に余計な改行が入ってるみたいですが、
> たぶん前々からおかしかったんだろうと思います。
> 
> ぼちぼち調べてみます。

よろしくお願いします。

とりあえず原因の切り分け（UTF-8からISO-2022-JPに変換する際に問題が起きているのか、BASE64デコーダーが出力するCRLFの受け取りをアスキーモードにしていないせいなのか、それとも他に何かあるのか）が必要かと思いますので、簡単なテストデータをご用意させていただきました。

前回のスクリーンショットと同じ
http://e231.tokyo/@/20220520-maruo-hikkoshi/
に本日2022-05-22づけのzipファイルを1つ追加してありますので、よろしければご利用ください。
[ △ ]
RE:01434 RE01425サーバー本体の引っ越し５月２０日No.01435
秀まるお2 さん　22/05/23 15:56　[ コメントを投稿する ]
　 　再現できました。秀丸メールのバグが原因だと思います。

　まず、秀丸メールのバージョンが、Version 7.11正式版以下だろうと思います。

　それで、送信済みフォルダに残ってる投稿したメールを見ていただくと、引用行の右端の改行記号が、普通の下矢印じゃなくて、右下ななめ方向の矢印になってると思います。

　そういう改行になってると、メールの改行コードが２倍になってしまうバグがありました。

　最新βに入れ替えていただくと、以後大丈夫だと思います。すみませんがとりあえず最新βに入れ替えて、この発言にコメント投稿お願いしたいです。
[ △ ]
RE:01435 RE01425サーバー本体の引っ越し５月２０日No.01436
秀まるお2 さん　22/05/23 16:08　[ コメントを投稿する ]
　 　すみません。Version 7.12βの最新βでも、V7.11正式版で作成した送信済みメールを元にしてテストしたらダメでした。

　V7.12βで返信メールを作成すると、引用部分の改行コードが右下ななめじゃなくて、下方向の矢印になりまして、それだと再現しないと思いますが、一応これもテストしてみます。
[ △ ]
RE:01436 RE01425サーバー本体の引っ越し５月２０日No.01437
秀まるお2 さん　22/05/23 16:15　[ コメントを投稿する ]
　 　やっぱり秀丸メールとは関係なく、utf-8で投稿されたメールのデコードの問
題のような気がします。とにかく再現方法は分かったのでなんとか修正してみま
す。二転三転の書き込みでお騒がせしてすみません。
[ △ ]
RE:01434 メールが BASE64 でエンコードされているNo.01438
Iranoan さん　22/05/23 21:21　[ コメントを投稿する ]
　 秀まるおさん今日は Iranoan です

どこあてに投稿するのが妥当のか? が良くわからないのですが、
この返信元のメール
> でるもんた・いいじまです。
> ＃このメールはISO-2022-JPで投げています。
あたりから、
> Content-Type: text/plain; charset=iso-2022-jp
> Content-Transfer-Encoding: base64
と BASE64 でエンコードされて送られています

仕様を変更したのならそれはそれで構いません
「意図せずそうなっているなら、お知らせしたほうが良いかも」と持った次第です

また秀丸メールを使っているユーザは、そもそもデコード済みデータが保存されるの関係ありませんが、それ以外の MUA を使っているユーザは、BASE64 でエンコードされていると、grep などの処理が面倒になるので、困る人がいるかもとも考えました

逆に意図して BASE64 でデコードしているなら、
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
になれば、JIS 外文字が使えるのでやり取りがしやすくなり有り難いです
[ △ ]
RE:01438 メールが BASE64 でエンコードされているNo.01439
秀まるお2 さん　22/05/24 08:39　[ コメントを投稿する ]
　 　コミュニテックスのメール配信はここ何年もいじってませんが、しいて引っ越しによって変更されたとしたら、メールサーバーが、以前のIMail ServerからPMailServer Pro2に変更したってのはあります。しかし、メール本文のエンコードがbase64になるのは、以前からの仕様です。しいて言うなら同じ処理は秀丸メールでもやってます。

　メール本文の中の１行の長さの最大がある程度以上の長さになってる場合はbase64エンコードするようにしています。そうしないと、古いメールサーバーとかで１行が1024バイトくらいでぶった切られてしまうことが以前あったからだと思います。（はっきりそうなった事例を把握してた訳じゃないかもしれないけど）

　最近の秀丸メールで、送信するメールの折り返し無しが標準になったり他のメールソフトでもそういう動作になってきてるので、base64エンコードされるケースが増えたんだと思います。
[ △ ]
RE:01437 RE01425サーバー本体の引っ越し５月２０日No.01440
秀まるお2 さん　22/05/24 09:06　[ コメントを投稿する ]
　 　テスト環境でテストしても再現せず、本番マシンでテストして再現し、いろいろ調べたら、どうもPMailServer Pro2のバグのような気がします。

　メールボックスに入ってる一時ファイルに余計な改行が入ってるようなので。

　そっちに問い合わせしてみます。
[ △ ]
RE:01439 メールが BASE64 でエンコードされているNo.01441
Iranoan さん　22/05/24 13:32　[ コメントを投稿する ]
　 秀まるおさん今日は Iranoan です
> 　メール本文の中の１行の長さの最大がある程度以上の長さになってる場合はbase64エンコードするようにしています。そうしないと、古いメールサーバーとかで１行が1024バイトくらいでぶった切られてしまうことが以前あったからだと思います。（はっきりそうなった事例を把握してた訳じゃないかもしれないけど）
JIS でなぜデコードされているのだろう? と思ったのですが、一行の長さでも切り替えているんですね
失礼しました
[ △ ]
RE:01440 RE01425サーバー本体の引っ越し５月２０日No.01442
秀まるお2 さん　22/05/24 15:14　[ コメントを投稿する ]
　 　作者さんの所でも確認してもらったので、PMailServer2側のバグで間違いないようです。僕の方でも対処は可能なんですが、面倒なのでPMailServer2側で対処されるのを待とうと思います。

　とりあえず現状でも改行が増えるだけで大した害は無いと思うので、そのまま気にしないで書き込んでほしいです。
[ △ ]
[ 新規に投稿する ]