[Top] [All Lists]

Re: Using SUBMIT without bothering the user (was Re: MyDoom, Sorbig - Actions taken?)

2004-02-05 11:18:31

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


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.

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.


<Prev in Thread] Current Thread [Next in Thread>