Is there a workaround for Thunderbird in a corporate environment 352

Well, yes. That's the way it's worked for the last 30 years or so. Time for a quick history lesson.

Originally MUAs ran on the server alongside the MTA, and they just handed messages off to the MTA and let it worry about addresses. An address without a domain portion meant the address was on the local machine (you want local e-mail to work even if the network interface is down or the machine isn't connected to a network). To keep things consistent on network-connected machines, the MTA was often configured to append the correct domain portion for the local machine onto bare addresses before delivering them. That way the addresses always looked the same regardless of whether the message was locally delivered or not. MTAs that did this usually also did it for the sender's address as well. MUAs thus never had to worry about the domain, they just sent to their proper MTA server and it worried about all the rest. It also meant the mail admins didn't have to worry about whether or not the users knew what their proper domain was. As a final embellishment, the MTAs were set up to be able to recognize a list of domain portions as "local" and to be treated as if they'd been left off of the address, so if machine mail.domain.com handled mail for domain.com then addresses "user",

With the advent of network-connected PCs that couldn't run MTAs locally (and whose users wouldn't know how to configure the MTA even if it could run), the "smart-host" was born. This was a mail server running an MTA set up to handle submissions from remote PCs as if they were locally-generated messages. Properly configured, the smart-host would do the same domain appending as described above. The PC's MUA simply opened an SMTP connection to the smart-host and sent the mail and the smart-host would take care of appending the right domain to any bare addresses. "local" now morphed from "local user on this machine" to "directly handleable by my smart-host", but MUAs still just didn't have to worry about domains for "local" users. The local-domain list above was extended to handle the case of PCs that knew and used their own hostnames in "local" addresses, so if mail.domain.com from above was the smarthost for machine office123.csc.domain.com then mail.domain.com and would all be equivalent.

Meanwhile over in the Windows world mail systems were developed without a clear distinction between MUA and MTA. MUAs were part of the mail system and tasked with getting the domain portions of addresses right. This was fine when it involved a single LAN and one set of admins set up all the client software but starts to cause headaches when clients set up by one group have to be consistent with servers run by another group, especially when the client group doesn't know what settings the server group needs to have. When those Windows systems had to start talking to Unix servers, the Unix guys came up with a simple solution: the Unix MTAs were configured to know the proper domains for the Windows clients and would *force* the domains to be correct when neccesary. Windows mail server software didn't develop the same capabilities so Windows mail servers tend to require more care in setting up the clients correctly. Indeed, SMTP is often treated as a second-clbutt protocol by things like Exchange and little attention is given to making it work exactly like the first-clbutt proprietary protocol does, so quite often people simply give up on using SMTP-only clients like Thunderbird with Exchange, Notes, etc. and either switch to the proprietary client or point Thunderbird to a "real" Unix MTA that can handle things without the client having to know domain and addressing details.

-- rest.net: because for some problems there's only one solution.