[Top] [All Lists]

Re: Submission and SMTP SRV records

2004-03-17 15:33:05

--On Wednesday, 17 March, 2004 16:00 -0600 Pete Resnick <presnick(_at_)qualcomm(_dot_)com> wrote:

On 3/17/04 at 10:13 AM -0500, John C Klensin wrote:

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

Unless we solve the entire configuration problem (which I
think is intractable), there will *always* be some hand
configuration, whether that involves firing up a VPN tunnel on
your OS (well below the layer that most MUAs worry about),
entering your own e-mail address, or choosing the screen font
to display menus in your MUA. None of those problems are
addressed by a solution which finds a server based on an
e-mail address. Keith's argument (as I read it) was not only
that solving this one problem isn't worth it, but that it
might actively cause harm. I don't think the relative value
question is one we need to worry about; that's strictly a
judgement call for those wanting to implement it. If such a
solution causes harm *is* something we need to worry about,
but I've seen no convincing argument that it would cause any

If you insert "major" between "any" and "harm", I agree with you. I could quibble about "any", but that isn't the point (see below). One of the reasons I quibble about 90% is that all of my travelling machines are configured with the submission server set to "localhost". That isn't because I'm running a local queuing SMTP server, but because I submit mail over an SSH tunnel... and, of necessity, all of the relevant configuration is done in SSH, not in SMTP. Whether this is the best way to do things, or even a good one, is irrelevant -- enough people do things that way or in similar ones to make me skeptical about "90%" claims.

But the core of this is the deep philosophical question of whether we should publish, or publish as standards, things that are not obviously harmful if used carefully and where there are interoperability benefits (however slight) of everyone doing things the same way. The counter-theory, stated extremely, is that we should not publish anything that could be harmful, no matter how it is misused. I am clearly in the former camp: I think it is reasonable to document the pitfalls and issue warnings, but that interoperability is a good thing, even when it is interoperability among ideas that aren't wonderful.

        * 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

No, I think you've gotten this completely wrong. Dynamic DNS
or intimate relationships with the airline have no bearing at
all on the example. In the airplane case, my IP address might
be changing a lot, my DNS servers and other information
returned by DHCP might be changing a lot, but (assuming the
protocol used in the draft) if my e-mail client is configured
with an e-mail address of "presnick(_at_)qualcomm(_dot_)com", an SRV
lookup for "" is going to return
the same answer every time, no matter where in the world I'm
connecting from and I'm going to connect to the same
submission server every time.

Yes, that is exactly what it is going to do. And whether that is wise or not depends on whether there is a submission server on the airplane that can burst things out and, if there is, whether you are willing to use it. I'm agnostic on whether you should be willing, but whether you are or not is a key issue.

It *would* be a problem if we were using the "I want a server
on *this* network" model, but that isn't what's discussed in
the draft.

And my point was that "I want a server on *this* network" is another common case. Is it more common or less common? I don't know and don't care. But the two cases are both common enough that a 90% of cases claim for one or the other strikes me as dubious. Mind you, while I don't share Eric's enthusiasm, I think the draft is an adequate solution to one of these types of configuration requirements (and "not significantly harmful"). I just don't think we should confuse ourselves by pretending that it is a universal solution.

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

Though there is a great deal of blocking of port 25 (or even
worse, redirecting), I'm not sure blocking of 587 (or other
submission ports) is a problem. I think "local submission
server that will accept my relay traffic" is not a concept
that's going to survive the latest wave of anti-spam maneuvers
by ISPs. Furthermore:

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

I think DHCP, and not SRV, would be the right way to handle
such a case if one wanted to address that particular problem

We agree, but I note that DHCP is, as I think Keith pointed out, a bit too tied to address assignment. If we want to use it this way, we really need to sort through the cases of a DHCP server that gets a request for information from a host whose address it didn't assign (PPP and PPPoE being two of the more obvious cases in addition to classic static address configuration).

I do think the ability to find "the submission server that
goes with this domain name from this e-mail address" is going
to be an increasingly widespread desire. Whatever the
percentage may be, I'll bet it's on the rise.

I bet it is too, although I have no idea whether setting up of tunnels, etc., will largely subsume the need to use SRV for this. That is _not_ an argument against having the SRV capability, just a caution about wild statements about its likely utility (which I note you haven't made).

That said, let me suggest an odd way to look at the problem. Oversimplifying somewhat, we have two cases (there are others, too, but let's focus on these):

        (1) "I want the server which I can use that is closest
        to me so I can unload this email and let it handle the
        stuff".  "Local submission server that will accept..."
        is just one form of this case.
        (2) "I want the server that is optimal for the domain of
        my mailbox, but not necessarily 'closest'".  The SRV
        proposal addresses this one.

Now the first of these is perhaps best addressed by some modified version of DHCP, even though the best server may not belong to the address-assigner. One could also think about using some SRV-based approach based on the address of the mail-originating host. The second is more interesting, because the problem, modulo issues of port numbers, may be exactly the one that MX was intended to solve -- a more or less static list of preferences of mail server hosts to get closest to a particular target. You will recall that we had a discussion during the DRUMS effort as to whether SMTP originators should use MX records to access the first hop relay and concluded that they should not, partially because that relay was best configured in some static way. I wonder whether that decision should be revisited?