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?
All good questions that probably need to be discussed on some email services mailing list rather than NANOG. But don't be shy, go all the way. We are really saying that the UUCP style relaying inherent in the current SMTP mail system is not necessarily a good thing and mail server operators should not be forced into relaying. But when you follow this through to giving mail server operators the ability to redirect SMTP connections, then you are really saying, "Let's seperate email routing from email delivery". Perhaps this is the time to find a new general solution rather than continuing to tack extensions on the existing email service? I don't have the answers but I think the 10 years of failure to put a dent in spam have shown beyond the shadow of a doubt that Internet email is broken by design and bandaids are not going to fix this, no matter how many different bandaids are applied. It is time to re-engineer with the benefit of hindsight. --Michael Dillon