[Top] [All Lists]

Re: deprecate implicit MX even for IPv4

2008-04-07 13:47:12

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

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