「SMTP」を含む日記 RSS

はてなキーワード: SMTPとは

2024-09-29

anond:20240929092551

計算機科学知識体系とネットワーク技術

計算機科学は、情報理論的基盤から実用的な応用まで、広範な領域カバーする学問です。以下に、計算機科学の主要な分野と、特にネットワークに関連するトピックを体系的にまとめます

1. 計算機科学の主要分野

1.1 アルゴリズムデータ構造

アルゴリズム設計: 問題解決のための効率的な手順の開発。

データ構造: データの整理と管理効率化するための手法

1.2 プログラミング言語コンパイラ

プログラミングパラダイム: 手続き型、オブジェクト指向関数型、論理型など。

コンパイラ設計: 高水言語機械語翻訳する技術

1.3 オペレーティングシステム

プロセス管理: CPUスケジューリングマルチタスキング

メモリ管理: 仮想メモリメモリ割り当て。

ファイルシステム: データの保存とアクセス方法

1.4 データベースシステム

リレーショナルデータベース: SQLによるデータ操作

NoSQLデータベース: 非構造データ管理

1.5 人工知能機械学習

機械学習アルゴリズム: 教師あり学習教師なし学習強化学習

深層学習: ニューラルネットワークによる高度なパターン認識

1.6 ソフトウェア工学

開発プロセス: アジャイルウォーターフォールモデル

品質保証: テスト手法バグトラッキング

1.7 セキュリティ暗号

暗号アルゴリズム: 対称鍵暗号公開鍵暗号

セキュリティプロトコル: SSL/TLSIPsec

2. ネットワーク技術

ネットワークは、情報の共有と通信可能にする計算機科学の核心的な分野です。

2.1 ネットワークの基本概念

OSI参照モデル: ネットワーク通信を7つのレイヤーに分割し、それぞれの機能定義

物理層: 電気信号ビット伝送。

データリンク層: フレーム転送エラー検出。

ネットワーク層: パケットルーティング

トランスポート層: エンドツーエンドの通信制御

セッション層: コネクションの管理

プレゼンテーション層: データ形式の変換。

アプリケーション層: ユーザーアプリケーション使用するプロトコル

TCP/IPモデル: 現実インターネット使用される4層モデル

2.2 ネットワークトポロジー

スター型: 中央ハブを介して各ノード接続

リング型: 各ノードが一方向または双方向に隣接ノード接続

バス型: すべてのノードが一本の通信ラインを共有。

メッシュ型: ノード間が多重に接続され、高い冗長性を持つ。

2.3 ネットワークプロトコル

IPInternet Protocol): データパケット化とアドレッシング

TCPTransmission Control Protocol): 信頼性のある通信提供

UDPUser Datagram Protocol): 信頼性よりも速度を重視した通信

HTTP/HTTPS: ウェブデータの送受信。

FTP/SFTP: ファイル転送プロトコル

SMTP/POP3/IMAP: 電子メールの送受信。

2.4 ネットワークデバイス

ルーター: 異なるネットワーク間のパケット転送ルーティング

スイッチ: 同一ネットワーク内でのフレーム転送

ブリッジ: ネットワークセグメントの接続

ゲートウェイ: 異なるプロトコル間の通信可能にする。

2.5 ワイヤレスネットワーク

Wi-Fi802.11規格): 無線LANの標準技術

Bluetooth: 近距離間のデータ通信

セルラーネットワーク: モバイル通信3G、4G、5G)。

2.6 ネットワークセキュリティ

ファイアウォール: 不正アクセスを防止。

IDS/IPS(侵入検知/防止システム): ネットワーク攻撃の検出と防御。

VPN仮想プライベートネットワーク): 安全リモートアクセス提供

暗号技術: データの機密性を保護

2.7 クラウドネットワーキング

クラウドサービスモデル: IaaSPaaSSaaS

仮想ネットワーク: ソフトウェアによるネットワーク構築。

SDNSoftware-Defined Networking): ネットワークの柔軟な管理制御

2.8 分散システム

分散コンピューティング: 複数ノードタスク分散処理。

ブロックチェーン: 分散型台帳技術

2.9 IoTモノのインターネット

センサーネットワーク: デバイス間の通信データ収集

IoTプロトコル: MQTT、CoAPなどの軽量プロトコル

2.10 ネットワーク管理モニタリング

SNMPSimple Network Management Protocol): ネットワークデバイス管理

ネットワークトラフィック分析: パフォーマンスセキュリティ最適化

3. ネットワーク技術の最新動向

3.1 5Gと次世代通信

帯域幅と低遅延: リアルタイムアプリケーションの実現。

エッジコンピューティング: データ処理の分散化。

3.2 SD-WANSoftware-Defined Wide Area Network

ネットワーク仮想化: 柔軟なWAN構築とコスト削減。

中央集中的な管理: ネットワークポリシーの一元管理

3.3 ネットワーク自動化AI

ネットワークオーケストレーション: 自動化された設定と管理

AIによるトラフィック最適化: パフォーマンスの向上と障害予測

3.4 ゼロトラストセキュリティ

信頼しない設計: 常に認証検証を行うセキュリティモデル

マイクロセグメンテーション: ネットワーク内部の細かなアクセス制御

4. 学習リソースと参考文献

4.1 推奨書籍

コンピュータネットワーク』 アンドリュー・S・タネンバウム著

TCP/IP詳解』 W. リチャード・スティーブンス著

ネットワークはなぜつながるのか』 戸根勤著

4.2 オンラインコース

Coursera: 「コンピュータネットワーク」、「ネットワークセキュリティコース

edX: 「Computer Networking」、「Cybersecurity Fundamentals」

4.3 標準化団体リソース

IETFInternet Engineering Task Force): ietf.org

IEEE Communications Society: comsoc.org

W3CWorld Wide Web Consortium): w3.org

2024-08-23

anond:20240822200241

ちなみに http://www.abc.co.jp意味郵便とかで例えると次の通りだ。

http(以下の住所に対してホームページ郵送依頼を実行)

wwwホームページ配信窓口 担当者様)

abc.co(abc 会社

jp日本国

まぁ、httpのところの例えは正確じゃないけど。

これは住所と操作内容(http)に当たるものをセットで書くとき世界共通ルールURLと呼ばれる形式)だから

例えるなら、日本手続き時の郵送方法「〒123-4567 東京都千代田区〜 〜窓口担当者様」っていう書き方が

まれから一度も変わらないなぁって言ってるのと同じに聞こえる。

:// なんて3文字もいらんだろという指摘なら同意する。

ホームページ配信窓口以外に何があるの?って指摘なら、めちゃくちゃ種類があって実は見えないところで色々使われてる。

一般の人が目にするのは ftp とか、あとはメールソフトを設定してたら出てくる smtppopimap あたりが有名かな

2024-03-01

anond:20240229235029

言ってくれたらわかるとこなら教えるで

RESTライブラリSMTPテストコード載ってたっしょ

そのままで動くで

英語からないなら機械翻訳かければいい

2023-06-15

YAMAHA NVR500 で エキサイトMEC光 に接続する方法

ネットに公開されている情報は、初心者には難しいと感じました。

Yamahaサイトconfigは公開されていますが、exciteMEC光だと、クリアする注釈が多すぎて。

"NVR500 では、tunnel endpoint address コマンド使用して、AFTR の IPv6アドレス指定してください。"

って書いてますが、exciteMEC光はAFTR公開してないぞ!ってなるので。

正解は[gw.transix.jp]のIPv6アドレス指定する、で

"tunnel endpoint address 2404:8e01::feed:101"です。

以下、全文。

#

# transixのIPv4接続DS-Lite)でインターネット接続

#

#

# ルーターの設定:ひかり電話契約なしの場合

#

#

# ゲートウェイの設定

#

ip route default gateway tunnel 1

#

# LANインターフェースの設定 (LAN1ポート使用)

#

ip lan1 address 192.168.100.1/24

#

# WANインターフェースの設定 (LAN2ポート使用)

#

ipv6 prefix 1 ra-prefix@lan2::/64

ipv6 lan1 address ra-prefix@lan2::1/64

ipv6 lan1 rtadv send 1 o_flag=on

ipv6 lan1 dhcp service server

ipv6 lan2 dhcp service client ir=on

ipv6 lan2 secure filter in 1010 1011 1012

ipv6 lan2 secure filter out 3000 dynamic 100 101 102 103 104 105 118 119

ngn type lan2 ntt

#

# トンネルの設定

#

tunnel select 1

tunnel encapsulation ipip

tunnel endpoint address 2404:8e01::feed:101

tunnel enable 1

#

# フィルターの設定

#

ipv6 filter 1010 pass * * icmp6 * *

ipv6 filter 1011 pass * * tcp * ident

ipv6 filter 1012 pass * * udp * 546

ipv6 filter 3000 pass * * * * *

ipv6 filter dynamic 100 * * ftp

ipv6 filter dynamic 101 * * domain

ipv6 filter dynamic 102 * * www

ipv6 filter dynamic 103 * * smtp

ipv6 filter dynamic 104 * * pop3

# ipv6 filter dynamic 105 * * submission

ipv6 filter dynamic 118 * * tcp

ipv6 filter dynamic 119 * * udp

#

# DHCPの設定

#

dhcp service server

dhcp server rfc2131 compliant except remain-silent

dhcp scope 1 192.168.100.2-192.168.100.191/24

#

# DNSの設定

#

dns host lan1

dns service fallback on

dns server dhcp lan2

2023-04-08

電子メールが中継サーバー漏洩するリスクを知りたい

疑問

1. 電子メールの内容は、中継サーバーで盗み見可能なのか?

2. 電子メール送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか?

3. 電子メール送信元のクライアントと受信先のクライアント間のP2P暗号化される技術は何があるのか?

4. 「3.」の実現は中小企業で導入するのは難しいものなのか?

5. 中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因?

6. 例えば、会社PCWiresharkからネットワーク上を流れるデータを盗聴し、隣にいる社員メール内容を盗み見することは容易に可能なのか?

疑問の詳細

疑問の背景

会社日常的に契約書のPDF重要文書を送付しあってるけど、あれ、内容が漏洩することはないの?

あと、会社情シスから、「迷惑メールが突然来るようになるのは、第三者が設置した中継サーバーメールアドレス漏れしまからインターネット不特定多数サーバーを経由するからITを囓ったものなら誰でもそれは分かる」と言われた。確かにインターネット(というかTCP/IP通信)では冗長化されたネットワーク上でパケットが送付されるが、第三者個人が設置した野良サーバーを、会社から送付されたメールデータが経由するものなのか・・・

思えば、正直、電子メール技術的詳細を知らなかった。

送信プロトコルとしてSMTPがあり、受信はPOP3IMAPがあるのは知ってる。

送信アドレス偽装が容易なのも(エンベロープFROM)。

バイナリBASE64エンコードされる、とかも。

 

各疑問の詳しい説明

1.について: TCP/IP通信では冗長化されたネットワークパケットが通るのは分かるが、例えばGmailからOCNメールに送られるとして、都内在住のマンションに住むある悪意を持った人物が設置したグローバルIPを持つ野良サーバーを経由して送られる、なんてことがあるのか? あるとは思ってなかったのだが。。。

 

2.について: 上と同じ。

 

3.について: S/MIMEかな? PGP会社使用されているのは見たことがない。

 

4.について: S/MIMEPGPは、例えば社員400名くらいの小規模な弊社でも導入は容易なのだろうか。Microsoft 365のExchange Serverの設定がいるの?

 

5.について: 情シスがこれ(メールアドレスは中継サーバー漏洩するもの)を気にしていた。だから重要文書メールで送ったりするな・・・と。そうなのか? 初めて知ったのだが。。。メールアドレス漏洩は、リスト型攻撃みたいに文字列(@の左側)を試行して特定ドメインに送付され、届かなければ存在しない、届けばその文字列アドレス存在する、みたいなやり方とか、あとダークウェブで入手するものとか、そうだと思ってた。

 

6.について: 弊社の情シスが言うには、メールの盗聴というのは容易に可能からメールPDF給与明細を送付するなんてことは絶対にできないらしい(でも、普通にしてる気はするけど・・・)。確かに電子メールネットワーク上を平文で送付されるかもしれないが、パスワード付きPDFにすればいいし、給与明細Webサイト閲覧の形にしてTLS通信させればいいじゃん。そういうクラウドサービスあるんだし。そもそも、社内のHUBに悪意ある第三者LANケーブルつないでパケットキャプチャするとか、実現の難易度高すぎるから、それは想定しなくていいんじゃないの?

 

 

ていうのか、疑問。誰か教えて。

2022-12-07

anond:20221206105752

22は、空の下なるFTPに、

 25は、岩の館のSMTPに、

70は、死すべき運命Gopherに、

 80は、暗き御座のHTTPのため

影横たわるWorld Wide Webの国に。

 HTTPは、すべてを統べ、

 HTTPは、すべてを見つけ、

 HTTPは、すべてを捕らえて、

 くらやみのなかにつなぎとめる。

影横たわるWorld Wide Webの国に。

2022-12-06

The Lord of the Internet

Twenty two for the FTP under the sky,

 Twenty five for the SMTP in their halls of stone,

Seventy for Gopher doomed to die,

 Eighty for the HTTP on his dark throne

In the Land of World Wide Web where the Shadows lie.

 HTTP to rule them all, HTTP to find them,

 HTTP to bring them all and in the darkness bind them

In the Land of World Wide Web where the Shadows lie.

2022-07-24

話題書籍の1章を読んだメモ

話題書籍を買って読みました。ひととおり読んだのですが、話題の1章を読みつつ取ったメモを、本が回収される前に置いておこうと思います

ちなみに最初電子書籍で読んだのですが、回収かもって話を聞いて紙も買いました。

以下にメモをそのままのっけるので、たぶん書籍と照らさないと意味不明だと思います


Web1・2のプロトコル

・Web1は「1970年代から1980年代」というのが若干謎ではあるが、この本ではそういう定義だとおもって受け入れる余地はあるか。実際、列挙されているTCP/IPSMTPHTTP最初RFCは70~80年代

HTTPWebサイトの「構築」をするものではない(Webサイトデータを取ってくるためのプロトコルである

レイヤー構造

TCP/IPの4層モデルとかOSI参照モデルとかを意識しているんだろうけれど、いまひとつWeb2とWeb3の対比ができていない。また、後段で「ブロックチェーンプロトコル」と主張する割に、このLayersにも「Protocol Layer」が存在しており、いまいち言いたいことが伝わってこない

・Web2 Layersの雑さは見ての通り。「中間レイヤー」としてなにを想定しているのかが気になるところ。「プラットフォーマーの上に載っている」という結論ありきで作られた図のように思える

データ通信方法

・Web1の例としてHTML/CSSWebサイトのことを提示しており、それはそれで正しいのだが、冒頭のWeb1は1980年代プロトコル云々というところと整合しない。

JavaRubyはわかる C++もそりゃあたくさん使われてるわけだが、この並びで出てくるのはちょっと違和感PHPとかは?

あとP2PはべつにWeb3独自ではない SkypeとかWinnyとか、クライアントサーバではない仕組みは2000年代からいくらでもある

ログイン方法

・このへんはあんま詳しくないのでよくわかんなかった そういえばログインIDメールアドレスを使わせるようになったのってなんでなんでしょうね

・この書き方だとSNSログインすると情報収集できそうに読めるけど、SNSログインを介したからって即ログイン先の情報プラットフォーマーが集められるわけではない

具体的なサービス

ブラウザのとこはそうだね~っていう感じだったが、Firefoxハブられてるのがかなしかった オープン云々のはなしをしたいならMozilla財団の果たした役割は相当に大きいと思うのだが、(この本に限らず)無視されてることが多い

OSの部分は突っ込みどころがいっぱいあるしスクショがバズったのですでに突っ込まれている

ここもLinux無視されているのが悲しいところ

プロトコルがどうこうのところ

あくまで例示で出てきてるだけなので本質的なところではないし、よくあるまちがいではあるのだが、POPはどちらかというと「受信したメールを取ってくるため」のプロトコルと呼んだほうがいいと思う じぶんが使っているメールサーバ(というかMTA)までメールが届くのはあくまSMTPが使われている 「プロトコルが一緒じゃないと~」という文脈で考えると、いったん向こうのMTAに到達しさえすれば、読み手POP3で受信しようがIMAP4で受信しようがどうでもいいわけで、例示としてあんまりうまくない

唐突にICMPが出てきてびっくりした 重要であることはまちがいないのだが、あんまりプロトコルの例」として出てくるとこはみないので

・後段で「Web3ではいろんなプロトコルがあるんですよ~」という話をするんだったら、ここでWeb3のプロトコルとしてBitcoinとEthereumしかさないのはなんか話が通りにくいのではないか

2022-04-07

anond:20220407101012

うそう、メールで送る機能なら昔からあるんだよな。

こないだのおじさん(おばさんかも?)が言ってたのは、

SMTPじゃなくてSMBで送りたいっていう概念だった。FAX回線使って。

かにSMTP経由しないかダイレクトルーティングオーバーヘッドも少ないし面白いなと思った。

しかし56Kbpsというねw

2022-03-13

SMTP POP3 IMAP4

これIT系じゃなくても「あメールの話ね」って常識だと思ってたらそうでもなくてさみしくなった

2020-05-09

anond:20200418175139

というわけでその後の話し

Amazonカスタマーサポートの手によって不審アカウントロック状態にした旨のメールが送られてきた

引用ここから

お客様Amazon.comアカウント上で、お客様自身が行っていない操作があることについて、お知らせいただきありがとうございました。 お客様情報保護するため、当サイトからお客様アカウント登録されているクレジットカード情報アクセスすることは不可能となっており、お客様クレジットカード番号全桁がアカウントに表示されることもありません。

お客様アカウントを再開するために、以下の措置を講じました。

引用ここまで●

.comドメインなのが気になるところだけど、ひとまずアカウントロックと共にカード情報が削除されたこと、身に覚えのない注文は無効になったということで一安心

5時間後にアカウント再開ができるようになるらしいけど、カード情報が削除されているので勝手に注文して決済されることはない

氏名と住所、電話番号とかが丸見えのままなのかもしれないので、完全に解決したとはいえいかれしれないが

上記措置から20時間後に、Amazonからメールが届いた

要約するとアカウント情報更新ができなかったかログインして確認しろという内容

文面は一見するとちゃんとしているが、そこはかとなくネイティブ日本人が書いたものとは違う不自然臭いがする

更にメールに貼られたリンク先はAmazonを装った胡散臭いアドレスだった

恐らくアカウントロックされたので不正手段で注文した奴らが再び誘導しようと試みたのではないだろうか

メールヘッダをざっくり読むと、SMTPサーバは[leemingglenn002.buzz]ということになっている

不正に注文されたのは4/18のことで、件のドメインは4/14に登録されていてまだ生きている(2020/5/9現在)

残念ながらスーパーハッカーではないのでこれ以上のことはわからない

なお、正規Amazonからメール(アカウントロックした旨を記載したメール)には「不正アクセスについてはAmazon側には責任がない(意訳)」「フィッシング詐欺に引っかかったか不注意にアカウント情報を漏らしたんじゃねーの?(意訳)」ということが書かれていた

アカウントが乗っ取られたのではなくアカウントが複製された可能性が高いんだけど....

それってAmazon側のシステムの不備なんじゃないの?

2020-01-22

anond:20200122112126

会社として無能かどうかは「言い訳」次第だからなあ。

其方が利用しているSMTPサーバが正確にメール送信できていなかったようです、って言われたら返しが難しいだろ。

2019-12-28

anond:20191228091800

通信プロトコルの話なんだから別にナンセンスじゃなくね?

Slack採用してたXMPPとか電子メール通信プロトコルチャットに応用したものだぞ

ジャックドーシーがSMTPって言ってるけどこれが電子メール通信プロトコル

わかりにくいけど共通した話なんだよコレ

2019-02-23

プログラミングのはなし

メール送信接続タイムアウト待ちが長すぎるのでなんとかならない?」「ちょっと難しいですね」とかいう会話が耳に入り、どれどれ、どういうコード書いてるのと見てみたら・・・

証明書ファイルを読み込む」というコメントが目に入り、はぁ?と思ったら、SSL/TLSハンドシェイクからSMTP実装まで全て独自実装してました

それもあんまりなんだが、それ実装できる実力あったら接続早期タイムアウトくらいできるっしょと思ったが黙ってました

LinuxC++の話

2018-11-09

auでもPixcel3を使えるようにするメモ(2018/11版)

大前提

いまさらキャリアを変えるのは色々なしがらみで面倒だけど、Pixcel3を使ってみたい人向け

店頭でもやってくれるらしいけど手数料がかかるっぽい、あとキャリアメールの設定はやってくれないと思う

確認事項

auVolte対応SIMを使っていること(灰色)(黒ではだめ)

LTE NET for DATA」サービスを使っていること(単なるLTE NETだけだと通話smsだけしかできない)(後からでもネットで変更可能

自宅wifi環境があること

買う

googleの直販からsimフリーのpixel3端末を購入(僕の場合ポチってから2週間くらいで届いた)

https://store.google.com/jp/product/pixel_3

通話設定

設定>ネットワークとインターネットモバイルネットワーク>詳細設定>アクセスポイント

で今まで使ってたauの設定のやつを選択ユーザ名がuser@au.au-net.ne.jp

インターネット設定

ここまででも繋がる人はつながると思うけど、僕のように繋がらなかった場合契約確認する

https://my.au.com/aus/hc-cs/omt/OMT0010001.hc?bid=we-hc-gn-1003

My auを開いて下の方にある「ご契約内容の確認・変更」を開く

その中にあるオプションサービスの設定に「LTE NET for DATA」(月額500円)がなければ追加する

すぐには反映されなかったけど、0時くらいに変更して、起きたらネットに繋がるようになってた

キャリアメール設定

UA偽装iPhoneなりすまして、imap3やsmtpid/passを取得する

具体的方法割愛

メーラはgmailだと、au回線メール取得してくれないので、何かローカルで動くメーラをインストールすること

auショップでやること

故障紛失サポート」は店頭でのみ解除可能らしいので、お願いしようと思う

感想

やってはみたもの全然人におすすめできない、auでPixcel3使ってる人他にいるのか?

使おうと思っててまだ待てるって人は素直にauから出るのを待つのがいいと思う

2018-04-03

SMTPのSって何のことだろう

SecureのSかな

2017-09-28

ドットiは、NTTドコモiモードとは違い、専用のサーバーではなく、ダイヤルアップ接続で直接インターネットサービスプロバイダ接続する形式採用している。POP3SMTPメール対応。4つまでのパソコンメールアドレスを利用する事もできた。

https://ja.wikipedia.org/wiki/AJ-51

ドットiの特徴は、一言で言うなら「インターネット特性を生かしたオープン仕様サービスである、ということでしょう。

 ドットi端末は標準でインターネットのさまざまな標準的プロトコル対応しています。具体的には例えば、電話線などを使ってコンピュータネットワーク接続するためのPPPや、インターネット上のメールサーバーからメールを取り出すためのPOP3などに対応しています

 つまり簡単に言うと、ドットi端末では、インターネットへの接続パソコンなどでアクセスしているプロバイダアクセスポイントに直接ダイアルアップ接続ができ、また、メールに関しても、あるいは、アステルの用意したものでなくても、インターネット上の自分プロバイダーのメールサーバーや、(インターネットからアクセス可能なら)会社学校メールサーバーメールドットi端末で簡単に見ることができるのです。

http://k-tai.watch.impress.co.jp/cda/article/keyword/3002.html

キャリア依存せず直接ネットにつなぐことのできる携帯電話としては世界初ということなのかしら

まり後ろ手に縛られた白瀬慧メテオリックスリーシスターズを発動する時に使った携帯電話アステル

2017-06-28

携帯メールアドレス勝手に抹消された

携帯メールアドレス勝手に抹消されたのだが身近に同じような境遇の方はいるだろうか?

経緯:

docomo.ne.jpアドレスメールしたけどエラーが返ってくるんだがアドレスを変えたのか?と電話があった。

メールアドレスを変更した覚えがないので、WebページからMy docomo(お客サポート)のメール設定を確認したが、表示される設定内容は以前設定したメールアドレスが表示された。

・きっとメールアドレスを打ち間違えたのだろうと思い、取得しているとされるメールアドレス送信してみたところメールが届かずエラーが返ってきた。

エラーコード

 メールエラーコードは、「 Diagnostic code: smtp;550 Unknown user メールアドレス @docomo.ne.jp 」であり、

 エラーコードを返してきたサーバは「 mfsmax.docomo.ne.jpである

エラー意味

 docomoメールサーバ(mfsmax.docomo.ne.jp)がそんなメールアカウントは知らねーよって意味になる。

 基本的メールサーバ上にメールアドレスメールアカウント)がない場合サーバアカウントを抹消された場合)にサーバが返答するエラーである

上記の内容から得られること:

 docomoではMy docomoのページで表示される内容と実際のメールアカウントについて整合性が取れていない。

 docomoでは正規手続きを行わず勝手利用者メールアドレスを抹消する。

 アカウント毎削除されており、プロトコルimapしか利用できないのでiPhonePCメールバックアップしておくということはできないためメール内容は復活しない。

 メールアドレスが削除されているためメールアドレスを削除されてからメールアカウントを復活してもエラーメールをが返されたメールは受信することはできない。

サポートセンターへの問い合わせ

サポートセンターに問い合わせてみたが、iPhone担当者が帰ってしまったのでお答えできないとのことであった。

問題iPhone上で起こっているのではなく、メールサーバ上でアカウントを削除されたこどで起きてると伝えたがダメだった。

・窓口のお姉さんに伝えても理解ができないようで(ある意味仕方ない)上長確認すると言われ待たされたが、やはりIPhone担当で無いと答えられないとのことだった。

・(iPhone担当ではdocomoメールサーバについて絶対に答えられないことなのだが)後日連絡を受けることになっている。

サポートセンター上長に報告したとのことだが、その上長docomoではアカウントデータ整合性が取れておらず、また正規手続きがなく勝手メールアドレスを抹消していることについて危機感を持たない対応であったことから増田に書いた。

#初増田なので読みづらかったら申し訳ない。

2017-04-17

情報処理安全確保支援士_20170416午後解答メモ

受けてきた。

覚えているうちにメモ

午後Ⅰ

<問2>

設問1

  L氏の確認内容 :退会処理完了までのログイン回数と日時

  ログイン記録から:退会処理完了までのログイン時刻

……ユーザは正確な時刻は覚えていないものなので「日時」にしてみた。

  担当者は、この時点では、XSRFでなく不正ログインを疑っている。

設問2

(1)a.クロスサイトリクエストフォージェリ

(2)b.3

(3)c.現在パスワード d.知りえない

(4)e.confirm f.submit

設問3

(1)イ、ウ

……適当。onmouseoverとかでもイケるらしい。ダメだこれは。

(2)g.セッションハイジャック

(3)h.スクリプト実行を禁止する。

……ありがちな答え。あとで考えると、サニタイズする、かも。

<問3>

設問1

 接続IPアドレスがF社のIPアドレス以外のもの

……『F社のプロキシサーバIP』まで書いてもよかった。

設問2

(1)a.ウ b.エ c.ア d.イ

(2)e.1 f.3

(3)g.オ

……ここは、ウ(クエリラメタ)が正しそう。

(4)h.IdP i.改ざん

(5)事前にIdPとSP間で情報共有し、信頼関係を構築しているから。

……『レスポンスを中継しているから』とか思ったけど、

  ここだけ設問に『具体的に述べよ』って書いてないので、。

  抽象的なやつかなと思ってこれに。

設問3

 交通費精算サービス:3

 社外から社内IdPへの通信は、ファイアウォール禁止されているか

 グループウェアサービス:1

 接続IPアドレス制限する機能によって、社外からアクセスできないか

……地味にFWという略語はでてきていないので、ファイアウォール記載

  ここの説明はすごく問題に出そうだったので、ぐりぐりとマークしていたからすぐに気づいた。



午後Ⅱ

<問2>

設問1

(1)a.SMTP over TLS

(2)b.ウ d.ア

(3)c.内部メールサーバ

設問2

(1)e.プロキシサーバ  f.URLがC&Cサーバである通信

(2)g.外部メールサーバ h.外部サーバ転送成功している通信

(3)外部DNS: 内部DNSサーバから再帰問合わせを許可しない

  内部DNS: 外部DNSDNS問合せしない

……内部のは間違っていそう。同じ内容だしかぶってるし。

(4)i.TXTレコードに対する問合せ

……よく分からないけど、TXTレコードってSE作業とか以外で問い合わせあるの?

  と思ったので、これを問い合わせるのはマルウェアYかなと。

設問3

(1)ファイル暗号化しないこと

(2)ウィルススキャンで異常が検出された場合に、システム部が即時検知できること

……「調査及び着手の早期化」の機能要件システム部が迅速検知できる、かな。

  A社の問題点として、セキュリティパッチ適用の遅さ(どこの会社でもあるよね~)も

  あるけど、今回、社員PCのフルスキャン毎日12:00。これは頻度高い。)から

  連絡受けてシステム部が検知する13:10まで時間かかっているのも問題かなと。

設問4

 j.PC-LAN

設問5

業務LANサーバ通信は、日次データ転送で用いるプロトコルのみを許可する

……『日次でデータ転送』もぐりぐりマークしていたので使ってみた。

以上

2016-03-12

プログレッシブ最高じゃねえかNHK死ね

元日マイクロソフト古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか

放送通信の在り方に関する、私見その9

http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry

https://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry

さて、この話をいつかはちゃん記述しておかねばと常々思っていたのですが、それに取り掛かろうと思うと胸の古傷が疼くというか、平常心を保って書こうと思ってもキーボードを叩く手に自然と汗が滲んでくるのです。しっかり深呼吸をして、書きます。(またまた長文にて、失礼)

まず、1999年5月24日発表の郵政省資料地上デジタルTV放送方式について電気通信技術審議会から答申」に記述のある以下の文章をご査読ください;

「また、昨年9月の暫定方式や既に答申がなされているBSデジタル放送方式CSデジタル放送方式技術的条件において、実証実験必要とする映像の表示方法とされていた720p(有効走査線数720本の順次走査による映像表示方法)について実験を行った結果、その性能が確認されたこと等が併せて報告されました。 この中で、720pは技術的にHDTV放送位置付けることが可能である、と結論付けられています。」(同上答申より引用

関連記事は、日経産業新聞(1999年5月25日PP.3)、日本経済新聞(1999年5月25日PP.11)、電波新聞(1999年5月26日PP.2)などにも掲載されています

以下は、そこに至るまでの「血と汗と涙のお話」であります

今となっては、720pや1080pのプログレッシブ方式プラズマ液晶テレビとの親和性映画CGなどの映像制作に有利なバリアブル・ピッチによる撮影パソコンによる編集再生環境においてその優位性を疑う人は居ないと思うのですが...1998年からこの1999年5月24日までの間、この720pを日本放送業界から抹殺しようとする「ありとあらゆる活動を展開した集団」がおり、その軋轢の中で多くの人が傷付き市場から去ることになったのでした。

個人の主張、そしてマイクロソフト立場は、1080iと720pどちらが良いか、どちらかひとつを採択するかではなく、仕様の中に1080iと720pを併記して頂きたいというものでした。 米国放送方式はATSCによるHD放送に向けた放送の標準フォーマットとして早くから1080i、720p、480p、480iが規定されていました。50年以上前発明されたテレビ放送米国に合わせてNTSC方式日本採用し、ヨーロッパ中国ロシアなどがPAL方式採用してきた背景からすれば、日米のテレビ方式デジタルハイビジョンHD放送)の時代になっても米国と同様の1080i及び720pを両方サポートするということは自然なことと思われました。日米間の互換性だけではなく、当時よりブラウン管チューブを使った重たいテレビ受像機は、急激な勢いでプラズマTV液晶テレビに取って変わることは明らかであり、走査線が走り一本ずつの光るスダレを交互に表示して人間の眼の残像を利用してひとつ映像に重ね合わせるという飛び越し走査よりは、一つ一つのセルが自ら発光する、もしくは遮光をオン・オフして光源を反射もしくは直視映像表現するフラットパネル時代には、プログレッシブ順次方式が有利と思われました。さらに、映像圧縮採用されたMPEG2方式においては、1080iは22Mbpsでは最高品質映像を表示するも、その転送レートを15Mbps以下まで落としてくると映像破綻するという現象も既知のことでした。720pはMPEG2による映像圧縮でも15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、さらMPEG2以外の圧縮方式MPEG4H.264WMV現在のVC1)などを使えば8Mbpsから12MbpsでHD放送を伝送できるというのが、私たちの主張でした。

当時の私の主張をまとめると、「HD放送1080iもしくは720pいずれでも撮影、記録、編集、伝送、受信、視聴できることとする。映像圧縮に関してはMPEG2に限らず、将来の斬新な圧縮技術を随時採択できることにする。コンテンツ保護技術や、個人認証課金技術特定技術一つに限らず、複数技術をそれぞれもしくは組み合わせて提供可能とする。放送通信の融合(連携サービス記述するメタ言語HTMLベースに各種プラグインそしてXML対応する。XHTMLベースにしたBMLはそのサブセットとして組み込む。」

それに対して、1080i擁護派は、「1080iが優れた方式で、議論余地は無い、プログレッシブの話をするなら帰れ!!」(実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん(E並氏)はとても紳士ですので、私は尊敬しております。決して誤解のないように)郵政省会合でも何度となく放送プロ達に諭(さと)されたものです。「君はPC業界に都合の良い方向へ持っていこうとしてるんでしょ」「崇高な放送世界邪悪世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。

将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。

当時、松下電器産業殿は720pの優位性を説きながらDVC Proをレリースされ、1080iと720pの両用機能を持った松下電器産業HD D5という放送局用ビデオデッキは、AJ-HD2700やAJ-HD3700という型番で欧米放送局でも沢山採用され、放送業界権威あるエミー賞DVC ProもHD D5も受賞されています。このD5というビデオデッキNHK殿に納入する時、720pの機能が付いているなんてことがバレると殺されるので、本体に点在するボタン11個以上押さないと、(つまり二人の人間の指を駆使してボタンを押さないと720pの機能アクティブにならないように細工がしてあったそうです。)..まるで隠れキリシタンが隠し絵にキリスト像を描いていたような話でありますが..この類(たぐい)のプレッシャは日々激しいものになってきて、魔女狩りに駆り出された狂信的な信者が、誰彼となく次々と火あぶりに挙げるような行為が続いたのです。

480pと720pの実験放送をやっていた日本テレビSさんKさんの受けた仕打ちは、某放送局のEB沢さんから直接日テレ社長のUJ家氏に電話をかけてこられて、「お宅の技術トップ人間は、ウチに対抗して何かやっているようだけど、けしからん話だ。そんなことではデジタルハイビジョン映像をウチから供給できなくなるけれど、それでも良いのかねぇ」と迫ったそうです。その結果SさんKさんは当然将来取締役約束されてもおかしくない何十年にも渡る業界に対する貢献がありながらいつのまにか表街道を去ってしまうことになりました。

テレビ朝日殿が新しいスタジオを作るにあたり、1080i/720pの両用ビデオスイッチャーを東芝から導入された時、某放送局のキツイお達しがテレ朝東芝に飛び、720pの機能は殺して納入するようにとの指示が飛んだそうです。そして、BS-iスタジオ導入で,1080iのカメラと720pのカメラを性能評価したという話を聞きつけて、「まさか720pのカメラを導入するなんてことはありませんね?」という問い合わせが某局から入ったそうです。

TBS殿も全く同様にメインスタジオへのHD機材導入にあたって1080iと720pの両用システムの導入計画純粋技術観点選択肢だけではなく、それ以外の見えない力に奔走されておられました。「魂の報道」を標榜するTBS殿の報道部門が、DVC Pro 720pを採択されたことが、唯一の救いと感じられました。

NAB98の会場にて明日から開場というまさに前日のこと、某放送局のY氏、会場を事前に巡回されJVC殿の会場にて1080iと720pの両用カメラ発見JVC殿に対して「好ましくない表示は控えるようにと一括」結果としてNAB98の初日には無残にも綺麗にできた展示パネル1080i/720pの文字列の720pの部分にはガムテープが張ってありました。

毎週のようにこのような話を耳にするにつけ、これは魔女狩りでも特高警察検閲でもあるまいに…現代の話なのに本当にそんなことが起っているのだろうかと自分の耳を疑っていました。そしてそれが、とうとう我が身にも降りかかったのでした。

1998年NABショウでマイクロソフトは初めて放送関連のコンベンション技術展示をすることになりました(関連記事)。松下殿より当時500万円程したHD D5デッキマイクロソフトは購入し、1080iと720pの映像を左右1対で比較デモ表示し、どのように優位性が表示されるか比較デモを予定していました。1080iの標準的撮影は1440x1150の1080i標準ビデオカメラによる撮影結果を1920x1080の映像計算しなおし(アップスケール)、それをスダレのような偶数奇数フィールドに振り分け送出するという方式を取っていました(現在デジタルハイビジョン放送の標準撮影方法です。)。そして同じ映像1280x720の720p標準カメラ撮影しD5デッキに録画した映像をそのまま720pで再生するというデモ内容でした。映像再生には当時の最高品質CRTスタジオモニター(8000ドルクラスSONY製品を2台)をマイクロソフトの展示会場に用意しておりました。比較展示用デモ映像は同じスタジオ環境撮影した1080iと720pのそれぞれの映像データをお持ちの松下電器産業殿からD5の録画テープをお借りして、初日デモへ向けて全ての設営と映像チェックが終わった時のことです。某放送局の方が、マイクロソフトブース垣間見るや、とても渋い顔をしておられます

私は夕方の6時過ぎに会場の設営も終わり、ホテルに戻ろうとしていたところ、松下殿から緊急の連絡が入り、展示に使っていたビデオテープを持って松下殿の技術担当役員ホテルの部屋まで来て欲しいとのこと..部屋に入るとその役員さんは、ベッドの上にあぐらをかいて、その両脇には15人を超そうという松下の方々が壁沿いに2列にずらりと並んで座っているではないですか..その姿はまるで、新入りの囚人(私)が牢名主親分に「今日からお世話になります」と仁義を切るのかい、というような雰囲気でありました。

そしてその親分さんが言うには、「そのテープ黙って置いて、帰ってくれ」とのこと..「冗談じゃない、そんなことしたら明日の展示は何も映像が表示できないではないですか?何故そんな唐突な話をこの期に及んでされるのですか」と問いただしたところ、松下マイクロソフトに協力して720pを推進するのはけしからんと、某放送からお叱りを受けたと..それだけでも絶句出来事なのに…「とにかく松下から映像を貸し出すなどとんでもない..即効撤収してくるように」との具体的な命令を受け私は必至に食い下がり、「その映像作品は全て松下殿の著作物であり、某放送局に文句を言われる筋のモノでは無いはずです。それを何故ゆえに引き上げなければならないのですか?」と伺えば..「その中のヨーロッパのお城のシーンはARIB加盟各社がテスト映像として皆で利用するために松下が供出したもので、そのテスト映像ARIBの会員でもないマイクロソフト勝手に使うのは如何なものか?」とのこと..私はさらに一歩も引かず交渉を続け…もしそれが現実になるのなら「明日の朝は急遽説明パネルを書いて、某放送局の名前実名で明らかにした上で、この名前会社の不当な介入でマイクロソフトでは展示ができなくなりました」と張り出しますよとまで迫りましたが担当役員は首を立てに振りません。最期に私は「判りましたこテープはここに置いて行きますが、夜中に誰かにまれたということにして私が犯人になりますから..盗難届けを出してください!!それでは如何でしょうか?」と交渉は3時間を越える押し問答となりました。

その結果最後に明らかにされた背景は、某放送局の方から松下役員に語られた厳しい言葉でした。それは、「君、僕らは今年50億円くらい君の会社からモノ買う予定だよねぇ、そんな態度でいると、50億円のビジネス失うことになるよ、君ぃ!! それでも良いのだね!!!」というもので、担当役員は縮み上がってしまったのだそうです。技術担当役員マイクロソフトの展示に協力をした結果、50億円のビジネスを失うことになったら営業担当役員との軋轢を生むことは必至であり、そこまでのリスクを負ってまでビデオテープマイクロソフトに貸し出すわけにはいかないとの判断、私はビジネス交渉でこんなに困り果てたことは一生に何度も無いというぐらい意気消沈しきっておりました。

10時にならんとするタイミングで、日本からシアトル経由でラスベガスに到着後、時差から回復する間も無く会場の設営を手伝っていた私はもうダウン寸前…そこで思いついた解決策は「判りました、このテープはお返ししましょう。その代わり今から新規撮影を開始しまから必要な機材と人を朝まで貸してください」と何とも無謀な提案を申し出たのでした。 NABのメイン会場からマイクロソフトの借りていたヒルトンホテルの部屋まで、HDカメラ(当時は100kg以上あったと思います)とD5のデッキを担いで深夜に部屋へ持ち込みスイッチャーや編集機もないままイッパツ撮りでデモ映像を仕上げなければなりません。私はそれまでにいくつかの放送スタジオ見学に行ったことはあるものの、映像プロデュースも撮影も全くのシロウトですので、カメラライティング撮影オペレーションに付き合ってくれる人たち3人ほどに朝まで付き合ってもらいました。

途方に暮れて困ったことは、深夜の12時にラスベガスホテル撮影できる生素材など有りはしないのです。それも著作権肖像権侵害せず、HD映像の違いが際立って表現できる素材、なおかつ1080iより720pの方が綺麗に見えるという素材(多くは、風にそよぐ木々とか波打つ水面、キックされたサッカーボールなんてものが使われるのですが..残された時間日中ロケハンに出かけることもできず、全てはラスベガスヒルトンの部屋で深夜、朝までの6時間以内に解決しなければなりません。

まず、深夜のルームサービス果物の盛り込みを頼みました。そしてその果物の表面に霧を吹いて光るリンゴの表面に張り付く水滴なんてもの撮影しました。本格的なスタジオと違って光の回り方も映像モニタを視ても、思ったような映像にはなりません。

夜も更けて3時を廻り4時にならんとした頃でしょうか、雑誌カラーグラビアをメクりながら、この際著作権の許諾を無視して雑誌に写っている写真撮影してしまおうか?こんな深夜にマトモに著作権の許諾などできる素材など有りはしないし、と途方に暮れていたところ、あるアイディアが湧き出てきました。「そうだ、ドル紙幣撮影すれば手彫りのエッチング表現された人間の顔やお札の文様HD撮影すればビックリするほど細かい映像として撮影対象になるに違いない、誰でもそのパターンが何か理解できるはずだし、何よりもお札の縦横無尽に走っているストライプが際立って720pと1080iの違いを引き立ててくれるに違いない」と確信するに至ったのです。ドル紙幣ビデオ撮影しても肖像権著作権を主張する人もあるまい、という点が一番大事ポイントだったのです。

壁に貼り付けた50ドル札(私の持っていたピン札はそれしかなかったので)にバッチリライティングを施し、撮影した結果は「キタキタキターッ」という感じ!!カメラパンして右へ左へ振りながらお札の表面を舐めるように撮影した720pの映像は細かい線の1本1本を明確に表示して、1080iの映像は実に見事にモアレ縞が出まくり画面にチリチリと汚い映像が糸を引きます。これでこの映像をそれぞれディスプレィに表示した上で、 Permalink | 記事への反応(0) | 11:32

ログイン ユーザー登録
ようこそ ゲスト さん