Chúng báo lỗi như thế nào bạn ?
Lỗi Delivery error và mail được gửi trả trở lại bởi mail exchange, hay mail gửi đi và một đi không trở lại, im hơi lặng tiếng luôn. 

Theo em nghĩ là do Mail anh ah.
Nếu đã gửi được cho những công ty khác thì network và DNS theo em là ổn.
Anh thử kiểm tra lại Exchange xem. 

Hi Thangdiblo,

- Dữ kiện lão đưa ra sao thiếu nhiều quá ! xin thảo luận vài vấn đề cần làm rõ.
1. Lão có theo dõi khi môt mail đươc gửi đi/ nhận về không ?
2. Công ty lão, công ty đối tác lọc mail spam như thề nào ?

Theo dabu nghĩ muốn chứng minh công ty lão không bị vấn đề gì thì nghĩ nên tạo một lab như công ty đối tác lão và kiểm tra thử thế nào ?
 

gửi tới nhau xác xuất nhận chỉ vào khoảng 30% 

Giữa công ty tôi email dạng @aaa.com ( tạm gọi công ty A ) và công ty đối tác email dạng @bbb.com ( tạm gọi công ty B ) gửi tới nhau xác xuất nhận chỉ vào khoảng 30% 

công ty tôi và các công ty khác gửi nhận bình thường. Công ty B gửi nhận với các đối tác khác bình thường 

gửi tới nhau xác xuất nhận chỉ vào khoảng 30% 

Vậy vấn đề là 70% đám mail còn lại vướng ở đâu đó, lão thử post 1 cái header của 1 email được gửi từ B sang A xem, ở đây nếu có network problem thì có thể là do delay ở đâu đó.
Ngoài ra trên exchange lão thử enable relay cho 1 host trong A network. Rồi từ host đó telnet đến 1 of exchange server port 25, rồi thử gửi 1 mail đến B thông qua telnet emulator này, dùng SMTP commands.



 

Microsoft Mail Internet Headers Version 2.0
Received: from ares.bbb.com ([x.x.149.4]) by dns2.aaa.com with Microsoft SMTPSVC(6.0.3790.3959);
Sat, 18 Oct 2008 13:59:49 +0700
Received: from node1.bbb.com ([x.x.149.3])
by ares.bbb.com (Lotus Domino Release 7.0)
with ESMTP id 2008101814045344-13632 ;
Sat, 18 Oct 2008 14:04:53 +0700
Subject: Re: Finish Network for test Direct connection with xxx
From: Suntiviriyanon <Thananit_Sun@bbb.com>
To: thang.nn@aaa.com
Cc: S Thangjitwattana <phop_Tha@bbb.com>,
nghia.nt@aaa.com,
"IT" <it@aaa.com>,
Charoenporn <Cha@bbb.com>,
Tran Thi Thanh <T_Ttt@bbb.com>,
MyLinh LeThi <Mylinh_Le@bbb.com>,

Pawinee Tanyapanyachon <Pawinee_Tan@bbb.com>
Date: Sat, 18 Oct 2008 14:02:24 +0700
Message-ID: <OF6BA027FD.5316B7E4-ON472574E6.0026AC2B-472574E6.0026AC3B@bbb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
Return-Path: Thananit_Sun@bbb.com
X-OriginalArrivalTime: 18 Oct 2008 06:59:49.0732 (UTC) FILETIME=[1CEC1240:01C930EF]


================================================================================================== 

Từ <QUOTE>Giữa công ty tôi email dạng @aaa.com ( tạm gọi công ty A ) và công ty đối tác email dạng @bbb.com ( tạm gọi công ty B ) gửi tới nhau xác xuất nhận chỉ vào khoảng 30%. </QUOTE>
Và
<QUOTE>công ty tôi và các công ty khác gửi nhận bình thường. Công ty B gửi nhận với các đối tác khác bình thường</QUOTE>
Theo mình đoán thì có thể là vấn đề ở phần lọc Mail của đối tác ,nó "nuốt" mất 70% kia rồi.
Bạn thử kiểm tra xem liệu các công ty khác gửi đến họ có bị tình trạng thế không ?
 

Chào anh em,
...

Có 1 vài thông tin để anh em tham khảo. Mail Server bên tôi chạy 03 con. 1 là Master 2 là Member cluster với nhau.

 

thangdiablo wrote:

Chào anh em,
...

Có 1 vài thông tin để anh em tham khảo. Mail Server bên tôi chạy 03 con. 1 là Master 2 là Member cluster với nhau.

 

Điểm đáng xét là ở phần màu đỏ.

Cluster thế nào? Thông tin từ ngoài vào đến SMTP servers như thế nào?

Cung cấp thêm mô hình mạng từ ngoài vào trong và cấu trúc cluster thì mới có thể xét được. 

conmale wrote:

thangdiablo wrote:

Chào anh em,
...

Có 1 vài thông tin để anh em tham khảo. Mail Server bên tôi chạy 03 con. 1 là Master 2 là Member cluster với nhau.

 

Điểm đáng xét là ở phần màu đỏ.

Cluster thế nào? Thông tin từ ngoài vào đến SMTP servers như thế nào?

Cung cấp thêm mô hình mạng từ ngoài vào trong và cấu trúc cluster thì mới có thể xét được. 

Em xin cung cấp thêm thông tin để anh em nắm rõ.

Mail Server của công ty tôi có 3 con. 1 back end nằm trong core và 2 font end nằm phía ngoài.

Giữa back end và font end có 1 firewall.

Trên Exchange tôi có tạo 2 connector.

Connector thứ nhất là để hướng email từ công ty ra bên ngoài Internet và từ Internet vào trong.

Tạm gọi Connector này là AAA-Internet . Tại đây những email gửi ra ngoài ( bên ngoài domain @aaa.com ) sẽ được chuyển tới backend và sử dụng DNS để route đi.

IP WAN cho Mail Server được trỏ thẳng vào con backend này.

Connector thứ hai là để luân chuyển mail trong nội bộ, giữa các chi nhánh ( những email có dạng @aaa.com )

Tạm gọi Connector này là AAA-Intranet

Khi user1@aaa.com gửi tới user2@aaa.com thì thay vì dùng backend để đẩy mail đi thì nó sẽ hướng những email này tới 2 con font end nhằm giảm tải cho backend.

 

Giữa công ty tôi email dạng @aaa.com ( tạm gọi công ty A ) và công ty đối tác email dạng @bbb.com ( tạm gọi công ty B ) gửi tới nhau xác xuất nhận chỉ vào khoảng 30%.
 

Công ty tôi đang sử dụng 03 mail exchange 2003 SP2.
Mail Server bên tôi chạy 03 con. 1 là Master 2 là Member cluster với nhau.
Mail Server của công ty tôi có 3 con. 1 back end nằm trong core và 2 font end nằm phía ngoài.
Giữa back end và font end có 1 firewall
Tại đây những email gửi ra ngoài ( bên ngoài domain @aaa.com ) sẽ được chuyển tới backend và sử dụng DNS để route đi.
IP WAN cho Mail Server được trỏ thẳng vào con backend này.
 

Công ty đối tác của tôi dùng email Lotus của IBM.
 

---> kiểm tra cái này xem nó có drop cái gì đó không đúng hay không.

---> route thế nào ở đây?

---> xét lại rule mail được đẩy ở đây có đúng không.

---> xét lại rule mail được đẩy ở đây có đúng không. 

Đang ngủ trưa có thằng cu em cứ gọi ý ới rồi vứt cho cái Link hỏi han linh tinh, đành vào ngó nghiêng xem có anh sẽ gì không, ai ngờ lại là cái này. Ghét nó quá đi, đã trót vào ngó nghiêng vậy.  

Hi Thắng, để anh túm lại cho chú các thông tin xem có đúng ý chú không nhé


Giữa công ty tôi email dạng @aaa.com ( tạm gọi công ty A ) và công ty đối tác email dạng @bbb.com ( tạm gọi công ty B ) gửi tới nhau xác xuất nhận chỉ vào khoảng 30%.



Cảm nhận , hay dùng công cụ gì mà đo được để biết là 30? ( Cái này cũng không quan trọng lắm, hỏi chơi thôi )  

Ở đây có mấy cái nhầm lẫn mà anh tô đỏ ( có lẽ Thắng vội quá nên nhầm smilie ). Hoặc nếu không thì việc thiết lập hệ thống có mistake.
Trong hệ thống Exchange các con FE sẽ chịu trách nhiệm giơ mặt lên Net và nó sẽ là thằng chuyển mail đi. =>
Chính vì thế nên để đảm bảo hệ thống High Avail người ta có thể dùng 2 con FE, ngoài ra còn có tác dụng share tải nữa ( LB ). Để làm LB người ta có thể dùng ngay cơ chế round robin trong Windows, khai các bản ghi mx có độ ưu tiên bằng nhau hay khác nhau ( MX preference ), hoặc dùng các thiết bị phần cứng làm nhiệm vụ Load Balancing ( F5.com)
=> IP WAN sẽ được gán cho các con FE hoặc thiết bị share tải ...  

Nguyên tắc hoạt động của mail trong một hệ thống Mail Exchange giữa những con FE và BE là có thể sử dụng routing group hoặc smart host. Không biết hệ thống của Thắng sử dụng cơ chế nào để chuyển mail giữa các con này. ( Đó là một vấn đề cần quan tâm nếu hệ thống lớn, phân tán .... )  

Cái này thực ra cũng sẽ không cần quan tâm nhiều lắm chỉ cần quan tâm đến hệ thống chặn spam ( nếu có ) trên hệ thống của đối tác. Thông thường một cách chống spam người ta hay sử dụng một cách khá đơn giản nhưng hiệu quả là thiết lập việc query ngược lại bản ghi mx của một tên miền để kiểm tra xem tên miền có thật không, IP tĩnh hay IP động, nếu chưa khai bản ghi mx thì có thể sẽ bi reject ngay từ câu lệnh helo.
Nếu đúng như những gì Thắng nói thì có thể là hệ thống đã bị thiết lập sai và khi mail đi từ con BE thẳng ra có thể không biết cách đi ra => luẩn quẩn trong hệ thống.  

=> Yêu cầu đối tác đưa tên miền của mình vào Whitelist, đồng thời đưa tên miền của đối tác vào danh sách Whitelist của hệ thống mình.  

Nguyên tắc bảo mật sẽ không bao giờ cho nối thẳng từ ngoài vào Core như thế, FE phải đặt ở DMZ, giữa FE và BE đã có FW rồi thì cũng cần quan tâm đến việc mở port nào vì khi cần xác thực User nó sẽ phải nối vào AD sử dụng thêm một số thứ nhằm xác định đúng U/p.  

@thangdiablo: bên A gửi cho B cũng bị mất mail và ngược lại, bên B gửi cho A cũng bị như thế luôn? Hay là chỉ bị một chiều thôi?

--m 

Hôm nay có 1 thông báo từ phía đối tác và user của bên em " Trong vòng 3 ngày qua mail chạy êm, không còn tình trạng lúc được lúc không". Họ cũng xác định là chưa hề chỉnh sửa gì bên họ, và bên em cũng vậy. Thông tin này làm em hơi thất vọng nhưng vẫn muốn tìm ra nguyên nhân triệt để của vấn đề. 

E:\Documents and Settings\Administrator\Desktop\SmtpDiag>SMTPDIAG "thang.nn@aaa.com" "Somphop_Tha@bbb.com" -d 10.128.28.2 /v

Searching for Exchange external DNS settings.
Computer name is THANGNGUYEN.
Failed to connect to the domain controller. Error: 8007054b

Checking SOA for bbb.com.
Checking external DNS servers.
Checking internal DNS servers.

Checking TCP/UDP SOA serial number using DNS server [10.128.28.2].
TCP test succeeded.
UDP test succeeded.
Serial number: 2007110219

Checking TCP/UDP SOA serial number using DNS server [10.128.28.3].
TCP test succeeded.
UDP test succeeded.
Serial number: 2007110219

Checking TCP/UDP SOA serial number using DNS server [210.245.24.22].
TCP test failed.
[/color]UDP test succeeded.
Serial number: 2007110219

Checking TCP/UDP SOA serial number using DNS server [210.245.24.x].
TCP test failed.
UDP test succeeded.
Serial number: 2007110219
SOA serial number match: Passed.

Checking local domain records.
Starting TCP and UDP DNS queries for the local domain. This test will try to
validate that DNS is set up correctly for inbound mail. This test can fail for
3 reasons.
1) Local domain is not set up in DNS. Inbound mail cannot be routed to
local mailboxes.
2) Firewall blocks TCP/UDP DNS queries. This will not affect inbound mail,
but will affect outbound mail.
3) Internal DNS is unaware of external DNS settings. This is a valid
configuration for certain topologies.
Checking MX records using TCP: aaa.com.
MX: cktcm.aaa.com (10)
A: cktcm.aaa.com [10.128.28.3]
Checking MX records using UDP: aaa.com.
MX: cktcm.aaa.com (10)
A: cktcm.aaa.com [10.128.28.3]
Both TCP and UDP queries succeeded. Local DNS test passed.

Checking remote domain records.
Starting TCP and UDP DNS queries for the remote domain. This test will try to
validate that DNS is set up correctly for outbound mail. This test can fail for
3 reasons.
1) Firewall blocks TCP/UDP queries which will block outbound mail. Windows
2000/NT Server requires TCP DNS queries. Windows Server 2003 will use UDP
queries first, then fall back to TCP queries.
2) Internal DNS does not know how to query external domains. You must
either use an external DNS server or configure DNS server to query external
domains.
3) Remote domain does not exist. Failure is expected.
Checking MX records using TCP: bbb.com.
MX: mailscan.bbb.com (1)
MX: ares.bbb.com (5)
A: mailscan.bbb.com [61.90.149.1x]
A: ares.bbb.com [61.90.149.x]
Checking MX records using UDP: bbb.com.
MX: mailscan.bbb.com (1)
MX: ares.bbb.com (5)
Both TCP and UDP queries succeeded. Remote DNS test passed.

Checking MX servers listed for Somphop_Tha@bbb.com.
Connecting to mailscan.bbb.com [61.90.149.x] on port 25.
Received:
220 mailaudit Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu
, 13 Nov 2008 00:24:52 +0700


Sent:
ehlo aaa.com

Received:
250-mailaudit Hello [58.186.164.x]
250-TURN
250-SIZE 15728640
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK


Sent:
mail from: <thang.nn@aaa.com>

Received:
250 2.1.0 thang.nn@aaa.com....Sender OK

Sent:
rcpt to: <Somphop_Tha@bbb.com>

Received:
250 2.1.5 Somphop_Tha@bbb.com

Sent:
quit

Received:
221 2.0.0 mailaudit Service closing transmission channel

Successfully connected to mailscan.bbb.com.
Connecting to ares.bbb.com [61.90.149.x] on port 25.
Connecting to the server failed. Error: 10060
Failed to submit mail to ares.bbb.com.