Tìm hiểu cách DSN nhằm giới thiệu trạng thái gửi tới email SMTP.
Bao giờ tự hỏi điều gì đã xảy ra với một email bạn gửi?
Thậm chí chỉ cần một cái nhìn ngắn gọn về giao thức SMTP, bạn sẽ thấy rằng bên cạnh HELO thông thường, cũng có EHLO, mà làm cho máy chủ SMTP mở rộng quảng cáo các khả năng của nó vượt quá tiêu chuẩn ban đầu. Một trong số đó là DSN. DSN? DNA và DDT có đủ không?
Để tranh luận rằng email là không đáng tin cậy, rằng ai đó nên " ... ăn máy chủ của họ tốt hơn, nó ăn thư của tôi ... " không phải là không phổ biến. Tôi tự làm nó. Tuy nhiên, không có nhiều lý do để hỗ trợ những nghi ngờ này.
Giao hàng S tatus N otification đã được khoảng từ RFC 821 (từ năm 1982). Ngay khi phần DATA của giao thức SMTP được hoàn tất và máy chủ đã chấp nhận email để gửi, nó chịu trách nhiệm cho nó. Nếu vì bất kỳ lý do gì, nó không thể chuyển nó đến người nhận, nó phải gửi lại thông báo lỗi cho người gửi ban đầu. Điều này dẫn đến một số email tối nghĩa.
Ngoài ra, quy ước cũ này có nghĩa là bạn có một thông báo lỗi hoặc bạn không có gì trong trường hợp bạn không biết gì cả : email có thể đã đến hoặc có thể không. Các thông báo lỗi trong nhiều trường hợp cũng hữu ích như không có thông báo lỗi. Với email ngày càng trở nên quan trọng, điều này không còn thỏa đáng nữa (như thể trước đây).
Tiện ích mở rộng DSN cho SMTP
RFC 1891 đề xuất một số phần mở rộng cho giao thức SMTP sẽ dẫn đến một hệ thống DSN đáng tin cậy hơn và dễ sử dụng hơn. Nó là một tập hợp các phần mở rộng cho các lệnh MAIL và RCPT (nếu điều này có nghĩa là không có gì cho bạn, hãy đọc cách SMTP hoạt động và sau đó trở lại đây.).
Không có EHLO, Không vui
Đầu tiên, chúng ta phải đảm bảo rằng máy chủ hỗ trợ DSN. Vì vậy, chúng ta phải nói EHLO với anh ta và lắng nghe cẩn thận. Nếu nó đáp ứng với DSN một cách nào đó trong danh sách tính năng, chúng tôi có thể giả định rằng nó sẽ có thể phục vụ các yêu cầu của chúng tôi. Nếu không, thì không: chúng tôi có thể thử một máy chủ khác hoặc đơn giản là quay lại email mà không cần DSN. Ví dụ (đầu vào của tôi là màu xanh, đầu ra của máy chủ màu đen):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Chủ nhật, ngày 24 tháng 8 năm 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Xin chào localhost [127.0.0.1], rất vui được gặp bạn
250 EXPN
250 ĐỘNG TỪ
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
May mắn thay, trong số những thứ khác, chúng tôi tìm thấy DSN.
Tiện ích người gửi DSN
Lệnh tiếp theo thường là MAIL FROM :. Với DSN, điều này không khác gì. Nhưng có hai tùy chọn bổ sung mà bạn có thể phát hành: RET và ENVID.
Tùy chọn RET được đặt tùy ý trong lệnh MAIL, nhưng nó phù hợp ở đây cũng như nó sẽ ở bất cứ nơi nào khác. Mục đích là để xác định bao nhiêu tin nhắn ban đầu của bạn sẽ được trả lại trong trường hợp không gửi được. Đối số hợp lệ là FULL và HDRS. Trước đây có nghĩa là thông báo đầy đủ nên được bao gồm trong thông báo lỗi, HDRS hướng dẫn máy chủ chỉ trả về các tiêu đề của thư thất bại. Nếu RET không được chỉ định, thì tùy thuộc vào máy chủ phải làm gì. Trong hầu hết các trường hợp, HDRS sẽ là giá trị mặc định.
ENVID thực sự thuộc về người gửi vì cô ấy hoặc (chứ không phải) ứng dụng email khách của cô ấy sẽ là người duy nhất làm cho chúng tôi nhận dạng phong bì này. Mục đích của nó là để cho người gửi biết email có thể là một thông báo lỗi có thể tương ứng với. Định dạng của ID này về cơ bản là trái với trí tưởng tượng của người gửi. Chúng tôi sẽ không sử dụng ENVID trong ví dụ của chúng tôi (trí tưởng tượng!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Người gửi ok
Rõ ràng, chúng tôi chỉ muốn lấy lại các tiêu đề trong DSN của mình.
Tiện ích người nhận DSN
RCPT TO: nhận được phần mở rộng công bằng của các tiện ích mở rộng: NOTIFY và ORCPT.
NOTIFY là trái tim thực sự của DSN. Nó cho máy chủ biết khi nào gửi thông báo trạng thái gửi. Giá trị đầu tiên có thể là KHÔNG BAO GIỜ có nghĩa là trong mọi trường hợp, DSN phải được trả lại cho người gửi. Điều này là không thể nếu không có DSN. Sau đó, có THÀNH CÔNG, sẽ thông báo cho bạn khi thư của bạn bị chặn tại điểm đến của nó. FAILURE là đối tác của SUCCESS (!): Một DSN sẽ đến nếu một arror xảy ra trong quá trình giao hàng. Tùy chọn cuối cùng là DELAY: bạn sẽ được thông báo nếu có sự chậm trễ bất thường trong phân phối, nhưng kết quả giao hàng thực tế (thành công hay thất bại) vẫn chưa được quyết định. KHÔNG BAO GIỜ phải là đối số duy nhất nếu nó được chỉ định, ba đối số khác có thể xuất hiện trong một danh sách, được phân tách bằng dấu phẩy. THÀNH CÔNG và FAILURE tạo nên một đội khá mạnh với nhau (!), Cho bạn biết (gần như) mọi trường hợp xảy ra với thư của bạn.
Mục đích của ORCPT là để quản lý người nhận ban đầu của một email, ví dụ nếu nó được chuyển tiếp đến một địa chỉ khác. Đối số cho tùy chọn này là địa chỉ email của người nhận ban đầu cùng với loại địa chỉ. Loại địa chỉ xuất hiện trước, sau đó là dấu chấm phẩy và cuối cùng là địa chỉ. Ví dụ:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Người nhận ok (sẽ xếp hàng)
Tiếp theo là DATA như chúng ta biết và cuối cùng, hy vọng, một thông báo trạng thái gửi thông báo cho bạn về một thành công.
DSN có hoạt động không?
Tất nhiên, tất cả vẻ đẹp và trí thông minh này sẽ chỉ hoạt động nếu các tác nhân vận chuyển thư từ người gửi đến người nhận hỗ trợ DSN. Một ngày nào đó họ sẽ làm.