SEはただいま営業中

ありきたりのことなのですが、 好きな言葉があります。 「頭は下げるためについている」、「挨拶はコストゼロ」、「実るほど頭をたれる稲穂かな」 「笑顔のコストはゼロ」、「苦労は背負い込む」、「不具合にこそ商機あり」、「不可能は解決する方法を生む出せば可能になる」 「技術的な理由で断られた仕事、納期と予算だけ何とかしてくれれば何とかします」

システムの設計管理をしていると予想外の事態が発生したり、ミスから発生する不具合が発見されたりします。 前者では海外などからの高頻度のアクセス、セキュリティの裏を狙うアクセスだったり、後者ではシステムの設計の落ち度であったり。 安全工学では不幸な事態は起きないようにすることは目標にはしているがおきた場合にどのように対処するかということを考えの基本においている。 客先との関係では起きたこと事態を真摯に受け止め説明することと緊急対応が肝要です。 非を認めるだけが営業ではないけれど、心理的な対立が顧客との間にあっては何事も前に進みません。 誤魔化すことなく、事実を正確に、正直に、早急に顧客に説明すべきです。 報告する点は、正確にわかっていること、予想していて確実でないことを混ぜて報告せず分けて話すことが大切です。 安全工学については別途

送信者、送信サーバー、返信宛メールアドレス、などが一致していない場合は成りすましメールと判断されます。

インターネットでは大きな組織が一括で管理している仕組みではなく多くの組織が一定の取り決めに従って全体として機能するようになってきます。そのなかで成りすましという問題があがってきました。

これに対してauが出しているコメントを抜粋して紹介します。

---

送信ドメイン認証SPFレコードについて

概要

メール送信時のお願い

技術仕様

送信ドメイン認証

SPFレコードについて

送信ドメイン認証SPFレコードとは、メールを送信するサーバの情報をDNSサーバ上で公開し、送信されたメールのドメイン名とDNSサーバのSPFレコードとの整合性を受信サーバ側で確認することで、そのメールが正当なメールサーバから送信されたものかを認証する技術です。これにより、正当なメールサーバから送信されたメールと「なりすましメール」とを判別することが可能となります。その為には送信されているメールのドメインと送信IPアドレスの関連をSPFレコードに記述していただく必要がございます。

詳細は以下サイトの送信ドメイン認証技術導入マニュアルを参考にしてください。

送信ドメイン認証技術導入マニュアル

EZwebにSPFレコードを公開してメールを送信される場合の注意事項

SPFレコードの確認には、エンベロープFromに記述されているドメインを使用致します。

エンベロープFromが記述されていない場合には、SPFレコードの確認は、HELOドメインを使用しますので、EHLO/HELOにも正しい送信ドメインを記述されますようお願い致します。

EZwebにメールを送信するドメインのSPFレコードはTXTレコードで公開してください。

IPアドレスの指定にはIPv4を使用してください。

※お客さまが迷惑メールフィルターの「なりすまし規制 (高)」をご利用になる場合、エンベロープFromに加えてPRAに記述されているドメインを使用したSPFレコードの確認を行い、SPFレコードが無い場合はメールを拒否します。

PRAとして以下の順にヘッダをチェックします。

Resent-Sender → Resent-From → Sender → From

SPF公開の注意事項

SPFレコードが255文字 (ASCII) 以内に収らない場合には、互換性の問題がありますので、includeなどを使用することにより255文字以内での設定をお願い致します。

SPF Website (英文)

SPFレコードのサンプル (一般的な定義例)

"v=spf1 ip4:192.xxx.xxx.0/24 -all"

[BINDでの設定]

example.org. IN TXT "v=spf1 ip4:192.xxx.xxx.0/24 -all"

※"v=spf1 +all"や広いIPアドレスの空間を記載するなど、実質どのIPからでも認証がPASSとなる記載は受信不可となる場合があります。

 

"v=spf1 -all"

[BINDでの設定]

example.org. IN TXT "v=spf1 -all"

1つのドメインに対して複数のSPF1レコードを公開している

(誤)

example.org. IN TXT "v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 ~all"

example.org. IN TXT "v=spf1 a:mx01.example.org ~all"

example.org. IN TXT "v=spf1 a:web.example.org ~all"

(正1)

example.org. IN TXT "v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 a:mx01.example.org a:web.example.org ~all"

(正2)

example.org. IN TXT "v=spf1 ip4:10.0.3.0 ip4:10.0.3.1 a:mx01.example.org a:web.example.org ~all"

example.org. IN TXT "spf2.0 ip4:10.0.3.0 ip4:10.0.3.1 a:mx01.example.org a:web.example.org ~all"

ip4とすべきipv4になっている

(誤)

example.org. IN TXT "v=spf1 ipv4:10.0.3.0 mx ~all"

(正)

example.org. IN TXT "v=spf1 ip4:10.0.3.0 mx ~all"

SPFレコードの確認 (nslookupコマンド)

nslookup -q=txt example.org

SPFレコードの確認方法

auケータイ（4G LTEケータイ除く）での確認方法

auの携帯電話にEメール（@ezweb.ne.jp）を送付し、ヘッダ閲覧システム (Eメール設定 → その他の設定 → 5 Eメールヘッダ情報表示 (通信料有料)) にアクセスしていただくと、以下のヘッダで認証結果がPassになっていることをご確認いただくことができます。

2010年12月まで

X-SPF-Auth: Pass

2010年12月以降

Authentication-Results: example.org;

spf=pass smtp.mailfrom=user@example.org;

sender-id=pass header.from=user@example.org

auスマートフォン/iPhone/4G LTEケータイでの確認方法

auWebメールにてご確認いただけます。

auのスマートフォン/iPhone/4G LTEケータイにEメール（@ezweb.ne.jp）を送付し、auWebメールへアクセス（ログイン後）後、受信箱にて該当メールの「ヘッダーを表示」いただくと、以下のヘッダーで認証結果がPassになっていることをご確認いただけます。

Authentication

-results ezweb.ne.jp; spf=pass reason=policy; sender-id=pass reason=policy

---

以上がauからのコメントですが他のプロバイダーでも同様な内容で適用できます。

多くの事務所ではほとんど蛍光灯が照明器具として使われています。

蛍光灯の効率的な使い方、安い使い方はご存知でしょうか？

１．安価な蛍光灯の間を購入しない。

安価な蛍光灯の間は寿命が短くまた動作が不安定です。

最近ではインバーター式の器具が増えたため寿命まじかかの管の効果gんが遅れがちになっていると思います。

蛍光灯は寿命に近くなると動作が不安定になり、安定期を劣化させ、消費電流が増えるため、できるだけ寿命の長い蛍光灯の管を使用しないとコスト的な面でデメリットがあります。

安定器の交換費用名危惧と交換とほぼ等しい費用がかかります。

また、寿命が短くなると省エネであるはずの蛍光灯の電気代が電気代がかさみます。

２．蛍光灯の白色は、昼間と同じ色？

蛍光灯の色は輝線スペクトルといって所々歯抜けになった色です。太陽の色も貴賤スペクトルで歯抜けになっていますがそれと蛍光灯のスペクトルは合致していません。

その結果同じ白い色でも少し感じが異なるように感じます。

より太陽光に近づけた光が出るようにした蛍光灯の管には「高演色性」というグレードのものがあります。

色を大切にする職場などではこちらを使用すると良いと思います。

• 事務所に何本の光ファイバーを引くか
• それぞれの回線をどのような位置づけにするか
• 他の事務所との連携はどのようにするか
• どの回線を固定ipにするか、また、どの回線を動的ipにするか
• どのプロバイダーとどのような契約にするか

コストと用途を考えて設計する必要があります。

システム設計には顧客との綿密な打ち合わせにより要求品質の決定が必要となります。

ここが出発点となりすべての業務が始まるので非常に大切な管理項目となります。

この段階で不十分な点があるとすべての設計の見直し、再構築が必要となる場合が多いので無駄な経費を使わないためにも時間を十分にかけて用件を決めてゆきます。

知識はコンピューティングの知識よりも顧客の業務内容に関する知識が大切となりますので当該業務に詳しい担当が主となり原案を作成します。

情報処理機器は電力を多く必要としまた、予想外に多く電力を必要とする状態が発生する場合がある。

そこで、

電源の要領を計算する場合は最大定格で計算すること。

敗戦の容量を超えて、あるいは、葉いい線が発熱するケースがない程度の電流となっていることを過度時にちぇっくすること。

多くの事業所には事務所用の電源として単相三線式敗戦されている、過不足なく電力をしようすることが無駄なコストを抑えることになるので電力計画を立案実施する必要がある。

事務所を探すときに電源の要領に関しては目が行かないことが多く見落としがちですが、現代では多くの電力を必要とするのに古い物件では特に電源の可能最大容量が小さい場合があります。 最悪日場合ビル全体の工事をしないと解決しないこともありせっかく移転したのに再度移転せざるを得ないケースがありますので多くの注意を払う必要があります。

社内におけるイントラネットに対して必要な管理項目は以下になる。

外部への接続にはルーター等のセキュリティ機器が介在していること。

外部へのアクセスは限定されていること。

外部のサイトから問題のある悪意のあるソフトウェアをダウンロード、実行しないような自動的に制限する酔おうな仕組みを提供できるかどうか判断すること。

社内情報処理機器ユーザーに対するセキュリティに関する教育を行い予防すること。

 

外部に対するホームページなどの内容が最新の情報を載せているかどうか、間違った内容になっていないかどうか、セキュリティ上問題がないかどうかを検証確認し問題点を発見しだい改良の対応を行う。

給与計算などの社内情報処理システムが稼動している場合、そのしすてむがあんて慰して動作しているかどうかを確認、検証しふぐあいｇ青北場合、また、不具合の発生が予見できる場合にソフトウェアの改良などの業務を行う。