Tại sao một địa chỉ MAIL trống có thể gửi email?

Chúng tôi đang sử dụng hệ thống Smarter Mail. Gần đây, chúng tôi thấy rằng hacker đã hack một số tài khoản người dùng và gửi rất nhiều thư rác. Chúng tôi có tường lửa để phê duyệt người gửi, nhưng đối với email sau, tường lửa không thể thực hiện việc này vì địa chỉ TỪ trống. Tại sao một địa chỉ TỪ trống được xem xét OK? Trên thực tế, trong MTA của chúng tôi, chúng tôi có thể thấy người gửi trong tiêu đề email. Bất kỳ ý tưởng?

11:17:06 [xx.xx.xx.xx][15459629] rsp: 220 mail30.server.com
11:17:06 [xx.xx.xx.xx][15459629] connected at 6/16/2010 11:17:06 AM
11:17:06 [xx.xx.xx.xx][15459629] cmd: EHLO ulix.geo.auth.gr
11:17:06 [xx.xx.xx.xx][15459629] rsp: 250-mail30.server.com Hello [xx.xx.xx.xx] 250-SIZE 31457280 250-AUTH LOGIN CRAM-MD5 250 OK
11:17:06 [xx.xx.xx.xx][15459629] cmd: AUTH LOGIN
11:17:06 [xx.xx.xx.xx][15459629] rsp: 334 VXNlcm5hbWU6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 334 UGFzc3dvcmQ6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 235 Authentication successful
11:17:07 [xx.xx.xx.xx][15459629] Authenticated as hackedaccount@domain1.com
11:17:07 [xx.xx.xx.xx][15459629] cmd: MAIL FROM:
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <> Sender ok
11:17:07 [xx.xx.xx.xx][15459629] cmd: RCPT TO:recipient@domain2.com
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <recipient@domain2.com> Recipient ok
11:17:08 [xx.xx.xx.xx][15459629] cmd: DATA

Các trống MAIL FROMđược sử dụng để thông báo trạng thái giao hàng. Cần có máy chủ thư để hỗ trợ nó ( RFC 1123 phần 5.2.9 ).

Nó được sử dụng chủ yếu cho các tin nhắn bị trả lại, để ngăn chặn một vòng lặp vô tận. Khi MAIL FROMđược sử dụng với một địa chỉ trống (được biểu thị dưới dạng <>), máy chủ nhận biết sẽ không tạo ra một tin nhắn bị trả lại nếu tin nhắn đang được gửi đến một người dùng không tồn tại.

Nếu không có điều này, một người nào đó có thể làm DoS bạn chỉ bằng cách giả mạo một tin nhắn cho người dùng không tồn tại ở một tên miền khác, với địa chỉ trả về của một người dùng không tồn tại trong tên miền của bạn, dẫn đến một vòng lặp không bao giờ kết thúc tin nhắn bị trả lại.

Điều gì sẽ xảy ra nếu bạn chặn tin nhắn với một sản phẩm nào MAIL FROM:?

• Người dùng của bạn sẽ không nhận được tin nhắn bị trả lại từ các tên miền khác: họ sẽ không bao giờ biết nếu họ mắc lỗi đánh máy khi gửi thư cho người dùng ở một tên miền khác.

Các MAIL FROM:tin nhắn trống mà bạn đang thấy có lẽ không đến từ một người gửi thư rác.

Thay vào đó, một người gửi thư rác đã giả mạo một địa chỉ tại tên miền của bạn và sử dụng nó làm địa chỉ trả lại cho một tin nhắn đến một tên miền khác. Hãy nói rằng bạn là yourdomain.comvà tên miền của tôi là mydomain.net. Người gửi thư rác gửi tin nhắn đến johnq@mydomain.net, giả mạo địa chỉ trả lại là johnq@yourdomain.com. Vì không có người dùng johnqtrong miền của tôi, máy chủ thư của tôi sẽ gửi một tin nhắn bị trả lại ( MAIL FROM:<>) cho người gửi rõ ràng , johnq@yourdomain.com. Đó là những gì bạn có thể đang nhìn thấy.

Theo tôi, việc chặn các MAIL FROMtin nhắn trống sẽ gây hại nhiều hơn là tốt. Những kẻ gửi thư rác, theo kinh nghiệm của tôi, hiếm khi sử dụng một sản phẩm nào MAIL FROM:vì chúng có thể dễ dàng giả mạo một địa chỉ trông giống thật. Khi thư là thư rác thực sự, có nhiều cách tốt hơn để phát hiện và chặn thư, bao gồm RBL, bộ lọc Bayes và SpamAssassin.

Và cuối cùng, bạn có thể ngăn chặn ít nhất một số giả mạo bằng yourdomain.comcách thiết lập các bản ghi SPF thích hợp cho tên miền của bạn.

Cập nhật: Sau khi xem xét kỹ hơn nhật ký của bạn, ai đó đã có thể AUTHsử dụng tên người dùng và mật khẩu hợp lệ cho máy chủ của bạn. Điều này đặt nó trong một loại rắc rối khác. Tuy nhiên, tất cả mọi thứ tôi nói về MAIL FROM:vẫn đứng. 99% thời gian sẽ là kết quả của các tin nhắn bị trả lại.

Bạn có thể tìm kiếm tùy chọn cho máy chủ thư của mình để giới hạn MAIL TỪ với e-mail người dùng được xác thực. Nhiều hệ thống thư áp dụng giới hạn đó.

Và do đó, buộc người dùng bị hack phải thay đổi mật khẩu.