Re: Queued Mail or Unreturnable Mail?

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.
-Doug