お申し込みからの作業の流れ

注目

サーバー初期構築/各種設定/サーバーマネージメント(保守契約)に関して
お客様のお申し込みからの作業の流れは以下のとおりです。

(1)お申込みページからお申し込み頂きますと、まず控えのメールが自動送付されます。

(2)次にこちらから「環境確認から作業開始までの流れ」というメールが送られます。

お送りしたメールにはお客様のサーバー情報をご記入頂くフォーマットがあります。
ご記入頂く情報は以下の項目です。

・対象サーバーIPアドレス:
・接続用アカウント(ユーザー名):
・接続用アカウントパスワード:
・root パスワード:
・SSHポート番号:

※ユーザー名は、SSHユーザー名あるいはFTPユーザー名です。
※お送りしたメールに指定のフォーマットでご返信を頂きます。

(3)お客様のサーバー情報をお送り頂きますと、ログインして環境チェックをいたします。

これはお申し込みの作業が可能かどうかを判断する重要な作業になります。
特殊な環境になっている場合やインストール済みのミドルウェアバージョン等によって、稀にご依頼の作業ができないような環境もあります。それを判断するものです。
これはお申し込みから30分程度で完了することが多く、大抵1時間以内です。

(4)環境チェックで問題のない場合、ご請求書メールをお送りいたします。

ここで初めてお申し込み確定・ご成約となり、費用のお支払いへと進みます。

(5)ご請求書メールが届きましたら費用をお支払い(指定口座へお振り込み)頂きます。

(6)費用の着金を確認いたしまして、お申し込みの作業開始となります。

作業は数時間(1時間~半日)で完了することが多く、大抵1日以内です。

ご利用条件はこちら

サーバー設定・サーバー管理のご利用条件

 

サーバー設定・サーバー管理のご利用条件

注目

サーバー初期構築/各種設定/サーバーマネージメント(保守契約)に関して
当サービスのご利用条件は以下のとおりです。

・対象OS: CentOS 6(RHEL6系)/ CentOS 7(RHEL7系)
・インターネット経由でSSH接続が可能であること
・root権限あり(SSHでログイン後 root で作業ができること)
・Parallels Panel, Plesk, cPanel がインストールされていないこと

特に、インターネット経由でSSH接続が可能であることは重要です。
これは、OSインストールとネットワークの初期設定は請け負っていないことを意味します。

当サービスがサーバー初期構築/各種設定として想定しているのは、専用サーバーあるいはVPSあるいはクラウドのインスタンス生成後、Webサーバーとして機能するためのミドルウェア(Apache、MySQL、メール関連やFTP機能等)の設定がされていない状態からそれを初期設定していく作業の代行です。
サービス一覧はこちら
サーバー初期構築/各種設定のページ

また、当サービスがサーバーマネージメント(保守契約)として想定しているのは、サーバーをクリーンに保つための日々の目立たない地味な管理作業(各種サービスが正常稼働しているか、問題はないかのリアルタイム状態監視と不具合発生時の即対応)および、ユーザー作成、Webサイトのバーチャルドメイン設定(サイト開設時の初期設定)、メールのバーチャルドメイン設定、MySQLデータベース作業等々諸々の作業代行です。
サービス一覧はこちら
サーバーマネージメント(保守契約)のページ
 ◎フルマネージメントの作業代行サポート範囲参照

お申し込み方法はこちら

お申し込みからの作業の流れ

 

メールアドレス抽出の正規表現

■ Procmailで使えるメールアドレス正規表現

From、Return-Path などからメールアドレスを抽出する正規表現、意外と難しいです。
結論から言えば、正規表現一発ではできません。

例えば、こんな反則的なメールアドレスが実際にあったりして

Return-Path: <a-b-c._.d=efg@hogehoge.com>

例えば、メールアドレスらしきものが2つ含まれていたりして

From: "I-am@office.work" <a-b-c._.d=efg@hogehoge.com>

こんなやつも引っ掛けるには以下のようにします。

echo 変数 | grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1

すると、こう展開されます。

echo '"I-am@office.work" <a-b-c._.d=efg@hogehoge.com>' \
| grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1

結果
a-b-c._.d=efg@hogehoge.com

ProcmailでFromとReturn-Pathの違いからスパムを弾くレシピ

スパムメールでは From はよく詐称されます。
From はあてにならないので From でブラックリスト判定するのは意味ないです。
やるなら Return-Path でブラックリスト判定のほうがマシ。
でも、ブラックリストを追加するのも疲れるしイタチごっこです。
もっとうまい方法がないか・・・

■ ProcmailでFromとReturn-Pathの違いからスパムを弾くレシピ

From と Return-Path が違ったらもう削除してしまうなら以下


# ヘッダからメールアドレス抽出して変数へ

:0
* ^Return-Path:\/.*
RETUERN_PATH=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

:0
* ^From:\/.*
ORIGINAL_FROM=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

:0
* ^To:\/.*
ORIGINAL_TO=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`

# スパム判定

# From と Return-Path が違う
:0
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
/dev/null

でもこれだと、いろんなものが弾かれてしまいすぎ。
いやいや、それはちょっと厳しすぎると思う場合、
From と To が同じときスパム確定にするなら以下


ヘッダからメールアドレス抽出する部分は上記と同じ
・・・

# From と To が同じ (スパム確定) - 削除
:0
* $ORIGINAL_FROM ?? $ $ORIGINAL_TO
/dev/null

# From と Return-Path が違う - 目印を付けるだけ
:0fw
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
| formail -i "Procmail-Match-From-Return-Path: unmatch!" \
| formail -i "Procmail-Return-Path: $RETUERN_PATH" \
| formail -i "Procmail-From: $ORIGINAL_FROM" \
| formail -i "Procmail-To: $ORIGINAL_TO"

あとは、総務省の迷惑メール対策室へ自動で転送したり
From と Return-Path のドメインも判定したり・・・


######## ヘッダからメールアドレス抽出

:0
* ^Return-Path:\/.*
{
  RETUERN_PATH=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
  RETUERN_PATH_DOMAIN=`echo "$RETUERN_PATH"|sed -r "s/.*@([-a-zA-Z0-9_.]+).*/\1/"`
}

:0
* ^From:\/.*
{
  ORIGINAL_FROM=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
  ORIGINAL_FROM_DOMAIN=`echo "$ORIGINAL_FROM"|sed -r "s/.*@([-a-zA-Z0-9_.]+).*/\1/"`
}

:0
* ^To:\/.*
{
  ORIGINAL_TO=`echo "$MATCH"|grep -o -E "[-a-zA-Z0-9_.=+]+@[-a-zA-Z0-9_.]+" | tail -n 1`
}

######## スパム判定

# From と To が同じ (スパム確定) - 削除
:0
* $ORIGINAL_FROM ?? $ $ORIGINAL_TO
/dev/null

# From と Return-Path が違う
:0
*! $ORIGINAL_FROM ?? $ $RETUERN_PATH
{
  # Return-Path ドメインが From ドメインを含まない
  :0fw
  *! $RETUERN_PATH_DOMAIN ?? $ $ORIGINAL_FROM_DOMAIN
  | formail -i "Procmail-Match-FromDomain-Return-Path: unmatch!"

  :0Efw
  | formail -i "Procmail-Match-From-Return-Path: unmatch!"

  :0fw
  | formail -i "Procmail-Return-Path: $RETUERN_PATH" \
  | formail -i "Procmail-From: $ORIGINAL_FROM" \
  | formail -i "Procmail-To: $ORIGINAL_TO"
}

# spamassassin
:0fw
*!^X-Spam.* 
| /usr/bin/spamc

:0c
* ^X-Spam-Flag: YES
{
  # 総務省の迷惑メール対策室へ転送
  # これで捨てずに自分も受信する

  SENDMAILFLAGS="-oi -f $RETUERN_PATH"
  ! meiwaku@dekyo.or.jp
}

こんな感じ。

qmail サポート対象外とします

今年から qmail をサポート対象外とします。

■ qmailとは

qmail とは、ライフサイクルを終えた旧式のメールサーバーです。
1998年に本家が開発サポートを終了しており、その後は有志によってのみ追加機能パッチなどが細々と出ておりましたが、さすがに昨今の時流には対応できていない過去の遺物になっています。
新しい驚異には対応できずセキュリティホール等の修正パッチもリリースされないため、特別な事情がない限り qmail は避けるべきです。

■ qmail の保守・障害対応について

2019年1月末をもって、当サービスでは保守・障害対応をしないこといたしました。
しかしながらどうしてもという事情がある方のために環境構築だけは特別料金で請け負う形を残しておきました。

・qmail/vpopmail/qmailadmin 構築

(メールサーバーをqmailにしバーチャルメール環境を追加します。ただしアフター保守・障害対応の対象外)
費用についてはこちらの料金表を参照ください。

他社の作業代行費用調査その3

【 2017/08/09 現在の調査です 】

以前の調査はこちら
他社の作業代行費用調査その1
他社の作業代行費用調査その2

───────────────────────────────────

■Zenlogic(ゼンロジック)

───────────────────────────────────
レンタルサーバーのファーストサーバー Zenlogic のプランです。

https://zenlogic.jp/option/operation/price.html

継続型サービス
(フルマネージドオプション)

・Zenlogicホスティングフルマネージド    120,000円/年
・Zenlogic CDNフルマネージド             60,000円/年
・Symantec Email Security.cloud フルマネージド 60,000円/年

作業実施時間 9:00~18:00 ※時間外対応 30,000円

スポット型サービス
(作業代行(スポット型))

・WEBサーバー初期設定           1回 30,000円~
・メールサーバー初期設定        1回 30,000円~
・ネームサーバー設定            1回  5,000円~
・Zenlogic CDN 初期設定         1回 30,000円~
・Symantec Email Security.cloud 初期設定 1回 30,000円~

・各種WEBアプリケーションセットアップ 1回  5,000円~
(WordPress, Movable Type, EC-CUBE等)
・サイボウズ Office バージョンアップ  1回 20,000円~

・他社サービスからの移行        1回 100,000円~
・データバックアップ            1回  30,000円~
・データリストア                1回  30,000円~
・サイトデータ複製              1回  20,000円~
・ファイル一括削除              1回  10,000円~

※上記はオプションサービスで、Zenlogic ホスティングのサーバー契約の料金とは別のようです。

ざっくり概ねベリーキュートの5倍~10倍の料金設定だと思われます。
フルマネージド 120,000円/年となっていますが、ベリーキュートでは 24,000円/年、
WEBサーバー初期設定 1回 30,000円~となっていますが、ベリーキュートでは 3,000円~、
スポット作業に関しては概ねベリーキュートの10倍です。
基本やることは同じなので、サーバーをここで借りても保守だけベリーキュートにする手もあります。

BINDの複数の脆弱性対策 (CVE-2017-3136他)

先日明らかにされたセキュリティアラート: CVE-2017-3136/3137/3138
ISC BIND に複数のサービス運用妨害 (DoS) の脆弱性

対策実施について

原文はこちら
CVE-2017-3136(英文)
https://kb.isc.org/article/AA-01465
CVE-2017-3137(英文)
https://kb.isc.org/article/AA-01466
CVE-2017-3138(英文)
https://kb.isc.org/article/AA-01471

JVNVU#97322649
ISC BIND に複数のサービス運用妨害 (DoS) の脆弱性
http://jvn.jp/vu/JVNVU97322649/index.html

本件の問題点と対策は以下の通りです。

続きを読む

総務省へ迷惑メール情報提供するプラグイン

総務省へ迷惑メール情報提供するプラグインのご紹介です。
ダウンロード http://plugin.antispam.soumu.go.jp/

迷惑メールとは
「特定電子メールの送信の適正化等に関する法律(平成14年法律第26号)」に違反していると思われる以下のようなメールです。

・送信に同意した覚えのない広告宣伝メール
・表示義務違反メール
・送信者情報(電子メールアドレス、IPアドレス、ドメイン名 等)偽装メール

総務省は迷惑メール対策に取り組んでいます。

総務省|電気通信消費者情報コーナー|迷惑メール対策
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html

特定電子メールの送信の適正化等に関する法律のポイント
http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/pdf/m_mail_pamphlet.pdf

【主要な罰則】

送信者情報を偽った送信
1年以下の懲役または100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して3000万円以下の罰金)
同意のない者への送信
総務大臣及び内閣総理大臣による命令。命令に従わない場合、
1年以下の懲役または100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して3000万円以下の罰金)
同意の記録義務違反
総務大臣及び内閣総理大臣による命令。命令に従わない場合、
100万円以下の罰金
(法人の場合は行為者を罰するほか、法人に対して100万円以下の罰金)

続きを読む

SPF判定をパスするスパムメールの例(SPFは意味がない証拠)

前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回は、実際に筆者に送られてきたスパムメールがSPF判定をパスしている例を示します。
SPF判定をパスするスパムメールは非常に多く、SPF判定は何の意味もないのが現実です。

■ 送られてきたスパムメールの例

From: 【ECショップ】ご注文の確認につきまして <zqtafc5pn5ww8umr0kew8d@virk.dj8eiidz78rxjk.site>
To: xxxxx@yahoo.co.jp
Subject: 【xxxxx@yahoo.co.jp】様 ご注文の確認につきまして

xxxxx@yahoo.co.jp 様


ご注文を頂きまして誠に有難う御座います。きゆおをにろつに

お取引終了まで短い間では御座いますが何卒宜しく御願い申し上げます。きゆおをにろつに

今回ご注文を致しました商品のご確認をお願い致します。きゆおをにろつに



http://xxxxx.yg58zymnjgh83.com/Q6a0d-NDc2-ODAxMTEy/NTAyMwQ6a0dQ6a0d/



尚、御発送に際しましては改めてメールにてご案内申し上げます。きゆおをにろつに
何卒宜しく御願い申し上げます。きゆおをにろつに






■配信停止
http://xxxxx.yg58zymnjgh83.com/Q6a0d-NDkz-ODAxMTEy/NTAyMwQ6a0dQ6a0d/

きゆおをにろつに
4374きゆおをにろつに

(ただし、xxxxx は伏せ字)

■ 送られてきたスパムメールのヘッダ解析

続きを読む

GoogleのGmailのIPv6逆引き判定が迷惑な問題

前に、SPFレコードでドメインの正当性を判定する方法が逆にスパムを増長させる問題について書きましたが、今回はさらに突っ込んでGoogleのGmailの厳しい判定が迷惑な問題について書きます。

参考)

一括送信ガイドライン – Gmail ヘルプ
https://support.google.com/mail/answer/81126

Googleだけに限ったことではないですが、Gmailはシェアが多いのでトラブルが目立ちます。

トラブルというのは【Gmailに送ると届かない】という問題です。
これはGmailが、迷惑メール対策として判定が厳しいためです。

Googleは最近、自分たちのガイドラインに【何が何でも従わせる】という強引なやり方をするようになりました。
事実、Googleのガイドラインに従わないメールはリジェクト(受信拒否)されるトラブルが多く、最近 Gmail / G Suite(旧 Google Apps)のメールに関して問い合わせが多いです。
仕事の取引先からの必要なメールでもGoogleのガイドラインに反していると届きません。
迷惑メールフォルダに振り分けられるならまだしも、勝手にリジェクトされて気付かないままになります。

続きを読む