rfc-1846 & reply code-521

2
SMTP 521 Reply Code Network Working Group Request For Comments: 1846 Category: Experimental Authors: A. Durant, F. Dupont Year: September 1995 Link: https://tools.ietf.org/html/rfc1846 This rfc[1] is based on the Simple Mail Transfer Protocol (SMTP)[2]. It defines a new reply code-‘521’[3] and it will be used to indicate that the internet host does not accept incoming mails. Problem: Today, the hosts on the internet are more distributed, smaller in size and more specialized in tasks than ever before. Hence, some hosts do not provide mail service as they don’t run SMTP server. Thus, when mails are diverted to such servers then they remain there for certain days waiting for SMTP servers to start, in the lack of it they are returned back with an unclear error message. Solutions: There are two possible solutions 1. Usages of MX (mail exchanger)[4] relay to return back mail destined to SMTP-less host along with 521 reply code. MX relay of all the priorities should work similarly as mentioned above. 2. Run a minimal SMTP server to return back all the mails. This method contains of certain steps: Step 1: Send the 521 reply code along with the computers IP address to the sender (incoming SMTP Connection). Step 2: Close the SMTP connection or wait for 5 minutes for Client to issue Quit command and then close. On receiving the 521 reply code the Client must understand that it is not any transient error and for the same not to re- queue the mail for later delivery to same system and there is no need of postmaster[5] requirement. As postmaster are required to process and handle emails with error, whereas 521 reply code suggests hosts inability in accepting mails, which is not an error. On receiving the 521 reply code, client should either try resending the mail to alternate MX host or return the mail along with the reason of delivery failure.

Upload: pandyakavi

Post on 11-Sep-2015

2 views

Category:

Documents


0 download

DESCRIPTION

This rfc-1846 is based on the Simple Mail Transfer Protocol (SMTP). It defines a new reply code-‘521’ and it will be used to indicate that the internet host does not accept incoming mails.

TRANSCRIPT

SMTP 521 Reply CodeNetwork Working GroupRequest For Comments: 1846Category: ExperimentalAuthors: A. Durant, F. DupontYear: September 1995Link: https://tools.ietf.org/html/rfc1846

This rfc[1] is based on the Simple Mail Transfer Protocol (SMTP)[2]. It defines a new reply code-521[3] and it will be used to indicate that the internet host does not accept incoming mails.

Problem:Today, the hosts on the internet are more distributed, smaller in size and more specialized in tasks than ever before. Hence, some hosts do not provide mail service as they dont run SMTP server. Thus, when mails are diverted to such servers then they remain there for certain days waiting for SMTP servers to start, in the lack of it they are returned back with an unclear error message.

Solutions:There are two possible solutions1. Usages of MX (mail exchanger)[4] relay to return back mail destined to SMTP-less host along with 521 reply code. MX relay of all the priorities should work similarly as mentioned above. 2. Run a minimal SMTP server to return back all the mails. This method contains of certain steps:Step 1: Send the 521 reply code along with the computers IP address to the sender (incoming SMTP Connection).Step 2: Close the SMTP connection or wait for 5 minutes for Client to issue Quit command and then close.

On receiving the 521 reply code the Client must understand that it is not any transient error and for the same not to re-queue the mail for later delivery to same system and there is no need of postmaster[5] requirement. As postmaster are required to process and handle emails with error, whereas 521 reply code suggests hosts inability in accepting mails, which is not an error.

On receiving the 521 reply code, client should either try resending the mail to alternate MX host or return the mail along with the reason of delivery failure.

Conclusion:Thus, 521 reply code helps in distinguishing mails that face error in getting delivered from the one that are being delivered to host which does not accept incoming mails. This differentiation enables Client to take decision accordingly and treat both the cases accordingly/differently rather than treating them alike which does not solve the purpose and results in delayed and inaccurate delivery.

For understanding the above concepts the below links were visited:[1]. https://www.ietf.org/rfc.html[2]. https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol[3]. http://www.greenend.org.uk/rjk/tech/smtpreplies.html[4]. http://www.crucial.com.au/blog/2012/09/17/undestanding-mx-records-mail-relayauthentication-and-open-relay/[5]. https://en.wikipedia.org/wiki/Postmaster_(computing)