Re: Using SUBMIT without bothering the user (was Re: MyDoom, Sorbig - Ac

--On Thursday, 05 February, 2004 10:44 -0800 william(_at_)elan(_dot_)net 
wrote:
> > > Which reminds me. How is a MUA supposed to find its submit
> > > server?
> >
> > The same way an MUA finds an SMTP server to submit mail.
> I think above refers to that SMTP and POP3/IMAP server names
> are  preconfigured in the mail client setup for each user.
Yes.

> That does not however means we can not provide default values
> that lot  less advanced users could find useful and passing
> default values to user  for certain protocols is not really
> SUBMIT protocol only question (i.e.  not really for
> ietf-smtp). The protocol that is often used to pass on
> default parameters for host configuration is DHCP when it
> provides  computers with ip address, dns server name, etc.
In theory, DHCP could be used to pass that information.  If I 
recall, there is a key in there for SMTP server, but not a 
separate one for a Submit server (which might be different). 
But I know of no MUAs that pay any attention to DHCP-provided 
information and few or no operating systems that make 
miscellaneous DHCP key-value pairs available to applications in 
any event.
> if
> you look at IETF  work, I beliebve "Service Location Protocol"
> (see RFC2608) could be the  new generation version ofthat. I'm
> not sure if anybody actually ever  attempted to use that for
> configuring default SUBMIT server name - that  would require
> extension to client mail program obviously, but I dont see
> why it would not work if the functionality was written.
There is an Internet-Draft (draft-hall-email-srv-00.txt) that 
Eric Hall and I have been working on intermittently that 
specifies a way to use SRV for that purpose.   The difficulties 
are just the ones that earlier responses in this thread have 
identified, e.g., figuring out what to use as the lookup key. 
I've been somewhat dissatisfied with the proposal as a result 
and, in particular, with the differences between:
        * I want to find a Submit server on the subnet to which
        I'm attached, but want (or need) to use an Reverse-path
        address associated with that location.
        
        * I want to find a Submit server on the subnet to which
        I'm attached, but need to find one that will let me use
        my preferred Reverse-path (which may require telling the
        SRV process what that address is).
        
        * I want to find a Submit server associated with my
        corporate/ enterprise/ personal LAN, even though I may
        not be physically attached to it but may, instead, be
        connecting into it via an application-layer, IP-layer,
        or below-IP-layer tunnel/ VPN  (It is possible that
        those are actually three or four different cases.)
        
        * I want to find a Submit server associated with my
        corporate/ enterprise/ personal LAN, but may plan to
        access and authenticate myself to it using SMTP AUTH
        rather than any technology that depends on network
        addresses topology.

The I-D covers roughly one of those cases, and I will probably 
continue to find it unsatisfying until most of them are 
addressed in some way.
> Perhaps if some  enterprise mail package vendor would
> implement it and pitch it along to  their fortune500 clients
> as great new "feature", word would spread and  eventually this
> might get implemented by others...
Flying pigs may need to be inserted here by reference.  Most of 
the LAN and enterprise network planners for those Fortune 500 
clients whom I've run across are much happier with a client (or 
associated Operating System) that they can custom-configure for 
the server(s) they want used and that is then _really_ hard to 
change and reconfigure.   When one discusses service location 
models with them for anything less passive --and more subject to 
problematic spoofing-- than "find an appropriate printer inside 
my firewall", their reaction is mostly "this sounds like another 
opportunity for someone to attack my network and users".
But hope springs eternal.

   john