IMAP server should tell you your SMTP parameters

Topic: 

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.

Comments

Designate a particular mailbox as an OUTBOX. Messages copied to the OUTBOX would be injected by the IMAP server into the local MTA. This could even be implemented by a cron job on the server without support of either the IMAPd or the mail client, although both would be better.

Eudora's XTND / XMIT extensions.
http://www.panix.com/help/mail.xtnd.html

Realize that XTND/XMIT and other proposals to send email over the open imap or pop channel are not the same because they are creating a new protocol for sending mail. We already have a very advanced one in SMTP. (The "S" no longer means what it was meant to mean!) We don't want programs to have to support multiple protocols. This is more about helping the user configure than giving them another way to send mail, and allowing the outgoing config to be variable based on the incoming.

I simply noted that for those who want to send mail over the same port, this could be done. You don't want to use the same connection, because if you have a large email to send, it would block up your channel until it was done. Plus the receiving server may decide to sever the connection on you in mail sending more often than in IMAP.

So why did Eudora's feature die?

Why not just create another folder? Give it a name something like SMTP or outgoing. Then put messages in the folder with login information for the SMTP server. This can be done now and would give the user some idea how to configure the SMTP client.

freak3dot

Add new comment