[Top] [All Lists]

Re: I-D Action:draft-klensin-rfc2821bis-10.txt

2008-04-19 00:44:13

Douglas Otis wrote:

> [snip]
> The future of SMTP and IPv6 is better protected by _not_
> sanctioning AAAA as implied MX records and warning about the
> possible deprecation of A records as implied MX records.   This
> would move toward establishing the consistent treatment of A
> and AAAA records, and properly acknowledging the rising
> levels of SMTP abuse.

Hi Doug,

The way I see it, when you consider the overall desire that is being expressed, independent of what method is used to discover a host, it all boils down to a SMTP client/server session have proper transaction variables.

So the ultimate question becomes:

    Must all mail senders have a RECEIVER available "somewhere"
    in order to receive a notification?

and if we wish to extend this to 2822,

    Must all transaction expose a valid RECEIVER in the 2822
    message reply fields (Reply-To:,  From:) in order for the
    user or some mailbot to send responses?

We are really talking about an authorization concept via a new SMTP compliancy proposal.

The technical details of MX, A, AAAA, IPv4, IPv6 is meaningless. That's just the *how* in answering the above fundamental question(s).

Also, very important, it is an "authorization concept" for anonymous senders for local or hosted recipients because the way most systems behave today using traditional authorization or authentication methods, it is the when the client does not meet one or more of these criteria that any of this MX/A/AAAA issues would be important.

For our system, relay restrictions are completely bypassed when the client is authorized or authenticated using one of three methods:

  - IP allow relay tables,

It is only when it is anonymous, do any "extra" sender checking come into play and in our case, only after the recipient is acceptable. This follows the principle described in Section 3.3 of 2821 and carried over to 2821bis:

   3.3.  Mail Transactions

   ..... Despite the apparent
   scope of this requirement, there are circumstances in which the
   acceptability of the reverse-path may not be determined until one or
   more forward-paths (in RCPT commands) can be examined.

[Side Point: To me, this is one of the most important statements in SMTP. Kudos the the author of that statement. Any system that is doing return path checks at the SMTP level, will drastically improve it scalability and efficiency by following this "check recipient first, delayed return path verification" concept.]

Note, I am not questioning that an explicit MX requirement method is not a valid consideration. I am questioning to what purpose?

Just consider the many transactions with addresses such as:

   no-reply @

that many feedbacks system use today, including bad guys and the bad/good direct marketing people.

Well, an explicit MX does not resolve this problem of a response address not being reachable.

However, if it included other SMTP HOSTING requirements:

   Does it have a SERVICE PORT available?,
   Is the address acceptable at host?

then I think we would be closer to providing valid arguments behind the "WHY" we may want to even consider this idea.

I don't think I am saying anything odd here.

Much of this is all part of the basic concepts in RFC 3484 with its getaddrinfo() recommendations. In fact, RFC 3484 does not have not even one mentioning of MX records.

But check out RFC 3482, specifically section 2 and section 8.

Then also read the following:

  RFC 3901 DNS IPv6 Transport Operational Guidelines
  RFC 4038 Application Aspects of IPv6 Transition
  RFC 4472 Operational Considerations and Issues with IPv6 DNS

In 4038 section 3.2, this note covers what we been partially debating:

   3.2.  DNS Does Not Indicate Which IP Version Will Be Used

   In a node, the DNS name resolver gathers the list of destination
   addresses.  DNS queries and responses are sent by using either IPv4
   or IPv6 to carry the queries, regardless of the protocol version of
   the data records [DNSTRANS].

   The DNS name resolution issue related to application transition is
   that by only doing a DNS name lookup a client application can not be
   certain of the version of the peer application.  For example, if a
   server application does not support IPv6 yet but runs on a dual-stack
   machine for other IPv6 services, and this host is listed with an AAAA
   record in the DNS, the client application will fail to connect to the
   server application.  This is caused by a mismatch between the DNS
   query result (i.e., IPv6 addresses) and a server application version
   (i.e., IPv4).

It touches base with using not MX but SRV as a discovery method. But note again, not even one mentioning of MX records!!

But this statement is critical:

   The application should request all IP addresses without address
   family constraints and try all the records returned from the DNS, in
   some order, until a working address is found.  In particular, the
   application has to be able to handle all IP versions returned from
   the DNS.  This issue is discussed in more detail in [DNSOPV6].

This is where the SERVICE PORT and idea of using SERVICE NAMES comes into play.

In RFC 4472, section 4.1 it says:

   4.1.  Use of Service Names instead of Node Names


   For example, assume a node named "" provides both
   SMTP and IMAP service.  Instead of configuring the MX records to
   point at "", and configuring the mail clients to
   look up the mail via IMAP from "", one could use,
   e.g., "" for SMTP (for both message submission and
   mail relaying between SMTP servers) and "" for IMAP.
   Note that in the specific case of SMTP relaying, the server itself
   must typically also be configured to know all its names to ensure
   that loops do not occur.  DNS can provide a layer of indirection
   between service names and where the service actually is, and using
   which addresses.  (Obviously, when wanting to reach a specific node,
   one should use the hostname rather than a service name.)

Note that last sentence as well - a continuation of the implicit MX concept.

And here is an important section 4.3 is I fully agree with:

   4.3.  Adding the Records Only When Fully IPv6-enabled

   The recommendation is that AAAA records for a service should not be
   added to the DNS until all of following are true:

   1.  The address is assigned to the interface on the node.

   2.  The address is configured on the interface.

   3.  The interface is on a link that is connected to the IPv6

   In addition, if the AAAA record is added for the node, instead of
   service as recommended, all the services of the node should be IPv6-
   enabled prior to adding the resource record.

   For example, if an IPv6 node is isolated from an IPv6 perspective
   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
   that it should not have an address in the DNS.

All that basically means that its going to leak into the IPv4 network cloud, it better be ready to allow for a reverse communications.

Then we get to section 5.1, and again the all encompassing getaddrinfo() recommendation:

5.1.  DNS Lookups May Query IPv6 Records Prematurely

   The system library that implements the getaddrinfo() function for
   looking up names is a critical piece when considering the robustness
   of enabling IPv6; .....

and finally on a slightly different but highly critical related note, see section of 7.1 regarding how PTR lookups may or may not be necessary any more under IPv6.

  7.1.  Applicability of Reverse DNS


  It is not clear whether it makes sense to require or recommend that
  reverse DNS records be updated.  In many cases, it would just make
  more sense to use proper mechanisms for security (or topological
  information lookup) in the first place.  At minimum, the applications
  that use it as a generic authorization (in the sense that a record
  exists at all) should be modified as soon as possible to avoid such
  lookups completely.

All and all Doug, making a decision now about implicit MX in 2821bis might be the wrong move when one begins to implement IPv6 with the current recommendations.


Hector Santos, CTO