Localized mail servers, global scope

Thu Jun 23 11:19:31 UTC 2005

<Michael.Dillon at 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 at example.com> SIZE=1234 XREDIRECT
<<< 250 OK
>>> RCPT TO:<jim at example.net> XREDIRECT
<<< 411 gb.example.net XREDIRECT
>>> RCPT TO:<sheila at 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