When you set up a mail client, you have to configure mail reading servers (either IMAP or POP) and also a mail sending server (SMTP). In the old days you could just configure one SMTP server, with no userid or password. Due to spam-blocking, roaming computers have it hard, and either must change SMTP servers as they roam, or use one that has some sort of authentication scheme that opens it up to you and not everybody.

Worse, many ISPs now block outgoing SMTP traffic, insisting you use their SMTP server (usually without a password.) Sometimes your home site has to run an SMTP server at a non-standard port to get you past this.

I propose that IMAP (and possibly POP) include an extension so that the IMAP server can offer your client information on how to send mail. At the very least, it simplifies configuration for users, who now only have to provide one server identity. From there the system configures itself. (Of course, the other way to do this is to identify such servers in DHCP.)

This also simplifies the situation where you want to use a different SMTP server based on which mail account you are working on, something DHCP can't handle.

The IMAP server would offer a list of means to send mail. These could include a port number, and a protocol, which could be plain SMTP, or SMTP over SSL or TLS, or even some new protocol down the road. And it could also offer authentication, because you have already authenticated to the IMAP server with your userid and password. It could tell you a permanent userid and password you can use with the SMTP server, or it could tell you that you don't need one (because your IP address has been enabled for the duration of your IMAP session in the IMAP-before-SMTP approach.) It could also offer a temporary authentication token, which is good only for that session or some period of time after it. Ideally we would have IMAP over SSL/TLS, and so these passwords and tokens would not be sent in the clear.

With a list of possible methods, the client could chose the best one. Or, of course, it could chose one that was programmed in by a user who did custom configure their own SMTP information.

It's also worth noting that it would be possible, down the road, to use the very same IMAP port for a slightly modified SMTP session to an IMAP server set up to handle this. This could handle firewalls that block all but that port. However, the main benefit is to the user with simpler configuration.