[Top] [All Lists]

Re: Queued Mail or Unreturnable Mail?

2008-05-02 15:49:39

On Apr 30, 2008, at 7:02 PM, Frank Ellermann wrote:

2821 and 2821bis have it clear that the mere presence of a listening process does not say anything about the intent to receive mail for the corresponding domains. The MX can say something else, without MX a listening process at A or AAAA can reject clients or individual mails as it sees fit.

The problematic situation is the absence of MX and listening process, senders are forced to wait 100 hours, somebody might find the reboot button of the affected host. Another problematic situation is mail claiming to be "from" this domain without MX, receivers cannot wait until somebody finds the reboot button for a quick plausibility test, they are forced to reject such suspicious mails temporarily.

Since DARPA's development of a "network of networks" became known as the Internet, and intercommunication processes known as Internet protocols (IP), a means to relate hostnames and services with IP addresses was needed. Jon Postel publish a concept of Sockets (combing network address and port) in use with assignments for standard programs, laying a foundation on efforts made by Steve Carr from Utah, Jeff Rulifson from SRI, and Steve Crocker of UCLA, who introduced documents describing host networking almost four decades ago.

The next decade introduced RFC761 TCP, RFC768 UDP, and RFC790 Assigned numbers. Within a few years, RFC1034 DNS supplanted host files. With DNS, in addition to port assignments, service support could be declared using specialized DNS resource records. RFC974 recommended WKS (well known service) resource records to confirm support of SMTP. RFC1123 renounced WKS, as few domains published these records. The resource record concept did not mesh with host files, or NetBIOS adaptation of WINS's offering referrals from specific service names.

To help transitioning from WINS to DNS, SRV records were created. Even with SRV records, Window's adoption of DNS remained limited. Within a Window's enterprise environment, DNS might be converted into RPC. Avoiding proprietary development for this environment, protocols often employ only the limited list of resource records having data structures defined for Windows OS APIs. While API provisions now accommodate undefined resources records, a lack of OS data structure definitions remains an impediment.

Resolving services and hostname addresses, generic resource records holding signatures and policies continues to impact SMTP. Although SMTP adopted MX resource records within DNS, publishing MX records was unfortunately never mandated. While ensuring the viability of local hostname resolution remains important, undesired traffic associated with spoofed email addresses represents an ever increasing problem. However, there does not appear to be an easy method to differentiate name services when resolving an address. Facing massive amounts of undesired traffic, SMTP reception typically employes extensive examination of SMTP client IP addresses and return-path email-addresses.

Therefore, it should be reasonable to publish an RFC that warns of possible future changes where message acceptance may require return- path email-address domains to publish MX records. Mandating MX records be published by domains supporting SMTP better protects domains not supporting SMTP, and better ensures integration of IPv6 addresses. The MX mandate also replaces unofficial recommendations that domains not supporting SMTP publish bogus MX records targeting roots. This mandate would help establish conventions for receiving SMTP servers to predicate additional transactions upon first finding MX records for associated email-address domains. The receiving SMTP server is also best equipped at making necessary exceptions where needed.

In essence, SMTP discovery resource record mandate essentially impacts message reception. Justification for this mandate could be to support the obligation accepted by receiving SMTP servers of ensuring delivery or offering notification upon a delivery failure.