참조 URL : http://onlyperl.egloos.com/1954409
내가 생각하는 qmail의 문제점.
오랫 동안 qmail을 다루면서 몇가지 생각한 문제 점 들이다.
그동안 나름대로 애를 먹었던 점들이기도 하고, 나름대로 해법을 찾았다.
1. User-Check
단연 첫번째 문제 이리라.
예전에 queue에 왜 쓸데 없는 메일들이 많이 있는지 도저히 이유를 알수가 없었다.
처음에는 이문제가 "double bounce" 문제 인줄로만 알았다. 하지만 그런건 아니었다.
이것을 해결하기 위해 다른 프로그램을 가져다 쓰기도 했고,
개발팀과 우차장님하고 박대리님 하고 피터지게 싸웠었다. 그땐 프로그래밍에는 깡통이던 시절이었던지라..ㅋㅋㅋ
하지만 너무나 간단하게 멋지게 해결 해주셨다.
Vpopmail 을 쓸 경우에는 패치가 있다 하지만 checkpassword에는 마땅한 패치가 없다.
어쨌든 그때 했던 고민은, 나에게 두가지 무기를 안겨 주었다. magic 과 qmail 직접 고쳐볼 마음을 가질 수 있게 해준것이다.
어쨌든 지금도 Qmail을 몇몇 업체를 알고 있고, 약 10분이면 더 이상 배송이 되지 않도록 정지 시킬 수 있다.
2. Quota-Check
Qmail은 쿼터를 queue에서 유저의 메일박스로 메일을 적재 할때 체크 한다.
열어보면 "du -sk" 를 실행해서 체크 한다.
어떻게 본다면 Qmail이 만들어지던 시점에서는, 구현하기 쉽고, 소스 간단하고 뭐 이래저래 장점이 있었다.
마땅한 대안이 있는것도 아니지만서도....
아무튼 요즘 같이 유저들에게 대용량의 메일을 제공할경우,
100M씩 적재된 메일 박스를 저런 방식으로 체크하면 몇초씩 걸리기도 한다.
유저가 적을때는 상관없겠지만... 많은 유저가 있을 경우, 유동량이 많을 경우 등등...
또는 일부 오픈소스 웹메일등을 이용할경우 개인편지함이 쿼터체크가 안되는등의 문제가 발생한다.
특히 "쿼터가 다찬경우 발생 하는 리턴 안내메일" 이 문제 이다.
리턴패스에 따라 또는 메일 발송자에게 메일 딜리버리 실패 안내 메일을 보내게 된다.
문제는 요즘같이 스팸이 창궐 하는 시점에 보내는 사람이 정상적인 주소일리 없다.
이경우 리턴메일에 대한 실패 메일 ->더블바운스 ->트리플 바운스 등이 발생 하며,
굉장히 쓸데 없는 곳에 시스템 재원을 많이 소모 하게 된다.
(더블 바운스 패치는 이런걸 보면 필수다. ㅋㅋㅋ)
이 문제만 잘 활용 해도 서버 한대 바보 만드는건 일도 아니다.
이경우에 대한 몇가지 대안을 찾았다. 그에 대한 개발도 대충 끝내논 상태이지만...
시스템에는 적용을 하지 못했다.
똥인지 된장인지 구분을 못하는 멍청한 결제 권자로 인해서, 완료보고만 하는 형식으로 나는 접어 버렸다.
3. 빈약한 방어 체계
요즘 같이 스팸메일이 많이 발생 하는 시점에서는 그에 대한 방어 체계가 필수다.
대부분의 메일 에이전트에는 이러한 기능들이 많이 빠져있다.
스패머들의 공격형태를 보면 몇가지가 특징이 있다.
이중에서 가장 문제가 되는것이,
A. smtp 커넥션을 맺은 다음, 없는 유저든 있는 유저든 랜덤 또는 리스트에 의해 계속 메일을 보내려고 시도 한다는것이다. 시스템에서 할당하는 SMTP 포트 개수는 유한하다. 또한 유저의 유무를 붙어서 테스트 하기 때문에 시스템에 부하가 발생 하지 않을 수 없다.
B. 동시 발송 수 제한.
한번 SMTP에 붙어서 동시 발송에 대한 제한이 없다. 유저가 엄청 많을 경우 외부로 보내는 프로세스를 혼자 점령 해버리고 다른 유저들의 메일은 늦게발송 되는 현상이 나타난다. 물론 시스템 로드도 상승한다. 그러기 위해서는 MAX RCPT 호스트의 숫자와 MAX COMMAND의 제한하는 기능이 필요하다.
C. RFC 표준 검수.
스패머의 경우 대부분 RFC 표준을 충족하지 못하는 경우가 태반이다. 물론 스패머들은 대부분 웹플들이며, 이들은 메일 형식에 대해서 잘모른다. 물론 요즘은 점점 충족해 나가지만, 그래도 아직은 이것 만으로도 수많은 스패머들을 바보로 만들수 있다.
D. daemon-tools
양날의 칼이다. 직접 운영을 해본사람은 이것이 얼마나 피곤한 프로세스인지 알것이다.
하지만 그 반대로 엄청 도움이 된다. tcpserver와 함께 좋아 할수도 버릴수도 없는 계륵 같은 존재 이다.
비단 여기서 언급된 문제들은 Qmail 만의 문제는 아닐것이다.
그래서 요즘 T사 3사 I사 S사 A사 등등 스팸 필터장비로 유명한 업체들이 속속 등장한것이다.
물론 이것저것 테스트 해본답시고, 다른 회사의 저 장비들의25번 포트에 붙어서 이것저것 많이도 해봤다.
소감은 T사가 여러 회사들중에서 가장 많이 고민하고 있다는것을 느꼈다.
물론 저 T사의 오탐 및 버그로 인해서 고생도 많이 했다.
상대측 장비에 T사 장비가 오탐 및 버그로 인해서 아무런 문제 없는 정상메일을 스팸메일로 지정 해버리는경우다.
메일 형태 검사에서 말이다.
상대측 회사 담당자는 아무것도 몰랐고 그들은 T사에 요청에서 해결 했다. 문제에 대한 해결이 아주 빨리 되었다.
나온장비나 솔루션중에서는 사후 지원이라던가 다 생각했을때 제일 괜찮은듯....
어쨌든 급변하는 메일환경에 Qmail은 이러한 문제들이 있고 그에 대한 방어책으로 고민해본 사람들은 나의 생각에 동의할듯하다.답이 없으면 장비 사다 쓰는게 쉬울것이란 생각이든다.
각각의 문제를 해결을 위해 고민하고 또 고민 해 놓아도, 사용되지 않는 다면 무슨 의미가 있으리...
오랫 동안 qmail을 다루면서 몇가지 생각한 문제 점 들이다.
그동안 나름대로 애를 먹었던 점들이기도 하고, 나름대로 해법을 찾았다.
1. User-Check
단연 첫번째 문제 이리라.
예전에 queue에 왜 쓸데 없는 메일들이 많이 있는지 도저히 이유를 알수가 없었다.
처음에는 이문제가 "double bounce" 문제 인줄로만 알았다. 하지만 그런건 아니었다.
이것을 해결하기 위해 다른 프로그램을 가져다 쓰기도 했고,
개발팀과 우차장님하고 박대리님 하고 피터지게 싸웠었다. 그땐 프로그래밍에는 깡통이던 시절이었던지라..ㅋㅋㅋ
하지만 너무나 간단하게 멋지게 해결 해주셨다.
Vpopmail 을 쓸 경우에는 패치가 있다 하지만 checkpassword에는 마땅한 패치가 없다.
어쨌든 그때 했던 고민은, 나에게 두가지 무기를 안겨 주었다. magic 과 qmail 직접 고쳐볼 마음을 가질 수 있게 해준것이다.
어쨌든 지금도 Qmail을 몇몇 업체를 알고 있고, 약 10분이면 더 이상 배송이 되지 않도록 정지 시킬 수 있다.
2. Quota-Check
Qmail은 쿼터를 queue에서 유저의 메일박스로 메일을 적재 할때 체크 한다.
열어보면 "du -sk" 를 실행해서 체크 한다.
어떻게 본다면 Qmail이 만들어지던 시점에서는, 구현하기 쉽고, 소스 간단하고 뭐 이래저래 장점이 있었다.
마땅한 대안이 있는것도 아니지만서도....
아무튼 요즘 같이 유저들에게 대용량의 메일을 제공할경우,
100M씩 적재된 메일 박스를 저런 방식으로 체크하면 몇초씩 걸리기도 한다.
유저가 적을때는 상관없겠지만... 많은 유저가 있을 경우, 유동량이 많을 경우 등등...
또는 일부 오픈소스 웹메일등을 이용할경우 개인편지함이 쿼터체크가 안되는등의 문제가 발생한다.
특히 "쿼터가 다찬경우 발생 하는 리턴 안내메일" 이 문제 이다.
리턴패스에 따라 또는 메일 발송자에게 메일 딜리버리 실패 안내 메일을 보내게 된다.
문제는 요즘같이 스팸이 창궐 하는 시점에 보내는 사람이 정상적인 주소일리 없다.
이경우 리턴메일에 대한 실패 메일 ->더블바운스 ->트리플 바운스 등이 발생 하며,
굉장히 쓸데 없는 곳에 시스템 재원을 많이 소모 하게 된다.
(더블 바운스 패치는 이런걸 보면 필수다. ㅋㅋㅋ)
이 문제만 잘 활용 해도 서버 한대 바보 만드는건 일도 아니다.
이경우에 대한 몇가지 대안을 찾았다. 그에 대한 개발도 대충 끝내논 상태이지만...
시스템에는 적용을 하지 못했다.
똥인지 된장인지 구분을 못하는 멍청한 결제 권자로 인해서, 완료보고만 하는 형식으로 나는 접어 버렸다.
3. 빈약한 방어 체계
요즘 같이 스팸메일이 많이 발생 하는 시점에서는 그에 대한 방어 체계가 필수다.
대부분의 메일 에이전트에는 이러한 기능들이 많이 빠져있다.
스패머들의 공격형태를 보면 몇가지가 특징이 있다.
이중에서 가장 문제가 되는것이,
A. smtp 커넥션을 맺은 다음, 없는 유저든 있는 유저든 랜덤 또는 리스트에 의해 계속 메일을 보내려고 시도 한다는것이다. 시스템에서 할당하는 SMTP 포트 개수는 유한하다. 또한 유저의 유무를 붙어서 테스트 하기 때문에 시스템에 부하가 발생 하지 않을 수 없다.
B. 동시 발송 수 제한.
한번 SMTP에 붙어서 동시 발송에 대한 제한이 없다. 유저가 엄청 많을 경우 외부로 보내는 프로세스를 혼자 점령 해버리고 다른 유저들의 메일은 늦게발송 되는 현상이 나타난다. 물론 시스템 로드도 상승한다. 그러기 위해서는 MAX RCPT 호스트의 숫자와 MAX COMMAND의 제한하는 기능이 필요하다.
C. RFC 표준 검수.
스패머의 경우 대부분 RFC 표준을 충족하지 못하는 경우가 태반이다. 물론 스패머들은 대부분 웹플들이며, 이들은 메일 형식에 대해서 잘모른다. 물론 요즘은 점점 충족해 나가지만, 그래도 아직은 이것 만으로도 수많은 스패머들을 바보로 만들수 있다.
D. daemon-tools
양날의 칼이다. 직접 운영을 해본사람은 이것이 얼마나 피곤한 프로세스인지 알것이다.
하지만 그 반대로 엄청 도움이 된다. tcpserver와 함께 좋아 할수도 버릴수도 없는 계륵 같은 존재 이다.
비단 여기서 언급된 문제들은 Qmail 만의 문제는 아닐것이다.
그래서 요즘 T사 3사 I사 S사 A사 등등 스팸 필터장비로 유명한 업체들이 속속 등장한것이다.
물론 이것저것 테스트 해본답시고, 다른 회사의 저 장비들의25번 포트에 붙어서 이것저것 많이도 해봤다.
소감은 T사가 여러 회사들중에서 가장 많이 고민하고 있다는것을 느꼈다.
물론 저 T사의 오탐 및 버그로 인해서 고생도 많이 했다.
상대측 장비에 T사 장비가 오탐 및 버그로 인해서 아무런 문제 없는 정상메일을 스팸메일로 지정 해버리는경우다.
메일 형태 검사에서 말이다.
상대측 회사 담당자는 아무것도 몰랐고 그들은 T사에 요청에서 해결 했다. 문제에 대한 해결이 아주 빨리 되었다.
나온장비나 솔루션중에서는 사후 지원이라던가 다 생각했을때 제일 괜찮은듯....
어쨌든 급변하는 메일환경에 Qmail은 이러한 문제들이 있고 그에 대한 방어책으로 고민해본 사람들은 나의 생각에 동의할듯하다.답이 없으면 장비 사다 쓰는게 쉬울것이란 생각이든다.
각각의 문제를 해결을 위해 고민하고 또 고민 해 놓아도, 사용되지 않는 다면 무슨 의미가 있으리...
댓글 없음:
댓글 쓰기