[Top] [All Lists]

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

2008-04-07 00:28:06

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
        MAX = GET_MAX(domain)
        if MAX is OK then
           attempt to send mail to MAX

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
        //--------- NEW LOGIC -----------
        if I am IPv6 only then
           MAX = GET_AAAA(domain)
           MAX = GET_A(domain)
        //--------- ROBERT LOGIC -----------

        if MAX is OK then
             attempt to send mail to MAX

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.


Hector Santos, CTO

<Prev in Thread] Current Thread [Next in Thread>