At 04:57 -0400 on 04/07/2008, Hector Santos wrote about Re: deprecate
implicit MX even for IPv4:
Hector Santos wrote:
I say leave well enough alone and if you want to invent NEW
expectations, then you MUST raise the bar from what is normally
done and you can only do this with NEW indicators and state values.
is IPv6 it? From a legal standpoint, I say yes.
Is DKIM it? From a legal standpoint, I say yes.
Is Port 587 it? From a legal standpoint, I saw yes.
But not a legacy system like IPv4 with no indicators, I say no.
I will add to this a SMTP session with a HELO/EHLO domain literal
that is in the IPv6 format.
This would provide legal ground to do something that is NEW and
acceptable with new provisions in the new standards. Since the SMTP
client raised the bar (open the door) by showing something new, it
provides the opportunity for a new level of actions a receiver can
So to me, if you want to propose if a SMTP client is showing a IPv6
domain literal for the EHLO/HELO, then the idea of not doing
IMPLICIT MX is 100% acceptable to me.
One question - What does the client using a EHLO/HELO with an IPN
literal (or a FQDN) have to do with the MAIL-FROM FQDN of the Email
Address? Just because the client called itself Domain1 does not mean
that the email with MAIL-FROMs of Domain2 is going to have its
replies (or status messages) sent to a MTA at Domain1 (Domain2
incoming mail might be serviced by a different ISP or Domain). As a
perfect example, my client is identifying itself via my OptOnline.Net
Connectivity Provider FQDN/IPN yet the email is going to Panix.Com
MTA and replies will get sent to Panix not OptOnline.
The same applies in a POST SMTP logic where the 822 headers have
DKIM headers. This raises the bar the CLIENT has put in himself
into and can not claim anything against new standards that with with
the new information provided by the client.
Hector Santos, CTO