<Michael.Dillon@btradianz.com> wrote: [...]
In other words, SMTP does not have the equivalent of an HTTP redirect which is what he wants here. Maybe SMTP really is broken? ;-)
If you don't mind dirty, unreliable kludges, you could hack the server to give a 4xx and hope the client will try a different MXer. A SMTP service extension could fix this properly. Let's call it XREDIRECT, which is retured after EHLO on servers that wish to use this capability. Feel free to remove all the vowels from the extension name :) A client that is XREDIRECT-aware can indicate this by putting it in the MAIL (or RCPT?) command like so:
MAIL FROM:<fred@example.com> SIZE=1234 XREDIRECT <<< 250 OK RCPT TO:<jim@example.net> XREDIRECT <<< 411 gb.example.net XREDIRECT RCPT TO:<sheila@example.net> XREDIRECT <<< 250 OK DATA [etc]
In the case where XREDIRECT cannot be negotiated, the server will just have to accept and forward the message itself. There's obviously a lot of work involved in deciding the exact mechanism. Is gb.example.net looked up via MX, SRV, or something else? Can clients cache the name, and for how long, or do they need to initiate a new SMTP connection to the MXer for each new message, just to be told to redirect? Would extending the MX lookup mechanism with SRV records to direct to the correct server in the first place help? What about the spam implications? However, I figure that if it's useful, it'll end up in Exim et al and eventually become supported on most major mail servers through natural attrition. Do I think it would be useful? Well, I'm not entirely sure. I suppose it could be rather handy if ever email address portability becomes a legal requirement and ISPs want to avoid bandwidth being sucked up by ex-customers. -- Love is not enough. It must be the foundation, the cornerstone- but not the complete structure. It is much too pliable, too yielding. - Quentin Crisp