아웃룩 익스프레스에서 “배달” 을 눌러 메일을 수신하려고 할 때 메일이 받아지지 않는 경우가 있다. 이러한 경우에는 아래와 같이 여러가지 이유가 있을 수 있으니 아래의 사항에 대해 하나씩 원인을 찾아보기 바란다.
(1) IMAP 패키지가 설치되지 않았을 경우
서버에 배달되어 있는 자신의 계정으로 온 메일을 클라이언트 PC에서 받으려면 pop3 데몬이 반응하게 된다. pop3d 는 IMAP 패키지안에 포함되어 있으므로, IMAP 패키지를 설치하여야 pop3 를 사용할 수 있다. Rpm 으로 설치했다면 rpm –q imap 으로 현재 시스템에 imap 패키지가 설치되어 있는지 확인한다. 또는 /usr/sbin/ipop3d 파일이 있는지 확인해 본다.
(2) Inetd 에 설정되어 있지 않을 경우
pop3d 는 inetd 또는 Xinetd 에서 작동하게 된다.
/etc/inetd.conf 또는 /etc/xinetd.conf 파일을 살펴보아 ipop3 가 주석처리 되어 있거나 pop3 가 disable = yes 로 되어 있지는 않은지 확인한다.
(3) TCP Wrapper 에 설정되었는지 여부 확인
/etc./hosts.deny 에 pop3d 접근이 차단되지는 않았는지 확인한다.
(4) 계정에 Lock 이 걸리지 않았는지 확인
메일을 받는 과정에서 갑자기 회선이 끊기거나 PC가 다운되는 등 비정상적으로 종료시 서버의 pop3d 프로세스가 죽지 않고 계속 남아 있는 경우가 있다.
이러한 경우 계정에 “Lock 이 걸렸다” 라고 하며 이러한 경우에는 해당 프로세스를 찾아 kill 을 하면 된다. 만약 계정에 Lock 이 걸린 상태에서 아웃룩 익스프레스에서 메일을 수신하려고 하면 아래와 같은 에러가 나게 된다.
“메일 서버에 로그온하는 데 문제가 있습니다. 지정한 암호가 거부되었습니다.
계정: 'dolmuri', 서버: 'dolmuri.pe.kr', 프로토콜: POP3, 서버 응답:
'-ERR Can't get lock. Mailbox in use', 포트: 110, 보안(SSL): 아니오,
서버 오류: 0x800CCC90, 오류 번호: 0x800CCC92”

(5) Pop3 접속이 많은 경우
Pop3d 가 서비스되는 inetd는 기본적으로 60초동안 40회의 접속을 받아들이
도록 (즉, maximum 40회 fork되도록) 설정되어 있다. 따라서 짧은 시간에 pop3d
요구가 많을 경우에는 메일로그에 pop3/tcp server failing (looping) 라는 메시지가
나면서 pop3d 데몬 자체가 다운되어 버리므로 동시에 처리 가능한 프로세스의 한계
를 적절히 높여주어야 한다.
이를 위해서는 /etc/inetd.conf 를 열어 아래와 같이 수정하면 된다.

이전설정)
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d

변경 설정)
pop-3 stream tcp nowait.200 root /usr/sbin/tcpd ipop3d
(위의 경우 처리 가능한 프로세스를 200회로 늘려주었다.)
이후 killall -HUP inetd 를 하면 된다.

(6) 110 번 포트로 확인
아래와 같이 pop3d 포트인 110번 포트로 직접 접속하여 수작업으로 확인 가능하다.

# telnet mail.nuri.net 110 # 110번으로 직접 확인
Trying 210.116.105.100...
Connected to mail.nuri.net.
Escape character is '^]'.
+OK The Inet Hosting POP at idial-pop2.nuri.net starting.
user aaaaa # aaaaa 라는 계정으로 접속
+OK Password required for dolmuri.
pass krw # aaaaa 의 암호 krw 입력
+OK aaaaa has 31 visible messages (0 hidden) in 257562 octets.
quit
+OK Pop server at idial-pop2.nuri.net signing off.
Connection closed by foreign host..

위의 경우는 정상적인 경우이며 에러가 있을 경우(만약 암호가 다르게 설정되었을 경우 -ERR Bad login 와 같은 메시지가 나게 된다.) 각각의 경우에 따라 에러 메시지를
각각 확인할 수 있다.

sendmail 과 관련된 몇 가지 명령어

>> mail1q
mailq 프로그램의 목적은 큐잉된(/var/spool/mqueue 에 저장된) mail 메시지의 요약된 정보를 보여준다. 네트워크 다운등 어떤 특정한 이유로 바로 발송되지 못한 메일은 일차적으로 /var/spool/mqueue 에 큐잉된 상태로 저장된 후 일정 시간마다 발송을 위해 재시도가 되는데, 현재 큐잉된 메일 메시지의 요약 정보를 보려면 아래와 같이 확인할 수 있다.

# mailq

/var/spool/mqueue/q1 (2 requests)
----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------------
f7A84oV15068 1446 Fri Aug 10 17:04 nobody
(Deferred: Connection timed out with kebi.net.)
darling@kebi.net
f775ieF24893 521898 Tue Aug 7 14:44
(Deferred: Connection timed out with mail.unitel.net.)

/var/spool/mqueue/q2 is empty
/var/spool/mqueue/q3 (1 request)
----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------------
f775nJF25249 230815 Tue Aug 7 14:49
(Deferred: Connection timed out with hanmail.com)
cuwww23@hanmail.com

위 메시지를 보면 어떠한 이유로 메일이 발송되지 못하고 있는지를 추측할 수 있다.
3 메시지 모두 수신자의 e-mail 주소를 잘못 기입했기 때문인데, 각각 kebi.com 인데, kebi.net 으로 unitel.co.kr 인데, unitel.net 으로 , hanmail.net 인데, hanmail.com 으로 도메인 주소를 잘못 기입하여 메일을 발송하여 서버에서 메일을 발송하지 못하고 큐에 저장되어 있는 것을 확인할 수 있다.
여기에서 주의할 점은 mailq 명령어는 일반 유저로 실행하여 확인이 가능하므로 퍼미션을 700 등으로 조절하여 일반 유저들은 실행할 수 없도록 하는 것이 좋다.

>> mailstats
mailstats 프로그램은 현재의 메일 송수신과 관련하여 통계를 보여준다.

* 현재의 메일 통게를 보려면 아래와 같이 확인할 수 있다.

# mailstats
Statistics from Sat Aug 11 04:02:02 2001
M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer
1 0 0K 3 317K 0 0 *file*
4 690 596691K 824 137070K 68426 0 esmtp
9 63 12212K 0 0K 27 0 local
=============================================================
T 753 608903K 827 137387K 68453 0
C 753 827 68453

이를 적절히 이용하면 mrtg 를 이용해 일정 시간마다 발송되고 수신되는 메일의 개수를 통계로 내어 그래프로 볼 수 있다.

시스템의 제한 설정과 서비스의 안정성은 매우 깊은 연관성을 가지고 있다. 기본적으로 대부분의 서비스는 유저가 사용 가능한 시스템의 자원 제한이 거의 설정되어 있지 않은데, 메일 서비스도 마찬가지이다.
최근에는 메일의 이용율이 높아지고, 메일의 컨텐츠도 전통적인 텍스트 방식에서 음성,이
미지등 각종 동영상이 주종을 이루면서 용량도 점점 커지고 있다. 물론 그만큼 하드웨어나
메일 서버의 소프트웨어적인 성능도 향상되고 있지만 용량이 큰 메일을 주고 받는다면
당연히 시스템의 부하가 올라가기 마련이고 이로 인하여 같은 서버내 다른 서비스에까지
영향을 미치게 된다. 따라서 시스탬에서 보내는 메일 서비스(SMTP)나 받는 메일 서비
스(POP3)를 제공하고 있다면 용량이 큰 파일을 주고 받는 것을 적절히 제한할 필요가 있다.

sendmail 은 로컬의 메일을 외부로 발송하는 SMTP(보내는 메일서버) 기능도 있지만 외부에서 서버내 계정으로 전송되는 메일을 받아서 서버에 저장하는 기능도 있다. 이때 기본적으로는 보내거나 받는 메일의 양에 대한 제한이 전혀 없어 10메가 이상이 넘는 큰 사이즈의 메일이 송 수신 될 경우 서버에 과부하가 걸릴 수 있으므로 아래와 같이 각각의 설정(보내는 메일과 받는 메일의 양) 을 적절히 제한하여 설정하는 것이 좋다.

>> SMTP 서버에서 보내는 양 제한하는 법.

/etc/mail/sendmail.cf (또는 /etc/sendmail.cf. 이는 sendmail 의 패키징 방법에 따라 다르다.) 파일에서 다음과 같이 MaxMessageSize 부분의 주석을 제거하고 제한하고자 하는 적절한 값을 입력한다.

# maximum message size
O MaxMessageSize=5024000

위와 같이 설정하였을 경우 현재의 서버를 보내는 메일 서버로 이용시 첨부 파일이 5M 이상 초과하거나 웹에서 /usr/sbin/sendmail 을 실행하여 외부로 메일을 발송하는 메일링 리스트등의 프로그램에서도 메일 발송시 5 메가 이상의 메일은 보낼 수 없게 된다.
5024000 은 byte 단위이며 설정 변경 후 변경된 내용을 적용하려면 killall –HUP sendmail 로 sendmail 데몬을 Refresh 하면 된다.

>> 받는 메일 서버에서 받는 양 제한하는 법.

외부에서 서버로 들어오는 메일에 대해서 용량을 제한하고 싶다면 같은 파일(sendmail.cf) 에서 "Local and Program Mailer specification" 부분을 설정해 주면 된다.

Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30,
R=20/40, M=5024000, T=DNS/RFC822/X-Unix, A=procmail -Y -a $h -d $u

위와 같이 T=DNS/RFC822/X-Unix 앞부분에 M=5024000 부분을 추가해 주면 된다.
마찬가지로 5024000는 byte 단위이며 각자의 시스템 환경에 따라 원하는 용량만큼 적절히 설정해 주면 된다 역시 설정 변경 후 sendmail 을 refresh 하면 적용이 된다.
위의 경우 서버에서는 5메가 이상의 메일은 수신하지 않으며 5메가 이상의 메일을
보낸 이는

552 5.2.3 ... Message is too large; 5024000 bytes max
554 5.0.0 ... Service unavailable
와 같은 에러 메시지를 회신받게 된다.

아울러
# maximum number of recipients per SMTP envelope
O MaxRecipientsPerMessage=20

와 같은 부분이 있는데, 이 부분은 한번에 메일 발송 시 동시 발송(참조 발송)이 가능한 메일 계정의 수를 뜻하는 것으로 SMTP 서비스를 제공한다면 이 설정을 적용하는 것이 좋다. 기본적으로 이 값에도 제한이 없으므로 먼저 주석을 삭제한 후 적절한 값을 설정해 주면 한번에 동시 발송 가능한 메일의 수도 제한할 수 있다.
(위의 경우에는 한번에 참조 발송이 가능한 메일 유저를 20명으로 제한)
설정이 끝난 후에는 killall –HUP sendmail 로 sendmail 을 재가동해주면 적용된다.