김동욱 님이 쓰신 글 :
: 메일 서버에서 pop3를 사용하여 자동으로 메일을 가져와 저장하는 부분이 있는데
:
: 어느날 갑자기 메일의 첨부파일이 변경되었습니다.
:
: 원인은 밝혀 졌는데 해결책을 찾기가 어렵네요.
:
: 원문에서 첨부파일이 바이너리고 quoted-printable 로 인코딩된 부분이 있을때
:
: .=0A=  (원문)=> ..=0A= (pop으로 받은 부분)
:
: 마침표가 하나더 추가되어 바이너리 파일이 변경됩니다. (택스트는 읽는데 문제 없네요 ㅋ)
:
: 사용 컴퍼넌트는 OverbyteIcsV5 이고 메일 서버는 머큐리 입니다.
:
: 아무래도 메일 서버 자체의 오류 인듯한데 어디서 부터 손대야 할지 ^^;
:
: 인디로 테스트 해본결과 스트림 자체에서 변형이 일어나는 것 같습니다.
:
: 메일 서버를 만들기는 좀 그런데 ^^;;
:
: 다른 해결방법은 없나요?

메일 전달의 흐름을 보면
SMTP Sender -> SMTP Receiver    ..........   POP3 서버 -> POP3 클라이언트

SMTP Sender: 보내는 이가 이용하는 서버
SMTP Receiver: 받는 이가 이용하는 서버
POP3 서버: SMTP Receiver가 저장해놓은 메일을 받는 이가 요청할 때 받는 이게게 보내주는 서버
POP3 클라이언트: 받는 이가 이용하는 메일 수신 기능이 있는 프로그램(아웃룩 같은)

문제는 마침표(. 아스키코드46번) 때문인데
SMTP에서 CRLF마침표CRLF는 메일의 끝을 알리는 표시이고
POP3에서 CRLF마침표CRLF는 2줄 이상으로 구성된 응답메시지의 끝을 알리는 표시입니다.
위에서 CRLF는 줄바꿈 문자 쌍입니다. 아스키코드로 CR은 13(0x0D)번이고 LF는 10(0x0A)번입니다.

quoted-printable이나 Base64와 같은 인코딩은 메일을 보내는 쪽에서 합니다.
quoted-printable로 인코딩된 ".=0A="가 pop3로 받았을 때 "..=0A="로 변했다면
SMTP 쪽 보다는 POP3 클라이언트에 문제가 있을 가능성이 높습니다.


POP3 서버는 각 응답메시지가 두 줄 이상일 때 두번째 줄부터는 선두에 마침표가 나오면 앞에 마침표를 하나 덧붙여서 보내게 됩니다.
따라서, POP3  클라이언트는 받은 응답메시지가 두 줄 이상일 때 두번째 줄부터는 선두에 마침표가 나오고 연이어 CRLF가 나오지 않으면 선두의 마침표 하나를 제거해야 합니다.
POP3에서 CRLF마침표CRLF는 두 줄 이상인 응답메시지의 끝을 알리는 표시이기 때문에 이 표시와 실제 메시지에 마침표 하나만 있는 줄을 구분하기 위한 조치입니다.

이렇게 볼 때 ".=0A="가 pop3로 받았을 때 "..=0A="로 변할 수 있는 조건은
POP3 서버가 보낼 때 ".=0A="가 두번째 줄 이상의 선두에 놓여있어야 합니다.
즉,  POP3 서버가 메일 내용을 보낼 때 여러 줄로 보내게 되는데 이때
공교롭게도 ".=0A=" 앞에서 줄바꿈이 되게 되어 POP3 서버가 앞에 마침표를 하나 덧붙여
"..=0A="로 보냈는데 이를 받은 POP3 클라이언트는 원칙대로 처리하지 못한 것으로 보입니다.

물론, 굳이 오류의 가능성을 따지자면 모든 과정에서 있을 수 있지만
예를 들어, 메일을 보내는 쪽이나 POP3 서버에서 애초에 마침표를 필요 이상으로 덧붙였을 수도 있지만
그것 보다는 POP3 클라이언트에서 잘못했을 가능성이 높지 않나 생각이 듭니다.

SMTP Sender , SMTP Receiver ,   POP3 서버 , POP3 클라이언트 중 어디에서 문제가 발생하는 지
알아보려면 위의 내용을 참고하여 테스트 메일을 작성하여 송수신해보면 될것입니다.
SMTP Sender와 POP3 클라이언트를 두 개 이상 달리 해서 테스트해보아야겠지요.