headers
Pete Resnick | 16 Mar 2004 22:54

Submission and SMTP SRV records


Is anyone implementing SRV records for either SMTP or for Submission 
(i.e., SMTP SUBMIT extension)? Some talk about implementation raised 
some questions:

- SRV is pretty redundant with MX for SMTP, though you could 
conceivably use SRV to specify an alternate port number. Has anyone 
attempted this?

- SRV for submission is an interesting way for an client to figure 
out which server/port it should contact, but what exactly would the 
query look like? Should you take the right hand side of your e-mail 
address and query, taking me as an example, 
_submission._tcp.qualcomm.com? Should you be looking up 
_submission._tcp.4.3.2.1.in-addr.arpa (assuming your own IP address 
is 1.2.3.4)? And again, has anyone tried any of this?

It would be nice if we had a convention for such a lookup.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 33 comments |
headers
Eric A. Hall | 16 Mar 2004 23:22

Re: Submission and SMTP SRV records


[top-post for context]

See http://www.ietf.org/internet-drafts/draft-hall-email-srv-00.txt

I have gotten some recent feedback and am going to be updating it soon.
I'd like to hear any feedback you might have on it.

On 3/16/2004 3:54 PM, Pete Resnick wrote:

> Is anyone implementing SRV records for either SMTP or for Submission 
> (i.e., SMTP SUBMIT extension)? Some talk about implementation raised 
> some questions:
> 
> - SRV is pretty redundant with MX for SMTP, though you could 
> conceivably use SRV to specify an alternate port number. Has anyone 
> attempted this?
> 
> - SRV for submission is an interesting way for an client to figure 
> out which server/port it should contact, but what exactly would the 
> query look like? Should you take the right hand side of your e-mail 
> address and query, taking me as an example, 
> _submission._tcp.qualcomm.com? Should you be looking up 
> _submission._tcp.4.3.2.1.in-addr.arpa (assuming your own IP address 
> is 1.2.3.4)? And again, has anyone tried any of this?
> 
> It would be nice if we had a convention for such a lookup.
> 
> pr
(Continue reading)

Permalink | Reply | 30 comments |
headers
Keith Moore | 16 Mar 2004 23:33
Picon

Re: Submission and SMTP SRV records


> Is anyone implementing SRV records for either SMTP or for Submission 
> (i.e., SMTP SUBMIT extension)? Some talk about implementation raised 
> some questions:

I hope that nobody is doing this in shipping product.
There's a reason that RFC 2782 contains the following text:

> Applicability Statement
> 
>    In general, it is expected that SRV records will be used by clients
>    for applications where the relevant protocol specification
>    indicates that clients should use the SRV record. Such
>    specification MUST define the symbolic name to be used in the
>    Service field of the SRV record as described below. It also MUST
>    include security considerations. Service SRV records SHOULD NOT be
>    used in the absence of such specification.

Adding SRV to an existing application can break compatibility with that 
application, unless it's done very carefully.  For instance even if
there were SRV records pointing to an SMTP server, existing clients
would not recognize them - they would be looking for MX or A (or perhaps
AAAA)  records.  And new SRV-aware clients would behave differently than
existing clients, leading to more difficulty in tracking down problems. 
(Yes, at one time we migrated mail from just A records to MX records,
but that took several years to work reliably, and the net was much
smaller and less diverse then.  And in the interim it was necessary to
use a domain that happened to correspond to an A record if you wanted
mail to work reliably).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 17 Mar 2004 00:27

Re: Submission and SMTP SRV records


On 3/16/04 at 4:22 PM -0600, Eric A. Hall wrote:

>See http://www.ietf.org/internet-drafts/draft-hall-email-srv-00.txt

Cool. Always good to read documents; I have to pay more attention. 
:-)  In there, you write:

         b.  Extract the mail domain element from the user's email
             address, and append the "_submission" and "_tcp" labels to
             the left of that domain name.

Have any of the big ISPs deployed the appropriate records to try this yet?

On 3/16/04 at 5:33 PM -0500, Keith Moore wrote:

>Is anyone implementing SRV records for either SMTP or for Submission 
>(i.e., SMTP SUBMIT extension)? Some talk about implementation raised 
>some questions:
>
>I hope that nobody is doing this in shipping product.

Not that I know of. This was talk about what could (and should) be 
desirable as a future feature.

>For instance even if there were SRV records pointing to an SMTP 
>server, existing clients would not recognize them - they would be 
>looking for MX or A (or perhaps AAAA)  records.  And new SRV-aware 
>clients would behave differently than existing clients, leading to 
>more difficulty in tracking down problems.
(Continue reading)

Permalink | Reply | 29 comments |
headers
Keith Moore | 17 Mar 2004 01:00
Picon

Re: Submission and SMTP SRV records


>> Offhand, it seems like just solving the configuration problem for 
>> mail submission is too much work for too little gain.
>
> It seems to me if (e.g.) Hotmail (or even a large corporate network) 
> could deploy an SRV for their submission servers (round-robin'ed or 
> weighted appropriately) and clients supported the SRV, that would be a 
> lot of bang for the buck in simplifying the most straightforward user 
> configuration.

I guess I'm thinking that if the user still has to configure the choice 
of POP vs. IMAP, the server for POP or IMAP, the means of 
authenticating to POP or IMAP, "leave mail on server", and various 
other IMAP frobs that sometimes seem necessary, and how to authenticate 
to the submission server, getting rid of the "submission server" 
configuration item is a minor gain.   especially when you probably have 
to add a "determine submission server automagically using SRV" check  
box.

>> What you'd really like to do is solve the entire MUA configuration 
>> problem.
>
> That's what ACAP was supposed to do, but it hasn't gotten much 
> traction, I think at least in part because it tried to solve the whole 
> problem.

thought experiment:  say you're an ISP.  what incentive do you have to 
support ACAP?

Keith
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric A. Hall | 17 Mar 2004 01:05

Re: Submission and SMTP SRV records


On 3/16/2004 5:27 PM, Pete Resnick wrote:

> On 3/16/04 at 4:22 PM -0600, Eric A. Hall wrote:
> 
>> See http://www.ietf.org/internet-drafts/draft-hall-email-srv-00.txt
> 
> Cool. Always good to read documents; I have to pay more attention. :-)
> In there, you write:
> 
> b.  Extract the mail domain element from the user's email address, and
> append the "_submission" and "_tcp" labels to the left of that domain
> name.
> 
> Have any of the big ISPs deployed the appropriate records to try this
> yet?

Some mail client devs have looked over the algorithm and otherwise
contributed but none of them have implemented it in a shipping product.
None of the email providers are publishing the RR either. Not to my
knowledge, anyway.

> On 3/16/04 at 5:33 PM -0500, Keith Moore wrote:

>> Offhand, it seems like just solving the configuration problem for 
>> mail submission is too much work for too little gain.
> 
> It seems to me if (e.g.) Hotmail (or even a large corporate network) 
> could deploy an SRV for their submission servers (round-robin'ed or 
> weighted appropriately) and clients supported the SRV, that would be a
(Continue reading)

Permalink | Reply | 22 comments |
headers
Keith Moore | 17 Mar 2004 01:09
Picon

Re: Submission and SMTP SRV records


> The problem scope is variant. None of the technologies address every
> problem of every installation. The SRV approach is intended to solve 
> the
> common problems that 90% of the market faces.

which market is that?  email users in general?  web-based email 
providers that need internal configuration solution?  corporate 
internal networks?

> I'm happy to help work on similar solutions that use other 
> technologies,
> as parallel development efforts.

well, the last thing we need is more competing ways to do 
configuration.  autoconfiguration is supposed to simplify things, but 
it often ends up making them more complex.

that's why the "90% argument" is dubious.  if the other 10% would have 
to configure things manually, and the solution works for everyone else, 
that's great.  but if you have three autoconfiguration solutions that 
each work with a different large percentage of the market, you end up 
with a real mess.
Permalink | Reply | 21 comments |
headers
Eric A. Hall | 17 Mar 2004 01:12

Re: Submission and SMTP SRV records


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

> I guess I'm thinking that if the user still has to configure the choice 
> of POP vs. IMAP, the server for POP or IMAP, the means of 
> authenticating to POP or IMAP, "leave mail on server", and various 
> other IMAP frobs that sometimes seem necessary, and how to authenticate 
> to the submission server, getting rid of the "submission server" 
> configuration item is a minor gain.   especially when you probably have 
> to add a "determine submission server automagically using SRV" check  
> box.

The draft goes out of the way to say that probing for other settings is
not prohibited. There are a couple of places where it lays down the law,
ensuring consistency where vagaries might otherwise be problematic (like
saying to check for IMAP SRV RRs before looking for POP3 SRV RRs, since
having different clients do different things would be problematic).

Most of the options that are provided by messaging clients can be
determined with sensible defaults, or with simple probes. "leave mail on
server" option is an example of the latter. Things like finding the IMAP
namespace or choosing a SASL mechanism can be discovered with probes, and
are examples of the latter. I haven't been able to find anything that is
mandatory that cannot be dealt with via probes, but that would certainly
be a show-stopper and if you find anything let me know please. Options
are, umm, options, so they can be handled with defaults like already.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric A. Hall | 17 Mar 2004 01:19

Re: Submission and SMTP SRV records


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.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
Permalink | Reply | 20 comments |
headers
Keith Moore | 17 Mar 2004 01:23
Picon

Re: Submission and SMTP SRV records


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

something that works 90% of the time is unacceptably unreliable.
something that works 99.999% of the time for 90% of users might be 
acceptable, provided that the 90% contains essentially everyone with a 
reasonable expectation of having mail autoconfigured.
Permalink | Reply | 7 comments |

Gmane