김판중 2014-12

엔메일쓰다가 구글메일로 바뀌었습니다.
다들분들 불만은없는데
전 용량큰 파일 보내고 받을 때 느린게 좀 아쉽더라구요.

신성공 2014-12

선배님 답변감사합니다. 구글메일같은건 쓸수없으며, 저희 자체 회사 도메인을 써야한다는 점입니다.

김판중 2014-12

기업용 메일 서비스 말씀 드린겁니다
해당 도메인으로 사용하는겁니다.

https://www.gmail.com/intl/ko/mail/help/work.html

신성공 2014-12

답변감사합니다.
이거 공짜이며, asp.net인 저희 그룹웨어와 연동가능한가요? 아니면

GMAIL로 계속 접속을 해서 보는건가요? 자꾸 물어뵈어 죄송합니다.

잠깐 살펴본바 이거는 직접 계정을 생성하고 관리를 할수없는구조인것같습니다만,,

계정을 직접 관리하고, 생성하고, 용량을 조정하고 할수있어야 되는데 말이죠.

NAS로는 무리가 있습니까?

무아 2014-12

유료 입니다. 그룹웨어와 연동은 글쎄요.. 가능하더라도 제약이 많을 듯 합니다. 그룹웨어를 생각한다면 gmail은 아닐듯 합니다.
mail.회사도메인 으로 접속합니다. 그러나 gmail 로 접속한 ui가 나오며 gmail 로 접속하는 것과 다를게 없습니다.
직접 계정을 생성하고 관리할 수 있습니다. 용량도 조정할 수 있을 겁니다.

SEITIES강승… 2014-12

제가 구글 비즈니스 서비스 썼었습니다. 개정당 5불/월 합니다...  5인정도의 회사에서 썼었는데요...
구글서비스를 모두 회사도메인 네임으로 쓸수 있습니다... 구글 그룹웨어라고 하나... 구글비즈니스라고 하나... 하여간 있습니다...

단! 서비스지원이 한국에는 좀 허접합니다...

개인적으로 구글서비스를 좋아하긴 합니다만... 매달 나가는돈도 그렇고... 나의 자유도 좀 그립고..

리눅스 서버를 하나 돌리시는것도 나쁘지 않다고 생각합니다...  안정성이나 기타등등에서 구글을 따라갈수는 없겠지만 직접 운영하는 서버이니 자유롭고... 유져가 많다면 금액적인 부분에서 투자대비 나쁘지 않죠...

박문형 2014-12

윈도우즈2000이 요즘시스템에 설치 불가이기에 발을 잡는군요..

지금사용하시는 시스템 사양이어떻게되는지
지금사용하시는 메일프로그램 공급업체에서 요즘 나오는시스템과 OS용으로 만들어진 프로그램이 있는지
메일시스템의 마이그레이션이가능한지.
(구형서버 데이터를 신형서버 새로운 프로그램(?)에 이상없이 데이터 옮겨 사용하기)


사용하시는 메일프로그램을 잘 알아서 풀어야 풀릴 것입니다.

신성공 2014-12

선배님 답변감사합니다.
그냥 데스크탑에 윈도우 2000을 깔아놨더라구요...흑흑
서버는 저희 회사에서 자체적으로 돌리고있씁니다. kt 기업랜선으로 말이죠.

하늘하늘 2014-12

2가지를 고민하셔야 합니다.

1. 서버교체
2. 서비스 이관

요즘 서버야 워낙 좋으니 적당히 알아서 잘~? 고르시면 문제 없을것 같아요.
현재 서버의 사양과 사용자, 필요 용량 등을 적어서 질게에 올리면 많은 분이 답변을 주실겁니다.

문제는 서비스 이관인데요 신규 서버에 셋팅을 하고 기존 사용자의 데이터 이관부분을
직접 진행할 수 있느냐 없느냐에 따라 지옥을 경험하실 수 있습니다.

제일 먼저 서비스 이관을 어떻게 진행하실지 확인하셔야 합니다.
직접할지, 업체에 도움을 받을지, OS는 어디까지 지원을 하는지 등등

서비스 이관에 관한 고민이 끝나면 서버를 고르시면 됩니다.

어렵네요 ㅎㅎ

신성공 2014-12

선배님 답변늦어죄송합니다. 식사시간이 겹쳐버렷습니다.

1.서버교체는 어느정도 사양이 면될까요? 메일사용자는 현재 500명정도 됩니다. 데이터사용량은 2테라정도 됩니다.

2. 서비스 이관 문제..는... 가장 큰 문제네요.... 흑흑

이지영 2014-12

http://www.passkorea.net/Data/Nmail%2045%20Install%20Guide.pdf

보시면 NMAIL은 서버 2008 / SQL 2008까지를 첨부의 버전에서 지원합니다.
구조를 봐서는 데이터 이관은 크게 어렵지않을듯한데,
테스트 머신에 설치하고 데이터 복제하여 테스트해보시면 될듯합니다.

신성공 2014-12

답변 감사합니다. 지적해주신 부분은 알고있습니다만, 유료 인점과, 지금까지 써본바로는 넷메일이 느리고 그런점들을 벗어나고싶어하십니다.

향촌 2014-12

Nmail 현재 버전은 메일내용을 DB 에 저장해서 쿼리로 가져오는 방식일겁니다.
DB 속도가 떨어지지 않는다면 페이징은 크게 걱정안해도 되지 않을까요?

신성공 2014-12

답변감사합니다. DB속도가 뭐때문에 떨어지는지 모르겠습니다.

음 구조가요.

1. 넷메일 서버 , 그룹웨어와 DB 서버
넷메일에서 메일 eml이 들어오고 , 그룹웨어로 접속을하면 넷메일 eml파일을 가져오는구조입니다.
근데 너무 느립니다... 메일을 못가지고 오는경우도 발생합니다.

김문형 2014-12

저는 nmail을 사용한 적은 없습니다.
흠 쿼리 문제라면 SQL 쪽에서 쿼리로 확인을 해 보시는게 빠르지 싶습니다.
혹시라도 nmail 버전이 몇 이시려는지요.
제작사 홈페이지 보니 3.3 버전에서 페이징 패치가 있던데 그 전 버전이면 페이징에 문제가
있다고는 합니다.
그냥 일반적으로 본다면 웹에서(아마도 그룹웨어가 웹 이실겁니다.) 조회 할때 자료의 양이 많으면
항상 문제가 생깁니다. 그걸 적절하게 끊어서 보여 주어야 하는데 사용 해 보지 않아 namil이 문제인지
그룹웨어 쪽이 문제인지는 알 수 없겠군요.
눈 앞에 보인다면 곰곰히 고민을 해 보겠지만 그렇지 않은 상황이라.
일단 nmail 버전 부터 확인을 한번 해 보시는게 먼저 일것 같습니다.

신성공 2014-12

선배님 답변감사합니다. 버전은 3.8 입니다.
계속 분석해보고 알아보고 있는데아무래도 DB와 , 애플리케이션서버가 하나로 쓰다보니 발생되는 문제같습니다.

NAS가 문제가 아니라 DB서버를 분리해야 하는 상황이 올것으로 예상됩니다. 흑

zepinos김종화 2014-12

아마 pop3 로 메일리스트를 불러와서 그럴 겁니다.

그런 회사들의 특징이...메일함에 메일을 잔뜩 쌓아놓고 있는 경우라서 그렇구요.

nmail 의 장점이 DBMS 로 메일을 관리하고 이를 직접 컨트롤 할 수 있다...인데, pop3 로 이를 꺼내오면 nmail 의 장점을 하나도 활용하지 못하는 것입니다.

당장에 프로토콜이 imap 만 되어도 메일 헤더만 읽어오기 때문에 속도 개선이 눈에 띄게 됩니다.

pop3 는 메일 헤더와 본문을 분리하지 못하고 모든 목록을 요청해서 받아야 페이징도 되고 제목도 볼 수 있는 구조입니다. 그래서 pop3 클라이언트 세팅시 사본을 서버에 저장...같은 옵션을 켜놓았을 경우 서버에 eml 파일이 계속 쌓이고...조회할 때마다 전체 메일을 다 전송받아서 확인을 하니 느리죠.

이 내용을 가지고 예전에 모 업체 그룹웨어에 컨설팅 해준 적도 있습니다. 물론 그 땐 메일 서버가 nmail 은 아니고 qmail 입니다.

해결방법은...그룹웨어를 뜯어고치라는 겁니다. nmail 의 내용을 DBMS 에서 직접 읽어오게 바꾸던지, imap 으로 가져오게 바꾸던지(근데 nmail 이 imap 이 있나 모르겠네요), 그룹웨어에서 pop3 뒤져서 가져온 뒤 서버에서 내용을 지우고 자체적으로 가져온 내용을 분석해서 DB 에 별도 보관해서 다음부턴 그걸로 보여주던지...예전 그룹웨어 개발할 때 nmail 썼는데, 당연하게도 DBMS 에서 쿼리 조회해서 처리하는 형태였습니다. 필요할 경우 eml 파일을 개별적으로 꺼내서 사용하는 방식이구요.

그러고보니 nmail 은 자체적으로 웹메일을 제공해줍니다. 그건 DBMS 에서 데이터를 가져오죠. 그룹웨어 회사가 안망했다면 그걸 기반으로 메일을 처리하도록 수정해달라고 하는게 좋을 겁니다.

신성공 2014-12

선배님 답변감사합니다.
정말 쪽집게이십니다. 메일이 1만통이 기본으로 한명당 넘어가며, 백업도 안하고, 용량 부족하다고, 지우지도 않구요. 지우라고하면 다중요하다고 하고요. 정말 저희 회사를 왔다 가신것같습니다.

pop3로 되어있습니다.
그리고 그룹웨어서버에서 메뉴버튼에서 웹메일 버튼을 클릭하는 순간 자기 자신의 넷메일서버에 접속해 eml파일을 가져와서 이 eml파일이 DB에 녹아 듭니다. 그다음부터는 DB에서 로드하여 보게됩니다.

그룹웨어 회사에 맡긴것이 아니옵고,
예전 그만둔 선배들이 직접 만든 ASP.NET로 그룹웨어 입니다.
그걸 개조하고 뜯을려고 저도 여기에 입사하게되었구요.
근데 전 ASP.NET 는 한번도 해보지 못했고, php만 조금압니다.
그래서 막막합니다.

서버는 Nmail3.8 윈도우 2000, 30기가하드에 eml파일저장되고있습니다.
그룹웨어서버는 윈도우 2012이며, 그룹웨어 DB도 함께 사용되어지고있습니다.

메일 부분의 DB 총사용량은 20기가이며,
메일 첨부파일부분은 하드에 저장되어 끌어오게됩니다.

D:그룹웨어 애플리케이션
E:메일첨부파일 (2테라에서 800G사용중)

텍스트는 DB에 저장되고, 첨부파일은 하드에저장됩니다.

과연 왜 받은편지함을 누르면, 뱅글뱅글 돌까요? 흑

천외천oo노… 2014-12

십중팔구 ASP.NET 프로그램은 POP3로 접속해서 메일을 읽은 다음 파싱하는 구조가 아니고...EML 파일을 바로 땡겨와서 해독(?)할 겁니다. (POP3 컴포넌트 같은 걸 썼을수도 있긴 하겠네요. 여하간...)
POP3 로 바로 가져오려면 TCP 로 POP3 접속해서 커멘드 날려야하는데...그런걸 웹개발자가 했을리는 만무하고...써드파티 컴포넌트 같은데다...EML 파일 경로 지정해주고...거기서 프로퍼티로 꺼내올겁니다.

DB 에는 사용자계정과 해당 EML 파일명(PATH도 저장될수도)이 기록될 것이고...꺼내온 제목, 본문, 첨부파일 등의 정보가 저장되겠죠.

여기에 문제가 발생할 소지가 있습니다.
EML 파일이든 첨부파일이든...저장된 곳의 폴더에 들어있는 파일갯수입니다. (폴더 갯수 포함입니다)
1000개 넘어가면 느려지기 시작합니다.
2000개쯤 되면 완전 느립니다.
더 넘어가면 폴더에서 파일 못 읽어올 수도 있습니다.
이건...파일시스템의 구조 및 특성상 그러하기 때문에...도리가 없습니다.
그래서 폴더당 파일 갯수가 일정갯수 이상 증가하지 못하게 하기 위해...해슁해서 폴더를 나누어 저장하는 기법들을 씁니다.
NMAIL 쪽보다는 그룹웨어쪽이 좀 더 걱정이 되는군요.

만일 이러한 문제를 안고있다면...서버만 업그레이드한다고 해결되지 않습니다.
프로그램을 수정하든 해서...해결방안을 찾아야할겁니다.

zepinos김종화 2014-12

eml 파일을 가져와서 그룹웨어 DB 에 녹아들게 한 다음 다음부턴 그 메일은 그룹웨어 DB 에서만 읽어오고, 새로운 eml 파일이 있는지만 확인한다...가 맞나요?

먼저 그룹웨어 프로그램이 pop3 로 가져온 뒤 nmail 에서 eml 파일을 지우는지 확인해보세요.

그리고, 위의 DB 로 녹이는 작업은 이미 nmail 에서 다 처리해놓고 첨부파일도 eml 에서 분리해서 별도로 가지고 있습니다. nmail 에서 제공되는 웹메일이 친절하게 다 해놓은 작업인데...두 번 작업하는 거네요.

기존 그룹웨어의 DB 을 뒤지는걸 nmail 이 바라보는 DB 을 뒤지도록 변경하는게 빠를 겁니다.

여담이지만 리눅스 버전의 nmail php 가 더 성능은 좋습니다.



그리고 eml 파일을 지우고 그룹웨어 DB 에서만 예전 메일을 불러온다면...DB 쿼리에 문제가 있을 수도 있습니다.

컨설팅 한 번 받아보세요.

엠브리오 2014-12

NMAIL 데모 페이지에 들어가 봤습니다.

전형적인 그룹웨어 형식이네요.
이미 사용자가 수백명이나 되므로, 이걸 한번 사용하기 시작하면 나중에 다른걸로 바꾸기가 쉽지 않습니다.

그냥 성능좋은 서버로 교체하고, 튜닝은 개발사에 유료 기술지원 요청하심이 ..

신성공 2014-12

답변감사합니다.

서버를 분리하는것이 답이겟죠? 애플리케이션 서버와, DB서버....  고맙습니다.

SEITIES강승… 2014-12

그게 맞는 방향있수도 있네요...

잘 돌아가고 있는거 그냥 그대로 놔두는것이...

천외천oo노… 2014-12

여기도 문제의 소지가 있습니다.
그룹웨어 웹서버와 NMAIL 서버가 분리되어야하는데..
위에서 언급한데로...EML 파일을 땡겨와서 해석하는 경우라면...

첫번째로...EML 파일을 해석해주는 컴포넌트가 네트웍 공유된 EML 파일의 경로를 주었을때 파일을 열 수 있느냐...하는 문제가 있습니다. 물론...정석적인 방법으로 UNC 를 지원하고 API 를 정석적으로 호출해서 열도록 코딩했다면 문제가 없으나...귀찮다고 로컬파일만 열도록 코딩했다면 EML 파일을 못 읽어올 수 있습니다.

두번째로...NAMIL 서버가 윈도우 2000 이라고 했는데...EML 파일을 공유하기 위해 폴더 공유를 열 경우...24X7 환경으로 폴더 공유 사용하다보면...분명히 공유폴더에 접근하지 못하는 문제가 생깁니다.
2003 서버까지는 이러한 문제가 있었습니다. 2008 에서는 이런 형태로 운영해보지 않아 모르겠네요.
결국 2012 정도로 업그레이드하는 것이 좋습니다. (업그레이드 한다고 문제가 없을거라는 장담은 못 합니다)

만일 위의 댓글처럼 EML 파일을 직접 해석하는 경우이고...네트웍 공유된 EML 파일을 못 읽어온다고 하면...
해결책은 프로그램을 뜯어고치는 겁니다.
잘못 만든 프로그램은 아무리 좋은 장비를 갖다줘본들...제대로 동작하지 않습니다.

천외천oo노… 2014-12

제가 댓글을 대충 읽었군요.
지금도 NAMIL 과 그룹웨어는 분리되어있군요.
그럼 네트웍으로 접근하는 문제는 없나보군요. (신기하네요. 분명 한번씩 껐다켰다 해야할텐데. 하하~ 그룹웨어가 2012 라 괜찮은 걸 수도 있긴 하겠습니다.)

앞서 단 댓글처럼 폴더당 파일갯수 먼저 확인해보세요.
1000개 넘어간다면 장비 바꿔도 해결 안됩니다.

구리구리 2014-12

그냥 예전 생각이 나서. 잠시 적어 봅니다.
모 업체에서 상주로 근무 하였고요. 규모가 얼추 비슷한거 같네요.
사용자 들의 성향은 주로 outlook 사용자 였고 그룹웨어와 메일 서버가 동일한 서버였습니다.
outlook 사용자들의 무자비 메일로 그룹웨어 서비스 까지 영향을 받는 상황이었고요.
장애가 발생하면 보통 한사용자가 혹은 소수가 보낸 대량의 메일(특히 첨부파일이 묻은....) 인 경우가 대부분 이었습니다.
장애 리포팅을 작성하고 공지를 띠우죠. '당신은 단순히 한통의 메일을 보내는 거지만 첨부파일까지 추가된 대량 메일은 엄청나게 많은 데이타를 보내야 한다.' 이런 형식의 메일 사내 배보 메일은 링크를 이용한 방식으로 유도했습니다.

메일이랑 그룹웨어가 합쳐진 서비스라 분리가 사실 힘들었구요.
나중엔 발송 메일서버만 분리해 볼까라는 생각도 했지만. 투자문제로 거절 됐구요.

그래도 스팸처리 장비가 메일서버 앞단에서 꽤 도움이 되었습니다. 메일 필터링 및 로깅외에 몇몇 기능을 대신하기도 합니다. 특히 메일 서버가 다운될때 도움을 받기도 했구요.

여담이지만...테스트 삼아 개인적으로 구축해본 메일서버의 경우 sendmail 보다는 qmail 이 성능면에서는 괜찮은듯 했습니다.

향촌 2014-12

PHP 작업이 가능 하시면 Nmail PHP 제품으로 변경하시면 문제가 해결될것 같습니다.
메일서버는 기존 그룹웨어 서버와 분리하시구요.
제작사에 Nmail 3.8 데이타를 PHP 제품으로 이전 요청하시고 그룹웨어와 메일의 SSO 연동 요청을 하셔서
사용하시면 될것 같네요.
PHP 제품은 윈도서버와 리눅스 양쪽모두 지원되니 원하시는 O/S를 골라 사용하시면 좋을것 같습니다.

꼬랑지) 여담이지만 메일서버는 실시간 작은 파일을 수없이 처리합니다.
  첨부파일이 붙지 않은 메일은 보통 몇KB 정도의 사이즈 이구요. 이런 파일이 수없이 생성,삭제, 저장을 반복
  하다 보니 CPU 성능 보다는 디스크 I/O 가 더욱 중요합니다.
 리눅스의 qmail도 동일한 처리방식입니다.
 좋은 방벙을 찾아 원활하게 처리되길 바랍니다.

stone92 2014-12

기술적인 이야기들이 많이 나오는군요
nmail 자체가 모든 메일 메시지를 디비에 저장하는 방식이므로
그룹웨어에서는 nmail 의 디비에서 메일 메시지를 읽어와서 처리하는게 맞을듯 합니다.
굳이 디비에 저장된 메시지를  pop3를 통해서 읽어와서 동일한 처리를 할 필요는 없지요.

정책적인 이야기를 하자면 메일 메시지는 무한하게 저장하지 않는게 원칙입니다.
일정 시간이 지난 메일은 사용자들이 관리를 하게 하는것이 맞습니다.
무한정 늘어나는 데이터와 백업비용을 생각한다면 무조건 정리하게 하는것이 맞을듯 합니다.
꼭 필요하다고 저장한다고는 하지만 실제로 보는 일은 거의 없다에 한표 던져봅니다.