[Top] [All Lists]

Re: Submission and SMTP SRV records

2004-03-17 08:13:04

--On Tuesday, 16 March, 2004 18:19 -0600 "Eric A. Hall" <ehall(_at_)ehsco(_dot_)com> wrote:

On 3/16/2004 6:09 PM, Keith Moore wrote:

which market is that?

The people that have an email address (100%), and for whom SRV
lookups would work 90% of the time.


With respect, I don't believe this either. The reality is that there are a number of cases for locating submission servers, depending on network topology and technical restrictions. I can't even guess at the percentages, but I'd guess that "90%" as a description of the number of cases in which, not only would SVR lookups "work", but that they would yield a good result and solve enough of the problem to be worth the trouble would be _very_ high.

I would characterize the approach of the proposal in draft-hall-email-srv-00.txt as "find the name of the server that matches your email address given organization preferences". As we have discussed, that makes sense for some situations. But, even within that model:

        * Getting to that server may, in practice, require
        either special authentication setups or running a tunnel
        to get to the server, a tunnel that might otherwise not
        be present.  The presence or absence of SRV information
        is not likely to be a big help with that so, for some
        cases, Keith's argument (as I interpret it) that enough
        hand-configuration is required that SRV doesn't solve
        enough of the problem to be worth the trouble may be
        very relevant.

        * You wrote in a later note... "Moreover, SRV "works" in
        more situations than all of the others. I mean, DHCP is
        pretty cool but it doesn't "work" when I'm dialing up
        from an airplane and getting "local" PPP (that changes
        every 300 miles) and no localized proxy gateway to my
        home server".  Well, I don't think that, on that
        airplane, the SRV model in the draft is going to work as
        expected either, at least unless your organization has
        an implementation of dynamic DNS that might be
        considered to go past the basic model of the DNS spec
        (giving you widely different answers based on the IP
        address range from which your query came) and had a
        fairly intimate relationship with the airline.  That is
        probably a case of the model outlined below, but need
        not be (and it raises a whole collection of trust

More important, it isn't the only model. In today's network, where ACL restrictions on SMTP connections outgoing from particular subnets are common (I'm not suggesting that they are a good idea, only that they are common), it would make far more sense to support an inquiry for "submission server that I can reach from my address and that will accept my relay traffic". That could, of course, be done with an SRV setup and a different style of query. Or it could, in principle and in many cases, be done with DHCP when (or after) the local host or gateway address is assigned (but no one I know of supports that either).

Keith has addressed some of the other cases here, and I won't bother to repeat them.

That said, Keith, what convinced me to put my fingers into this proposal wasn't a "this is good" argument, much less a "90%" one. I'm still very skeptical about SRV use for anything off-LAN, where I see it filling in for some of the deficiencies that you identify with DHCP. But it is something that people are obviously going to think about -- the fact that Eric and Pete started doing so is evidence of that. I suggest that the benefits of interoperability in cases of "if you are going to do this [possibly dumb] thing, then doing it the same way that others do" justifies some work and, if you will, standardization _without_ a recommendation to implement. I hope the proposal --which I hope you have read by now-- is clear that it is in that "if you decide to do something like this..." category. If it is not, I (and I hope Eric) would welcome text. I would even welcome text along the lines outlined in some of your notes, e.g., a clear statement of the cases for which this particular approach is not applicable, the problems it doesn't solve even within the applicable range, etc.