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,
- ESMTP AUTH,
- POP B4 SMTP
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 @ validdomin.com
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 "pobox.example.com" provides both
SMTP and IMAP service. Instead of configuring the MX records to
point at "pobox.example.com", and configuring the mail clients to
look up the mail via IMAP from "pobox.example.com", one could use,
e.g., "smtp.example.com" for SMTP (for both message submission and
mail relaying between SMTP servers) and "imap.example.com" 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
infrastructure.
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com