무엇이든지 기록

기존에 발송했던, 수신했던 메일을 계속해서 Reply, 혹은 Forward 하는 경우,

기존의 메시지 ID 값이 References 에 쌓인다(들어간다)

아래 메시지 예시는 10번정도 전달이 된것 으로 보면 된다.

추가.

Exchange 2013 OWA 버그(?)

동일한 메일을 계속해서 Reply, 혹은 Forward 재사용하는 경우

수백 건의 Reference 값이 쌓이게 된 상황에서

Exchange 2013 OWA에서 해당 메일을 다시 Reply, 혹은 Forward 시도하는 경우

해당 IE 브라우저 Hang 현상발생 브라우저 재시작 필요

In-Reply-To: <SNT124-W2664003139C1E520CF4F6787D30@phx.gbl>

References: <SNT124-W2664003139C1E520CF4F6787D30@phx.gbl>

Did you notice?  The values of the In-Reply-To and References headers are taken from the Message-ID header of the original!  Ah, but what happens if I "reply to the reply"?   Well, my message gets its own unique Message-ID, of course...and the Message-ID of the message to which I'm replying goes in my In-Reply-To header (which usually has only one Message-ID)...but that In-Reply-To Message-ID is also APPENDED to the References header.  So, in a lengthy back-and-forth, you might see headers that look like this:

In-Reply-To: <4BE8776D.4080504@kheb.fr>

References: <AANLkTik0c9hCMm2Efyj7rB7Us7hL3ZdESYEhE2GBQCfM@mail.gmail.com>

<20100509165117.GD20976@ovh.net>

<AANLkTins_dUSqRbR371SNnOIPYlatKdTCIVM8oDbtVtX@mail.gmail.com>

<AANLkTimKu7l1AtEG-0CI7Q3Ely9PUL2yuyvYuhcMIuSn@mail.gmail.com>

<AANLkTikJaHXYM_DF8zqdaH0vVnJ-fCpqvJ3OCQweoeAb@mail.gmail.com>

<AANLkTinq7riyV4w3VnCoHyj9GsNf3H7jDzu1awU2PNRb@mail.gmail.com>

<AANLkTilrPTCZPj_Tb7bXO5SLym_QY3KUp4J1jkZd5-ZE@mail.gmail.com>

<4BE72FF3.3030501@kheb.fr>

<4BE7B451.8060700@linuxant.fr>

<4BE8776D.4080504@kheb.fr>

From: XXX <xxx@xxx.xx>

Date: Mon, 10 May 2010 23:20:59 +0200

Message-ID: <AANLkTikC5oN2rO5VTj8HN7U03b2H3HUqt89KYdemGlcJ@mail.gmail.com>

(Notice that this Message-ID isn't in the References header - because no one has yet referenced this message with a reply!)

Surprise - you've just learned how "threaded discussion" email clients work.  Basically, they can look at any message in the thread, grab its References header, and go find the other messages in your mailbox.

ISAPI 필터란 (Internet Server Application Program Interface)?

인터넷 서버 응용 프로그래밍 인터페이스

ISAPI 필터는 인터넷 정보 서버의 앞단에 위치하면서 인터넷 정보 서버로 들어온 모든 request 에 대해 가장 먼저 처리할 권한과, 인터넷 정보가 생성한 response를 클라이언트에 보내주기전에 가공할 수 있는 권한을 갖는다.

ISAPI 필터를 작성할 대 잊지 말아야 할 것은 가능한 최소한의 작업을 이곳에서 처리해야 한다는 사실이다. 웹 사이트에 대한(가상 디렉토리가 아닌 웹 사이트 전체이다) 모든 request가 ISAPI 필터를 거칠 수 있기 때문에 과도한 작업을 필터에 걸어주게 되면 웹 사이트 전체의 퍼포먼스에 심각한 영향을 미치게 된다.

ISAPI는 CGI 보다 더 빠르게 실행되는 웹서버 프로그램을 작성할 수 있도록 해주는 일련의 윈도우 프로그램 호출이다. CGI 프로그램의 단점은 매번 실행될 때마다 그것의 고유의 주소공간과 함께 별개의 프로세스로 실행된다는 것인데, 특히 많은 사용자들을 위해 수많은 인스턴스들이 실행되는 경우 가외의 명령어들이 실행되는 결과를 낳는다. 이제 사용자들은 ISAPI를 사용하여 HTTP 프로그램의 프로세스와 주소공간의 일부로서 동작할 수 있는 DLL 프로그램 파일을 만들 수 있다. DLL 파일들은 HTTP 시작되면 컴퓨터 내에 적재되며, 필요한 동안 계속 남아있게 되므로, CGI 프로그램처럼 자주 찾아 메모리 내로 읽어들일 필요가 없게 된다.

기존의 CGI 프로그램들은 로직을 재작성하지 않고도 ISAPI를 이용한 DLL로 변환될 수 있다. 그러나, 스레드를 지원함으로써 한개의 DLL 인스턴스가 여러명의 사용자들을 지원할 수 있도록 재작성 될 필요는 있다.

ISAPI DLL 의 특별한 종류를 ISAPI 필터라고 부르는데, 이것은 모든 HTTP 요청을 위해 제어권을 받도록 지정될 수 있다. 이외에도 사용자는 암호화/복호화, 기록유지관리, 요구심사 또는 기타 다른 여러가지 목적을 위한 ISAPI 필터를 제작 할 수 있다.

ISAPI 필터의 동작 원리

ISAPI 필터는 웹 서비스가 시작될 때 인터넷 정보 서버와 같은 프로세스 공간에 로딩되는데, 이 때 ISAPI 필터는 자신이 처리할 이벤트 정보를 인터넷 정보 서버에 알려준다. 클라이언트로부터 request 가 들어오고 response를 전송할 때 인터넷 정보 서비스는 ISAPI 필터가 등록한 이벤트 정보를 사용해 각각의 필터에 특정 이벤트가 발생하였음을 알려주고, ISAPI 필터는 이벤트 핸들러에서 원하는 처리를 한다.

1. 웹 서비스가 시작 될 때 ISAPI 필터는 자신이 처리할 이벤트를 인터넷 정보 서버에게 알린다.

2. 클라이언트로부터 request 가 들어왔을 때 인터넷 정보 서버는 request 와 관련된 이벤트를 알려줄 ISAPI 필터가 있는지 확인하고 ,그러한 필터가 존재한다면 request 에 대한 정보를 ISAPI 필터에게 전달한다.

3. ISAPI 필터는 이벤트 핸들러에서 request 에 대한 작업을 수행하고 제어권을 다시 인터넷 정보 서버로 넘긴다.

4. 인터넷 정보 서버는 response를 생성한 후 response와 관련된 이벤트를 알려줄 ISAPI 필터가 존재하는지 확인하고, 그러한 필터가 있으면 response 에 대한 정보를 ISAPI 필터에게 전달한다.

5. ISAPI 필터는 이벤트 핸들러에서 response 에 대한 작업을 수행하고 response 를 클라이언트에게 전달한다.

이러한 과정을 수행하면서 인터넷 정보서버와 ISAPI 필터는 HFC(HTTP_FILTER_CONTEXT)라는 구조체를 사용해 상호간에 정보를 교환한다.

인터넷 서버 응용프로그램 인터페이스

즉, OWA, EAS, RPC over HTTP, ASP.NET ISAPI 등의 것을 모두 아우른다

모두 사용자에게 다양한 HTTP기반 프로토콜을 통해 Exchange 서버로의 액세스를 제공한다.

즉, 가상사설망(VPN)없이도 일반 HTTP를 통해 연결이 가능하도록 해준다.

RPC over HTTP는 VPN없이도 Exchange서버의 자신의 사서함에 ㅈ접근하도록 해준다.