Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the process of mta relay server in Smtp protocol". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how the process of mta relay server in Smtp protocol is.

Once the SMTP client lexically identifies the domain in which the message will be delivered for processing, it must perform a DNS lookup to resolve the domain name. These names should be fully qualified domain names (FQDN): the mechanism to infer FQDN from partial names or local aliases is not covered by this specification. Due to the history of the problem, the SMTP server used to initially submit the message should not make such reasoning (the message submission server [18] is more flexible), while the intermediate (relay) SMTP server cannot do so.

Lookup first attempts to find the MX record associated with that name. If a CNAME record is found, the result name is processed to the initial name. If you return a domain error that does not exist, you must report this condition as an error. If a temporary error is returned, the message must be queued and retried later (see Section 4.5.4.1). If an empty MX list is returned, the address is considered to be associated with an implicit MX RR with a priority of 0, pointing to the host. If MX records exist, but none of them are available, or if the implicit MX is not available, you must report this condition as an error.

If you find one or more MX RR,SMTP systems for a given name, you must not use any address RR associated with that name unless they use MX RR positioning; the "implicit MX" rule above applies only if there is no MX record. If MX records exist, but none of them are available, you must report this condition as an error.

When looking up the domain name associated with the MXRR and getting the associated data field, the data field of the response must contain the domain name. The domain name must return at least one address record (for example, An or AAAA RR) when queried, which gives the IP address of the SMTP server to which the message should point. Any other response, including in particular the value that will be returned by the CNAME record when queried, is outside the scope of this standard. Section 10.3 [38] of RFC 2181 discusses in detail the prohibition of the use of tags in data parsed to CNAME.

When the lookup is successful, because there are multiple MX records, multiple attributions, or both, the mapping may result in an alternative delivery address list rather than a single address. To provide reliable mail delivery, the SMTP client must be able to sequentially try (and retry) each relevant address in the list until the delivery is successful. However, the number of alternate addresses that can be tried may also be a configurable limit. In any case, the SMTP client should try at least two addresses.

Two types of information are used to arrange host addresses: multiple MX records and multihomed hosts.

MX records contain a preference indication that if more than one such record occurs, it must be used for sorting (see below). Lower numbers are more preferred than higher numbers. If multiple destinations have the same preference and there is no clear reason to support one destination (for example, by identifying easily reachable addresses), the sender SMTP must randomize them to spread the load across multiple mail switches for a particular organization.

The target host (which may be from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternate IP addresses. The responsibility of the domain name parser interface is to sort the list by reducing preferences if necessary, and the SMTP sender must try them in the order in which they are rendered.

Although you need to try the function of multiple alternative addresses, the specific installation may need to restrict or prohibit the use of alternative addresses. There has been controversy over whether the sender should try to retry using a different address of the multihomed host. The main reason for using multiple addresses is that it maximizes the possibility of timely delivery and may even sometimes achieve delivery; the rebuttal is that it can lead to unnecessary use of resources. Note that the use of resources is also strongly determined by the delivery strategy discussed in section 4.5.4.1.

If the SMTP server specifies the destination of the mail exchanger when it receives the message, it may relay the message (perhaps after rewriting the mail sending address and / or RCPT address), eventually delivering the message or delivering the message using some mechanism outside the transport environment provided by SMTP. Of course, none of the latter needs to further check the list of MX records.

If it determines that it should relay messages without rewriting the address, it must sort the MX records to determine delivery candidates. The records are first arranged in order of priority, and the lowest numbered records are the most preferred. The relay host must check the list for names or addresses that may be known in any mail transactions. If matching records are found, all records and higher numbered records at that preferred level must be discarded from consideration. If it is not recorded at this time, it is an error condition, and the message must be returned in a manner that cannot be delivered. If the records remain the same, you should try them as described above, preferably first.

At present, most mail encryption products in the market need to re-register a mailbox or redeploy a mail system, resulting in the original mailbox can not be used, that is to say, users need to change their habits. It is difficult for large companies to upgrade their mail systems.

It is a good choice to choose email encryption products that are transparent to users. For example, the secret mail launched by Tianyu Yunan ensures that the email content is encrypted, and the deployment is also transparent to users, which can be said to be very user-friendly.

Thank you for your reading. the above is the content of "how is the process of mta relay server in Smtp protocol". After the study of this article, I believe you have a deeper understanding of the process of mta relay server in Smtp protocol, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.