in windows you would specify the computer and workgroup names...or Domain name.

Sorry Matt, I don't see what you mean. My computer has a name and a workgroup name configured in Windows. It also has an entry (FQDN) in my local DNS (which just happens, at the moment, to be running on the same machine). That doesn't stop TBird identifying itself to the mail server as [<IP address>] - logged by the server as "EHLO [<IP address>]".

The client part of my mail distribution system, for example, has an "Identify myself as" setting in which I can enter the HELO/EHLO response that I require (its public DNS entry).

It's not necessarily illegal to use a local IP address in an EHLO/HELO greeting, but it's not helpful either. Ideally, a fully qualified domain name would be used to identify the submitting e-mail client, but that's not always available, especially not behind a router employing network address translation (NAT).

By default, Thunderbird uses the IP address associated with the network interface on your computer used to send the message. It is possible to change that with a hidden preference setting.

Follow the instructions in http://forums.mozillazine.org/viewtopic.php?f=39&t=574630 or http://forums.mozillazine.org/viewtopic.php?f=28&t=1915643 to set server-specific or global greeting strings.

Re "in windows you would specify the computer and workgroup names...or Domain name" - for Mac OSX and Linux, the hostname is taken as defined in the system; on Linux at least, it is only used if it is a FQDN (simple test though: if it contains a dot). On Windows, the system hostname is never a FQDN, thus the IP address is taken as the fallback (i.e., always).

To rsx11m "It's not necessarily illegal to use a local IP address in an EHLO/HELO greeting..." That's why I wrote 'Strictly speaking...' and '"illegal"'. The "legality" depends on the context. In the local private domain it's OK. In the public domain, a private IP is most strongly deprecated as it does not permit the machine to be identified in any way whatsoever. It makes EHLO/HELO rather pointless, it might just as well be 'EHLO/HELO <blank>'. When running TB and server on the same windoze box, you get 'EHLO/HELO [127.0.0.1]', which is equivalent to 'EHLO/HELO here' - equally unhelpful. Will check out your links and see if one of them matches my version of TB (the last one I found did not). I have TB 24.4.0.

Hi again. You forgot to cite but it's not helpful either from my previous post. ;-)

Given that likely most users are sitting behind a router/modem employing NAT these days (unless you are in a corporate or institutional network using static addresses or at least a fixed dynamic address range as registered), the HELO greeting argument has become virtually useless. Like any other e-mail client, Thunderbird only sees local configuration parameters, thus whatever name was assigned to the machine and the IP address bound to the network interface are the only information available. While desirable, there is no easy way for it to figure out the real outside-world IP address or FQDN.

On the other hand, most providers' servers consider that and adds it like

• Received: from [192.168.0.2] (xyz-dynamic.example.com[xxx.xxx.xxx.xxx])

to the headers. Thus, in general that information is preserved on the way.

The other question is how spam filters score the greeting; i.e., if you get a higher score with a local IP address, a true IP address, an arbitrary name, or a FQDN (properly DNS-registered or not). That probably depends on the filter employed and how it is configured, thus there may not be a clear rule.

To rsx11m: Tried your 2 links. It looks logical but I still get IP in square brackets. Tried helo instead of hello, still no joy. What's up?

That's weird, works for me with 24.4.0. The instructions of the first thread, e.g., setting mail.smtpserver.smtp1.hello_argument to example.net, result in

• Received: from example.net (xyz-dynamic.example.com[xxx.xxx.xxx.xxx])

as expected (this matches my SMTP server #1).

Do you have multiple SMTP servers configured? If yes, either each of those will have to be changed individually, or the mail.smtpserver.default.hello_argument preference used as suggested in the second thread.

To rsx11m:

OK, spelling error found, it now works - Thanks.

You are welcome.