Re: Minor is. It's not a pardigm change

Robert A. Rosenberg wrote:
> I agree with your statements. For historical reasons we MUST allow use 
> of the A records in the FQDN IN group (since no-one has had the guts to 
> ramrod an RFC that says "Enough is Enough. MX has been in existence for 
> 20 years and that is enough time to have gotten off your rumps and added 
> MX records pointing at the A records that define your IPv4 MTAs. Thus as 
> of this Flag-Day date the ability to access an IPv4 MTA via its A record 
> instead of having a MX record point at that A record is forbidden and is 
> no longer supported").
Well, for me, practically speaking, it would have to be done as a 
deprecated option.  Still make it optional and allow the admin to decide 
when to turn it off.  So I guess specs will will eventually say "MAY?"
I would be interested in hearing how other MTA deal with implicit MX 
logic. For our MTA, it has a "1 Shot Attempt" only and that has worked 
for us.  I wonder if others have similar logic.
> The fact we allow MX-less MTAs to be accessed via an A record is NOT a 
> valid excuse to allow AAAA records to be used in this case. While that 
> WAS an excuse to allow the A record to be used (ignoring the question of 
> if this excuse is still valid), the existence of the MX record (and 
> [all-most?] 100% support for the MX record in DNS code and 100% support 
> for the MX record in the code with IPv6 support) that predates the 
> existence of IPv6, means that it should be required to exist and point 
> at the AAAA records that belong to IPv6 IPN monitoring MTAs. The use of 
> AAAA records to locate an IPv6 MTA does NOT predate the existence of the 
> MX and thus should be forbidden.
In principal I agree with your Robert, I just not convinced if its best 
decision.
Remember, I think it is safe to say that regardless of the client type, 
IPv4 or IPv6, it still needs to follow the requirement for a valid 
x821.Mail From return path.
Up to now, although there are CBV systems which attempt to verify the 
validity of the return path, whether its fake or not,  there haven't 
been, that I am aware of, any solid means of reliably and efficiently 
verifying the return path.
We been using SPF and SENDERID and that works up to a point, but 
overall, my main point is that is that the return path still needs to be 
valid.
So to me, the question really translates to how much "Humph" do we want 
to put into the return path validity idea.
Some people here think, that the return path validity is only important 
when you need it - i.e. come bounce time and not before that.
> Thus the resolution logic is as follows.
>
> 1) Look for a MX. If found go to step 3. If not found set a NO-MX flag.
> 2) Pull the FQDN IN Group by acting as if a FQDN MX 0 FQDN was found in 
> step 1.
> 3) Process the IN A/AAAA records in order (within MX Priority order).
> 4) For each A/AAAA selected in step 3, check for the NO-MX flag and if 
> found ignore the record if it is an AAAA and immediately go to step 7.
> 5) Since NO-MX is not on, we found a real MX so process the A/AAAA as at 
> present. ie: If an A, check if we have IPv4 Stack support, if an AAAA 
> check for IPv6 Stack support. Lack of support goes to step 7.
> 6) Attempt to connect to the A/AAAA designated IPN. If we get a 
> connection then process based on whatever return code we get (which may 
> mean going to the next IPN in the list [step 3] or giving up).
> 7) The current A/AAAA record is no good, If this is not the end of the 
> A/AAAA list, go back to step 3 and process the next IPN in the list. 
> Otherwise go into the "No Usable IPNs" error state and deal with it 
> appropriately.
> NOTE: This method keeps the status quo for the case where ALL the MTAs 
> for the FQDN are IPv4 MTAs (with or without a FQDN MX). It only says 
> that MX-less FQDNs are serviced by those A records in the FQDN IN group 
> and that any AAAA records found there are to be ignored.
I have to re-read the above more, but I think it sounds ok to me.

Overall, to me it is this:

I'm going to use MAX to represent a A or AAAA record.

    MAXLIST = GET_MX(domain)

    if MAXLIST has records then
        for each MAX in MAXLIST
           attempt to send mail to MAX
    else
        MAX = GET_MAX(domain)
        if MAX is OK then
           attempt to send mail to MAX
    endif

I think what you are arguing for or against is this:

    if MXList has records then
        for each MAX in MXList
            attempt to send mail to MAX
    else
        //--------- NEW LOGIC -----------
        if I am IPv6 only then
           MAX = GET_AAAA(domain)
        otherwise
           MAX = GET_A(domain)
        //--------- ROBERT LOGIC -----------

        if MAX is OK then
             attempt to send mail to MAX
    endif

Would this make sense?

Robert, maybe I am off based but I am getting the impressive that we 
really don't know what all the issues.  I say that because a lot will 
define on how IPv6 is installed on the machine.
For example, the machine IPv6 layer software might be tunneling and/or 
working with a translator unbeknowst to the SMTP client and may return 
the A record or AAAA record for you based on what is available.
If this is true, and based on my readings, there are implementations 
like this, then this would important in how SMTP with IPv6 semantics 
need to be written.
--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com