Re: Submission and SMTP SRV records

--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
> harm.
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
> >         issues).
> 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 "_submission._tcp.qualcomm.com" 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
> space.
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?
   john