HELO/EHLO에서의 hostname 체크 여부.
Chu-yeon Park
얼마전 메일 서버가 spam의 mail-relay가 되지 않도록 처리해 놓고, 이왕
하는 김에 그 동안 안했던 EHLO/HELO의 hostname 체킹을 엄격히 하도록
설정해 놓았습니다. 그랬더니 놀랄 만한 일이 발생했더군요. 지금껏
아무 생각도 없이 사용해 왔습니다만, 제 개인적으로 다시 뒤돌아봐야 할
것이 아닌가 싶은 내용이 있어서 몇 자 적습니다.
HELO/EHLO 커맨드에는 호스트네임이 주어지게 되는데, 이 호스트 네임이
유효한 것인지(DNS A record에 있는지 혹은 PTR record에도 있는지)의
여부를 검사하느냐 안하느냐는 좀 다각도로 생각해 봐야 하겠습니다.
물론 요즘 문제가 되는 것은, 제 3자의 mail-relay입니다만, 자신을 가린채
접근해서 슬쩍 메일 서버의 상황을 알아본다던가 하는 일은 매우 기분
나쁜 일이 아니겠습니까. 그래서, smail상의 옵션인 smtp_hello_verify,
즉 HELO/EHLO에서 주어진 hostname이 A 레코드에 있는지만을 체크하도록
설정해 두었습니다. 이렇게 해두면, 쓸데없이 Name을 속여가면서 접속하는
사용자가 있을 수 없게 되므로 추후 로그에는 아주 유용합니다.
그런데, 상당히 끔찍했던 일은, 그 이후로 MS OE사용자들은 절대로 메일을
보낼 수 없게 되었다는 점입니다. MS OE의 경우, HELO/EHLO 커맨드 시
같은 도메인에 속하는 경우, 호스트네임만 HELO/EHLO 커맨드에 네임으로
보내게 됩니다. 이렇게 되면 vaild hostname에는 반드시 dot(.)이 포함되어야
하기 때문에 reject되어 버리고 맙니다. 물론, 특정 패턴의 IP 어드레스에
대해서는 broken hostname이라도 허용하게끔 설정할 수는 있지만,
뭔가 표준을 지키는 것은 아니라는 생각이 들더군요.
또한, Netscape Message Center(Netscape mail)에서는, HELO/EHLO 커맨드를
보내지 않고 바로 MAIL FROM 커맨드를 보내게 됩니다. 이러면 smail은
HELO/EHLO 커맨드 후에 MAIL FROM 커맨드가 입력되어야 함을 알리고 역시
reject시켜 버리게 됩니다.
sendmail은 어떤지 제가 sendmail을 사용하지 않으니 알 수는 없군요.
RFC1123에서는, 유효한 hostname을 SMTP 서버에 제공해 주는 것은 클라이언트,
즉 MUA의 책임이긴 하지만, 실패하였다고 해서 MTA가 거절할 필요는 없다고
규정해 놓았더군요. 최근에 RFC1123이 제정되었다고는 하지만, 만약 고의로
broken hostname, 즉 클라이언트를 파악할 수 없는 hostname을 클라이언트가
제공한다고 한다면 이는 어디서 보상받아야 하는 겁니까.
제 개인적 생각입니다만, 이것은 전적으로 메일 클라이언트의 잘못이
아닌가 싶습니다. 저희 랩 옆에 있는 랩원이 도대체 왜 MS OE에서 이러느냐고
저에게 불평하길래 제가 해줄 수 있는 말은, "MS OE와 Netscape Mail이 원래
표준을 제대로 안 지키기 때문이다" 라고 밖에는 더 이상 말을 해 줄 수가
없더군요.
박주연
--
Chu-yeon Park <kok...@doit.ajou.ac.kr> We are KOrean KIDS, kokids!
http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x4CDC3EC9
----------------------------------------------------------------------------
Internetworking Team, DoiT! in Ajou Univ., Information & Computer Eng. Dept.
Chu-yeon Park
In article <slrn6djtgh...@doit.ajou.ac.kr>, Chu-yeon Park wrote:
>HELO/EHLO 커맨드에는 호스트네임이 주어지게 되는데, 이 호스트 네임이
>유효한 것인지(DNS A record에 있는지 혹은 PTR record에도 있는지)의
>여부를 검사하느냐 안하느냐는 좀 다각도로 생각해 봐야 하겠습니다.
>RFC1123에서는, 유효한 hostname을 SMTP 서버에 제공해 주는 것은 클라이언트,
>즉 MUA의 책임이긴 하지만, 실패하였다고 해서 MTA가 거절할 필요는 없다고
>규정해 놓았더군요. 최근에 RFC1123이 제정되었다고는 하지만, 만약 고의로
>broken hostname, 즉 클라이언트를 파악할 수 없는 hostname을 클라이언트가
>제공한다고 한다면 이는 어디서 보상받아야 하는 겁니까.
얼마전 이 글을 올리고, 몇 가지 더 확인을 해보고 나니 네임 서버 관리자들의
무사안일을 탓하지 않을 수 없군요. 특히 코넷도 그렇구요.
요 며칠 동안 PTR record가 없어서 제 메일 서버에서 거절한 리스트입니다.
국내 유수라는 말이 무색할 정도로, 이럴 수 있는가 싶군요.
02/04/1998 17:53:35: remote EHLO: questionable operand: 'mail.taegu.net':
from ro...@mail.taegu.net source [203.251.92.85]:
Remote address PTR lookup failed.
02/04/1998 20:05:08: remote EHLO: questionable operand:
'kitsys.kits.co.kr': from kitsys.kits.co.kr source [210.127.237.200]:
Remote address PTR lookup failed.
02/04/1998 20:40:04: remote HELO: invalid operand:
'topper.soongsil.ac.kr.soongsil.ac.kr':
from (topper.soongsil.ac.kr) source [192.245.249.12]: Remote address
PTR does not have matching name.
02/06/1998 00:30:00: remote EHLO: questionable operand:
'dblab.changwon.ac.kr': from dblab.changwon.ac.kr source [203.246.5.131]:
Remote address PTR lookup failed.
02/06/1998 01:13:22: remote EHLO: questionable operand:
'wave.shopping.co.kr.': from wave.shopping.co.kr.(wave.shopping.co.kr)
source [203.248.226.3]: Remote address PTR does not have matching name.
02/06/1998 19:25:00: remote EHLO: invalid operand: 'ns.ischool.co.kr':
from nobody@ source [203.228.113.1]: Remote address PTR lookup failed.
02/07/1998 00:28:34: remote EHLO: invalid operand: 'mbcadcom.mbcad.co.kr':
from root@ source [210.121.144.1]: Remote address PTR lookup failed.
02/07/1998 03:21:08: remote EHLO: invalid operand: 'public.xm.fj.cn ':
from source [202.101.103.57]: Remote address PTR lookup failed.
02/07/1998 07:15:25: remote HELO: invalid operand: 'ns.pcline.co.kr':
from source [203.227.94.1]: Remote address PTR lookup failed.
02/07/1998 08:30:08: remote HELO: invalid operand:
'sdn-ts-001pakpruP08.dialsprint.net':
from (sdn-ts-001pakpruP14.dialsprint.net) source [206.133.6.33]: Remote
address PTR does not have matching name.
02/07/1998 10:32:48: remote EHLO: invalid operand: 'thor2.sprhwy.com':
from DBDemail@ source [207.154.137.5]: Remote address PTR lookup failed.
02/09/1998 10:24:43: remote EHLO: invalid operand: 'www.joongang.co.kr':
from source [203.249.157.2]: Remote address PTR lookup failed.
02/09/1998 10:30:27: remote EHLO: invalid operand: 'locutus.mcom.com':
from (h-205-217-237-89.netscape.com) source [205.217.237.89]:
Remote address PTR does not have matching name.
02/09/1998 10:34:12: remote EHLO: invalid operand: 'newsmail.khan.co.kr':
from source [203.234.154.2]: Remote address PTR lookup failed.
02/09/1998 14:53:46: remote EHLO: invalid operand: 'amazon.com':
from (154-31.amazon.com) source [204.177.154.31]:
Remote address PTR does not have matching name.
02/09/1998 20:33:43: remote EHLO: invalid operand: 'ns.castmail.co.kr':
from (www.castmail.co.kr) source [210.105.204.1]:
Remote address PTR does not have matching name.
02/09/1998 21:00:20: remote EHLO: invalid operand: 'ns.goldbank.co.kr':
from ibank@ source [210.123.102.1]: Remote address PTR lookup failed.
02/09/1998 21:24:19: remote EHLO: invalid operand: 'igate.kppinc.com':
from source [210.116.248.57]: Remote address PTR lookup failed.
02/09/1998 23:23:13: remote HELO: invalid operand: 'classea.com.br':
from (classea.classea.com.br) source [200.241.48.1]:
Remote address PTR does not have matching name.
02/10/1998 02:14:54: remote EHLO: invalid operand: 'soback.kornet.nm.kr':
from kokids@ source [168.126.3.3]: Remote address PTR lookup failed.
메일 관련 프로그램 만드는 회사의 메일 시스템이 엉망인 것은 말할 것도
없거니와 한국 최대 통신망이라는 코넷은 정말 열악하기 그지 없군요.
외국의 몰지각한 spammer도 있긴 합니다만, 이렇게 엉망으로 만들어 놓고
무얼 하겠다는 것인지 알 수가 없는 노릇입니다.
사소한 것에서의 보안이 심각하다는 것을 망각하고는 있지 않나 생각해 봐야
하지 않나 싶습니다. 인터넷 세상이 못믿는 세상이니 Name spoofing을 하는지
체크해 보기 위해 ptr 레코드까지 찾아봐야하고, MX 레코드가 제대로 박혀
있는지 확인도 해봐야 할 뿐더러, 3rd-party mail-relay가 되고 있지나
않은지 늘 체크해야 하는 현실이 좀 안타깝긴 하지만 조금만 관심을 가지면
해결될 수 있지 않을까 생각해 봅니다.
Lee aka mmung
Chu-yeon Park <kok...@doit.ajou.ac.kr> wrote:
> In article <slrn6djtgh...@doit.ajou.ac.kr>, Chu-yeon Park wrote:
> >HELO/EHLO 커맨드에는 호스트네임이 주어지게 되는데, 이 호스트 네임이
> >유효한 것인지(DNS A record에 있는지 혹은 PTR record에도 있는지)의
> >여부를 검사하느냐 안하느냐는 좀 다각도로 생각해 봐야 하겠습니다.
> > (... 중략 ...)
> >RFC1123에서는, 유효한 hostname을 SMTP 서버에 제공해 주는 것은 클라이언트,
> >즉 MUA의 책임이긴 하지만, 실패하였다고 해서 MTA가 거절할 필요는 없다고
> >규정해 놓았더군요. 최근에 RFC1123이 제정되었다고는 하지만, 만약 고의로
> >broken hostname, 즉 클라이언트를 파악할 수 없는 hostname을 클라이언트가
> >제공한다고 한다면 이는 어디서 보상받아야 하는 겁니까.
> 얼마전 이 글을 올리고, 몇 가지 더 확인을 해보고 나니 네임 서버 관리자들의
> 무사안일을 탓하지 않을 수 없군요. 특히 코넷도 그렇구요.
> 요 며칠 동안 PTR record가 없어서 제 메일 서버에서 거절한 리스트입니다.
> 국내 유수라는 말이 무색할 정도로, 이럴 수 있는가 싶군요.
## 중략 ##
> 사소한 것에서의 보안이 심각하다는 것을 망각하고는 있지 않나 생각해 봐야
> 하지 않나 싶습니다. 인터넷 세상이 못믿는 세상이니 Name spoofing을 하는지
> 체크해 보기 위해 ptr 레코드까지 찾아봐야하고, MX 레코드가 제대로 박혀
> 있는지 확인도 해봐야 할 뿐더러, 3rd-party mail-relay가 되고 있지나
> 않은지 늘 체크해야 하는 현실이 좀 안타깝긴 하지만 조금만 관심을 가지면
> 해결될 수 있지 않을까 생각해 봅니다.
전적으로 동감입니다.
자신의 리버스 도메인을 등록하지 않음은
(1) 무식해서
(2) 게을러서
(3) 무언가 나쁜 짓을 꾸미기 위해서
라고 밖에는 말할 수 없습니다. 운영상의 경험인데,
실제로 보라넷은 리버스 등록이 잘 되어 있는 편이지만,
고객 사이트들은 또 그렇지 못합니다.
더우기, 요즘에는 C-class를 반으로 쪼개서 (25비트 마스킹)
할당하는 열악한 상황이라 리버스 도메인 등록이 더 X같아 졌구요.
고객 사이트는 고객이 스스로 운영자를 지정하여 그 사람이
열심히 공부하고 적용하고 해야 할텐데
DNS가 뭐죠? 스팸이 뭐죠? 하는 사람이 그 자리에 앉아 있답니다.
물론 처음부터 다 아는 사람은 없습니다만 노력하는 자세가 아쉽습니다.
--
======-----======-----======-----======-----======-----======
이성희 Lee, Sunghee BORANet Team, DACOM
Email: mmung4u@*BORA.NET* @*chollian.net* (omit * when mail)
새로만든 계속 살이 붙어가는 홈페이지 http://mmung4u.bora.net
======-----======-----======-----======-----======-----======
박종대
Lee aka mmung <mmu...@news.dacom.co.kr> wrote:
: 자신의 리버스 도메인을 등록하지 않음은
: (1) 무식해서
: (2) 게을러서
: (3) 무언가 나쁜 짓을 꾸미기 위해서
: 라고 밖에는 말할 수 없습니다.
기계를 DNS 등록하지 않는데 대한 변명들..
1. 귀찮아서
2. 게을러서
3. 보안이 더 잘 되니깐.. -_-
--
박종대
-- ' C-language Edition
#define cdpark /* KAIST, CSDept, Theory of Computation Lab. */
#include <signature.h> /* the Hitchhiker's Guide to the Internet?? */