Sendmail의 개념정리가 안됩니다.
sendmail의 구성원리에 대해 살펴봤습니다.
사용자A가 MUA에서 메일을 작성하면 서버A에서 smtp사용자 인증을 하고 큐에 대기되어 있다가 서버B에서 받는 사용자를 확인하고 저장되어 있다가 imap이나 pop3를 통해 사용자B가 받는 방식 이더군요.
sendmail saslauthd와 dovecot을 설치하고 돌려보았습니다.
궁금한 것이 sendmail.mc에서 릴레이를 아래와 같이 오픈해 주면 외부에서도 보낼 수가 있다는데 그 의미를 정확하게 모르겠습니다.
DAEMON_OPTIONS(`Port=smtp,Addr=0.0.0.0, Name=MTA')dnl
dovecot을 시작하지 않을 때도 제 서버 자체에서 발송한 메일은 제 서버에서 받을 수도 있더군요.
그렇다면 외부에서 보낼 수가 있다는 의미는 서버의 IP와 다른 원격지에서
어떠한 MUA인 메일 클라이언트를 사용해서 제 서버에 접속해 메일을 보낼 수 있다는 의미인지요?
서버 자체 콘솔에서 테스트를 했을 때 정상적으로 송/수신이되어 25번 포트로 모든게 이루어지는 구나 싶어 dovecot의 필요성도 못느꼈습니다만 이게 없으면 메일 클라이언트에서 메일을 받지 못하는 것을 보고
dovecot의 필요성을 알았습니다.
dovecot의 imap과 pop3의 143/110번 포트는 메일클라이언트가 메일을 받기 위해 존재하는 구나라고 이해를 했는데 서적을 보니 어떻게 된 영문인지 싶습니다.
외부서 발송시 dovecot이 필요하다고 하고 있습니다.
--------------------------------------------------------------
발송자에 대한 smtp인증은 saslauthd데몬을 사용하여 발송자의 권한이 있는지 체크하여 발송을 허가할 것이다. 또한 외부에서 pop3,imap를 이용해서 접속하는 유저들에게 메일 발송권한을 주기 위하여 dovecot패키지를 이용해 제어할 예정이다
--------------------------------------------------------------
메일클라이언트에서 메시지를 보낼 때 서버의 root계정 암호를 물어보아야만 보낼 수 있던 데 이것은
지극히 정상적인 것인지요?
부연 설명하겠습니다.
만약 서버의 도메인이 abcd.co.kr이고 test1이라는 계정을 제가 타인에게 발급을 해 주어 그 사람이
test1@abcd.co.kr로 메일 발송을 원할 경우 서버의 루트계정의 암호를 물어보는 현상이 생깁니다.
이게 정상적인 것이라면 타인에게 메일 계정을 발급한다는 것은 서버 가져가라는 셈이 되는 거겠네요.
메일 서버를 구축한다는 것이 관리자에게만 발송권한을 주는 것은 아니지 않나요?
그렇다면 dovecot설치도 필요가 없는 것이겠구요.
서버설정 방법이 잘못되었을 수도 있고 원래 개념이 그러할 수도 있는데 이해 좀 하고 싶습니다.
/etc/mail/access에서 릴레이 허용 여부를 결정하게 되는데
여기에connect:abcd.co.kr RELAY를 명시하면
이 것은 abcd.co.kr의 IP를 리버스해서 찾아서 그 IP에 해당하는 클라이언트만 발송을 허용하는 것인지요?
해보고 해보다 보니 이게 맞나 저게 맞나 자꾸 의문도 들고 제가 이해가 가지 않는 부분이 많아서
명쾌히 지적해 주시고 설명해 주셨으면 해서 도움을 요청합니다.
relay 를 무조건
relay 를 무조건 허용하게 되면 spam 메일 발송처로 악용됩니다.
무조건 불허하게 되면 외부에서 "보내는 메일 서버"로 사용할 수 없게 됩니다.
이 문제를 해결하기 위해 SMTP AUTH 가 도입되었습니다.
그전에는 imap/pop3 서버로 인증 성공한 사용자의 ip 에 대해 얼마동안 relay 를 허용하는 등의 꼼수를 사용했었고요.
공개용 sendmail 에 정식으로 SMTP AUTH 가 들어간 지는 10년이 훨씬 넘은 것 같습니다.
SMTPS(SMTP over SSL/TLS) 와 거의 같은 시기에 포함된 걸로 기억합니다.
(AUTH 절차를 포함하려니 SSL/TLS 도 고려해야했겠죠.)
OTL
답변주셔서
답변주셔서 감사합니다.
말씀하신 내용에 대한 감이 잘 오지 않는군요.
릴레이를 무조건 허용하면 스팸 때문에 위험하고 무조건 불허하면 보낼 수가 없고... 이를
해결하기 위해 SMTP인증이 도입되었다는 말씀 잘 들었습니다.
말씀하셨듯 sendmail.cf에서 릴레이를 0.0.0.0으로 오픈 했을시에는 외부에서 smtp인증도 통하고
127.0.0.1만 오픈시에는 smtp인증이 불가능하다는 것을 확인 했습니다.
그렇다면 access.db에 의한 릴레이 접근/제어 설정은 saslauthd데몬이 띄워지면 무시되는 것인지요?
즉. SMTP도입전의 이야기라 이것이 띄워지면 access에 의한 릴레이 접근/제어 설정이 무시되는 것인가 하는 겁니다.
개인 계정을 발급받은 사용자를 서버에서 관리가 가능하고 메일을 발송할 수 있게끔 하고 싶은데 이와 같은
서비스가 www.daum.net과 같은 웹메일 서비스에서는 되는 것으로 압니다.
웹메일에서는 smtp를 이용한 인증이 어떤 루틴을 따르는 것인지요?
내부 웹메일 프로그램상 그 서버에서 설치되어 작동이 되므로 사용자 로그인시 루트 암호를 이용한
smtp인증이 필요가 없는 것인지...
선더버드를 통해 test1@abcd.co.kr계정으로 테스트 해 본 바로는 발송시 서버root의 암호를 물었습니다.
웹메일에서는 서버 루트의 암호를 묻지 않으니 생긴 의문입니다.
웹메일을 통하지 않으면 개인 계정을 발급해주고 그들에게 발송 권한을 주는 시스템은 꿈같은 것인가요?
위에서 외부에서 smtp인증을 통해 메일을 보내려고 오픈 릴레이를 만들어 줬었습니다.
smtp인증을 위해서는 릴레이를 무조건 오픈을 해줘야 하는게 맞지요?
telnet abcd.co.kr 25하면 암호없이 누구나가 접속이 가능한데 이 것을 통해서는
smtp인증을 거치지 않으니 스팸으로 악용할 수 있지 않나요?
질문이 많아서 죄송합니다. 부탁드립니다.
문서를 정독하지
문서를 정독하지 않으면 아무 것도 못합니다.
MTA의 동작에 대한 이해를 하세요.
1. 메일을 받는다
2. 메일을 보낸다.
3. 메일을 중계한다.
1번 동작은 자신의 계정에게 온 메일을 받아서 procmail 등의 backend에게 넘기는 동작이고.
2번 동작은 자신의 queue 에 있던 것을 가져와서 다른 메일서버로 보내는 동작입니다.
3번 동작은 다른 서버로 가야할 메일을 받아서 자신의 queue 에 넣는 동작입니다.
MUA의 "보내는 메일 서버" 설정은 위에 설명한 것 중에서 3번 동작을 할 서버를 지정하는 것입니다.
클라이언트가 SMTP AUTH 를 시도하지 않으면 기본 규칙인 access.db 등이 적용될 테죠.
내부 네트웍은 relay 를 허용합니다.
사무실의 사원들이 메일을 보내야 하니까요.
웹메일도 마찬가지 입니다. 폼메일 서비스를 제공하는 서버의 IP 를 등록해주는 것으로 족합니다.
telnet xxx 25
단계에서는 메일을 받는 동작을 해야하는지 중계하는 동작을 해야 하는지 아직 서버가 결정할 수 없습니다.
To: 에 적히는 주소를 보고 자신이 받을 메시지라면 받고,
다른 서버로 중계해야 할 것이라면 클라이언트의 SMTP AUTH 를 받던가 access.db 를 참고하던가해서
결정하겠죠.
OTL
스팸 얘기가 나와서
스팸 얘기가 나와서 말인데,
받는 쪽 메일서버가 보내는 쪽의 메일 서버를 검사할 수도 있습니다.
가장 단순한 형태가 reverse lookup, 즉 ip 주소로 domain name 을 찾는 방법이고,
최근에 제안된 것이 DNS 서버에 SPF 레코드를 추가하는 겁니다.
스팸을 보낼 때만 잠깐 떴다가 사라지는 악질 MTA 를 무시하기 위한 용도로 사용됩니다.
웹메일 서비스를 제공하는 곳들은 대부분 reverse lookup 정도는 검사하고 있고,
DNS 서버의 SPF 레코드까지 검사하는 곳도 있습니다(google mail).
sendmail 에도 reverse lookup 검사를 할 것인지 SPF 레코드 검사를 할 것인지 설정하는 지시자가 있을 겁니다.
위에 설명한 MTA 동작들 중 1번 동작에 해당되는 내용입니다.
시험삼아 구성한 메일서버를 이용해서 메일을 보냈는데 다른 곳에서 못 받더라.. 하실까봐 적었습니다.
OTL
아주 명확하게
아주 명확하게 개념을 정리해주시네요.
그런데, sendmail에서 spf 관련 milter 같은 것을 추가로 설치하지 않고도 spf 설정이 가능한가요?
그건 아니죠?
--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
SPF 는 최근에 말만
SPF 는 최근에 말만 들었고 어떻게 설정해야하는 지 모르고 있으며
SPF 의 단점을 개선하고자 등장한 SRS 라는 것도 있다던데 역시 말만 들었습니다.
나머지들은 14년쯤 전에 삽질하던 과정에 알게된 것들입니다.
가상계정 인증을 위해 pgsql/mysql 을 붙이는 개인적인 삽질이었습니다.
요즘에는 PAM 이 대세라 참 편하죠.
OTL
댓글 달기