The Thunderbird email client has a potentially useful autoconfiguration feature for configuring its server settings. It tries to fetch http://example.com/.well-known/autoconfig/mail/config-1.1.xml (and various similar URLs) and parse that file to obtain the hostname, port, etc. the server expects clients to use.
If this fails, it tries to guess by connecting to likely ports and seeing what happens. This sometimes works, but often doesn't, mainly because the response handling is excessively picky and the error handling is rudimentary and ill-thought-out; not only does it get wrong answers but it can also get stuck in a state where the setup process is impossible to complete because the error handling has disabled the very feature you need to correct the error yourself. This is exacerbated by the way it tries to turn every possible security setting up to 11 and then drops the error on the floor when the server turns out not to support something. And it refuses to let you save a configuration if it can't get a non-error response to trying every item in it live; there's no way to tell it "yes I know I haven't set so-and-so, that's because I don't want to, just fucking save it you stupid machine".
The autoconfig file can get around most of this by telling it the right answers so it doesn't get obvious things wrong and then shit its pants about it. It doesn't stop all the errors and there still exists the possibility of the impossibility of completion, but it does make an important difference.
In particular it has the potential to help with the situation where incoming and outgoing mail follow entirely different routes. For example a machine which isn't always connected so uses an external server to handle incoming mail but sends by SMTP directly to the receiving server or via a local relay. The setup process tries to force you to have both servers on the same domain and gets its knickers in a twist when they aren't. You want to leave the SMTP server set to the system default and only configure the IMAP/POP server, but the setup process determinedly insists on forcing you to have an SMTP server on the same domain it's guessed the IMAP server is on, and when it finds port 25 open on the IMAP server it is likely to succeed even if you can't use that as a relay yourself. So when setting up an IMAP server for this purpose it would seem to be a good idea to make it serve an autoconf file that can tell Thunderbird that no, we don't do SMTP relaying here, we just provide an IMAP server and that's your lot.
Only it won't bloody do it. If you simply don't include an <outgoingServer> tag, Thunderbird moans that there isn't an <outgoingServer> tag. If you include an empty <outgoingServer> tag, it moans that it isn't of type SMTP. If you include an empty <outgoingServer type="smtp"> tag it would probably moan about some other fucking thing, but in fact it bombs out the XML parser before it gets that far, and the same thing happens if you include the usual <hostname> etc. tags but leave them empty or provide dummy content.
Furthermore, the documentation on the file format is shit. It gives a sample file, but nowhere is there a list of all the tags it understands, which ones are optional and which ones aren't, what it thinks are valid values for them, etc. Nor is there any such list anywhere on any other Mozilla site or indeed anywhere else on the net - everything just ends up linking back to the same page linked above. If you want to find out what tags exist that aren't mentioned in the sample file, or what tags in the sample file you can leave out when they're not relevant, or what it would consider valid as a dummy value for ones you can't leave out but also can't supply a sensible value for, etc, it seems you have two options and they're both shit: edit the file on the server and then try and make a Thunderbird instance configure itself with it to see what happens, until (0), or pick out the answers from the Thunderbird source code (having first understood exactly what it is that makes it sometimes crash its XML parser on semantically valid input so you don't end up trying stuff that looks like it should work but actually doesn't).
Nor does it help to go round hitting random email providers' servers with wget to see if they're using any potentially useful variations in their own Thunderbird autoconfig files. Elsewhere on Mozilla's site there is another sample file, a "real-world example", which is rather less informative; a few email providers have installed obvious clone-and-hack copies of this file, and all the rest haven't bothered to install anything.
It doesn't look like I'm the only one who's run into this, either, since while poking around the net looking for information about it I found quite a few other people complaining about it but nobody offering any solution.
It also doesn't bloody help that the abovelinked page does one of the pieces of infuriating shit that all too many websites have started doing these days - styling everything to use a fucking huge massive font so you get less text on the screen than you do on a postcard. Which makes the sample file fucking impossible to read until I added my own CSS rule to use 12px for pre elements.
Which meant it took far too long until I even noticed the possibility of experimenting with this, buried at the bottom of the outgoing server section of the sample file:
<!-- remove the following and leave to client/user? --> <addThisServer>true</addThisServer> <useGlobalPreferredServer>true</useGlobalPreferredServer>
By fiddling with this I arrived at what seems better described not exactly as a solution, but as a hack to get the right result, for the abovementioned desired setup. I ended up with an <outgoingServer> section containing the details pertaining to the incoming server as placeholders - while it is not usable as an outgoing server, it will give the required positive answer to the question "is port 25 running an SMTP server?" - followed by a modified version of the above snippet of XML:
<outgoingServer type="smtp"> <hostname>example.com</hostname> <port>25</port> <socketType>plain</socketType> <authentication>password-cleartext</authentication> <restriction>client-IP-address</restriction> <username>%EMAILLOCALPART%</username> <addThisServer>false</addThisServer> <useGlobalPreferredServer>true</useGlobalPreferredServer> </outgoingServer>
With this file on the IMAP server, it was possible to successfully configure a fresh instance of Thunderbird without defining an outgoing server. It still tried EHLO on port 25, but it didn't do any more than that, didn't try to log in. Outgoing server entries in the various settings dialogues were either empty or "use system default".
And having thus got it working, that was it, thank you very much. I did not feel inclined to experiment with any variations on the theme, such as what happens if <useGlobalPreferredServer> is set to false, or what happens if there is no dummy outgoing server available at all so it can't even find a port 25 to say EHLO to. I just filed the experience in the overflowing mental wastebasket labelled "things that try to be "helpful" but are actually just a pain in the fucking arse".
A couple of days later... I went through the process of configuring a fresh instance of Thunderbird again, in order to take screenshots of each stage. And this time it didn't touch port 25 at all. Don't know why it sometimes does and sometimes doesn't but it may be possible to use this method when the outgoing server is offline.
Back to Pigeon's Nest
Be kind to pigeons