Sending FQDN at SMTP HELO/EHLO instead of Netbios name?
Federico Cozzi
I'd like to use either Outlook Express or Windows Live Mail (this
question applies to both) but I keep getting the same error when
sending email:
Risposta del server: 554 5.5.2 <fcozzinb>: Helo command rejected: need
fully-qualified hostname
What happens is that my company SMTP server requires a FQDN at the
HELO/EHLO greeting when I connect to the server from outside our
corporate network (sounds reasonable), yet my Outlook Express /
Windows Live Mail sends my Netbios name ("fcozzinb") instead of my
FQDN.
I have tried setting a domain in my network tab but without success.
Can someone please provide the exact steps?
The computer is WindowsXP Pro SP3 and is *not* joined to a Windows
domain.
Thanks,
Federico
![PA Bear [MS MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXsf05hH-R8XChS3fXPPzfoO8FYYxAKhT86KfPnIELr3QJ9tQ=s40-c)
PA Bear [MS MVP]
Twayne
I believe it is your ISP that determines what gets placed in the Headers
in an e-mail envelope, not your client. His software determines what's
send in the HELO/EHLO streams.
I guess that would amount to your company IT in your case. Very
often what happens is they forget to set FQDN's for the many default
settings in their software. For the longest time, my own ISP was
placing a "by 0" in its received line instead of an FQDN, simply because
they had forgotten/missed the default setting they had to adjust. I had
to climb the ladder all the way to the owner and arm him with plenty of
data before I got it fixed. What convinced him the most was showing how
he formed his headers and how other companies formed theirs. THEN he
finally decided maybe I wasn't just some wingnut with a computer setup
problem. I no longer use that ISP. They fixed it the next day. D'uhh!
Regards,
Twayne
N. Miller
> I believe it is your ISP that determines what gets placed in the Headers
> in an e-mail envelope, not your client. His software determines what's
> send in the HELO/EHLO streams.
The SMTP "HELO/EHLO" is issued by the agent connecting to the mail server.
MS Outlook Express sends, "HELO 'NetBIOS'" when it connects with an SMTP
message submission server:
| Received: from KOZUE (adsl-68-125-48-236.dsl.pltn13.pacbell.net [68.125.48.236])
| (authenticated bits=0)
| by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n1977Qpl029365
| for <******@hotmail.com>; Mon, 9 Feb 2009 01:07:26 -0600
| From: "Proper Name" <******@pacbell.net>
| Date: Sun, 8 Feb 2009 23:05:55 -0800
| X-Mailer: Microsoft Outlook Express 6.00.2900.5512
Worse, even if they did, some clients (Mozilla) products don't use the
NetBIOS name, they use the local machine IP address ('HELO 192.168.x.x', if
on a network in 192.168.0.0/24), so even setting an FQDN as the local
machine name is futile with those clients:
| Received: from [192.168.102.31] ([68.127.106.82]) by BLU0-SMTP28.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668);
| Tue, 21 Apr 2009 18:56:18 -0700
| Date: Tue, 21 Apr 2009 18:55:54 -0700
| From: Proper Name <******@hotmail.com>
| User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
The problem with expecting an FQDN from an end user client during message
submission is that most people don't set an FQDN as the computer name. This
is an issue which needs to be taken up with the administrator of the mail
server.
--
Norman
~Shine, bright morning light,
~now in the air the spring is coming.
~Sweet, blowing wind,
~singing down the hills and valleys.
N. Miller
You would need to re-run the network setup Wizard, and put the FQDN in when
it asks you for the computer name; i.e., instead of 'mycomputer', enter,
'mycomputer.example.org'.
Personally, that is a poor way to run a message submission server. If they
want security, they should require a username+password from the agent, not
an FQDN. Most user agents either use the computer NetBIOS name, or machine
IP address as the SMTP "HELO/EHLO" value. Somebody in your organization has
their head in an anatomically impossible position.
Peter Foldes
--
Peter
Please Reply to Newsgroup for the benefit of others
Requests for assistance by email can not and will not be acknowledged.
"Federico Cozzi" <f.c...@gmail.com> wrote in message
news:481f1ac5-7492-4f58...@n8g2000vbb.googlegroups.com...
Federico Cozzi
> > I believe it is your ISP that determines what gets placed in the Headers
> > in an e-mail envelope, not your client. His software determines what's
> > send in the HELO/EHLO streams.
> The SMTP "HELO/EHLO" is issued by the agent connecting to the mail server.
> MS Outlook Express sends, "HELO 'NetBIOS'" when it connects with an SMTP
> message submission server:
Thanks for your reply.
So you confirm that this behaviour can not be modified?
> Worse, even if they did, some clients (Mozilla) products don't use the
> NetBIOS name, they use the local machine IP address ('HELO 192.168.x.x', if
> on a network in 192.168.0.0/24), so even setting an FQDN as the local
> machine name is futile with those clients:
I don't know what Thunderbird sends, but it works.
On my PC, with same settings:
1. Outlook Express / Windows Live Mail get "need FQDN" message
2. Thunderbird works fine, so it sends (what the mail server believes
to be) a FQDN.
> The problem with expecting an FQDN from an end user client during message
> submission is that most people don't set an FQDN as the computer name. This
> is an issue which needs to be taken up with the administrator of the mail
> server.
I am afraid it is by decision.
If I connect to the corporate network from my office, everything works
fine.
I get the problem only when I am outside my office.
So I believe our mail server has two different settings, one for our
corporate intranet, the other for the internet at large. And only in
the second case it requires a FQDN.
It makes sense (albeit not much).
Thanks
Federico Cozzi
> You would need to re-run the network setup Wizard, and put the FQDN in when
> it asks you for the computer name; i.e., instead of 'mycomputer', enter,
> 'mycomputer.example.org'.
Great idea!
Sounds gimmicky but it should work.
> Personally, that is a poor way to run a message submission server. If they
> want security, they should require a username+password from the agent, not
> an FQDN. Most user agents either use the computer NetBIOS name, or machine
They do require username+password + SSL/TLS.
> IP address as the SMTP "HELO/EHLO" value. Somebody in your organization has
> their head in an anatomically impossible position.
It is always those people who get high in the corporate ladder, I am
afraid.
Thanks,
Federico
Federico Cozzi
> Consult your IT department or Sys Admin.
No, as someone else said, this is a client problem (my problem), not a
network problem.
Unless you are suggesting that the mail server admin re-configures the
mail server and drops this (silly) requirement.
Bye,
Federico
Federico Cozzi
> I believe it is your ISP that determines what gets placed in the Headers
> in an e-mail envelope, not your client. His software determines what's
> send in the HELO/EHLO streams.
No, it is the client software.
I am using Microsoft Outlook Express / Live Mail from a client's
corporate network, and I am connecting to my corporate mail server
directly with SMTP on port 25 + SSL/TLS + username&password.
So I get a direct connection (being a SSL/TLS connection, I am sure
there is no man in the middle) from my mail client to my corporate
mail server.
If I use Thunderbird everything works fine.
This is specifically a problem with Microsoft mail clients, or at
least with my poor knowledge on configuring them.
I was hoping there was a (hidden) switch to tell Microsoft Outlook
Express / Live Mail "send FQDN instead of Netbios name".
Thanks,
Federico
Federico Cozzi
> > You would need to re-run the network setup Wizard, and put the FQDN in when
> > it asks you for the computer name; i.e., instead of 'mycomputer', enter,
> > 'mycomputer.example.org'.
> Great idea!
> Sounds gimmicky but it should work.
Doesn't work, unfortunately.
Tried it but Windows complains that dots are not allowed in the
computer name.
Thanks anyway
Bye,
Federico
PA Bear [MS MVP]
PA Bear [MS MVP]
VanguardLH
Look at the headers of the e-mail. Look at the first Received header.
Headers are prepended as they pass through mail hosts so the 1st
Received header is the lowest one (or 1st one when reading upward)
unless a spammer or phisher tried to insert a bogus Received header to
mislead those that try to track back through the Received headers.
You'll probably see something akin to:
Received:
from <hostname> ([<ipaddress>])
by <mailserver> ...
For Microsoft products (Outlook and Outlook Express), the <hostname> is
whatever the user configured as the hostname for their computer. Often
it is just the hostname, not an FQDN. Apparently your particular mail
server doesn't allow just a hostname. That's stupid because the mail
server should be using a set of domain suffix rules to fall through in
finding out to which subdomain a host belongs (it's part of the DNS
setup in the TCP settings on the host for the mail server).
If you send a test e-mail using Thunderbird (which you said works), see
what <hostname> looks like in the 1st Received header. Perhaps it is
providing an FQDN. However, if the user configured only a hostname (no
domain) for the name of their host then Tbird would have to be using the
DNS rules for falling through to append a domain. For example, my
hostname is just "zodiac". That's all Outlook [Express] will use in the
HELO or EHLO commands. I don't have multiple subdomains which are
nested in order to determine which one of my intranet hosts is the
"zodiac" host. If I were in a domain, the TCP settings would specify
some domain suffixes to presume when just a hostname is specified in any
network connections. In my home network, I don't need a list of domain
suffixes, but I do at work. That is because one subdomain might have a
"zodiac" host and another have another "zodiac" host and there must be
some way to distinguish them, and that is with the order of DNS domain
suffixes that are to be used in resolving the hostname to a particular
host.
Go into your TCP settings under its DNS options. Sometimes domain
suffixes are assumed based on which DNS server is used, so if you have
multiple DNS servers listed then their order may be important.
Otherwise, what list of DNS [domain] suffixes do you have in your list?
You might have to specify the order rather than rely on the proper one
being used from the DNS server. My guess is that the server needs to
know WHICH host possibly by the same name comes from which subdomain on
their network. All of these TCP settings should be known by your IT
folks, so ask them on the proper config of your TCP setup.
I suppose you could change your hostname so it includes your [sub]domain
to provide resolution without having to fall through an ordered list of
domain suffixes in trying to uniquely identify your host. Right-click
on the My Computer desktop icon, Properties, Computer Name tab, and
click Change. However, you may end up having to call your IT folks
anyway to get that new ID authorized on their domain. Hopefully you
pick the correct domain or subdomain for your host so you aren't
stepping on someone else's host with the same hostname (which resolves
to the same [sub]domain that you selected).
Peter Foldes
Definitely since 554 5.5.2 = Not a Valid recipient
--
Peter
Please Reply to Newsgroup for the benefit of others
Requests for assistance by email can not and will not be acknowledged.
"N. Miller" <anon...@msnews.aosake.net> wrote in message
news:oku6cqwl...@msnews.aosake.net...
> On Tue, 12 May 2009 17:57:40 -0400, Peter Foldes wrote:
>
>> 554 5.5.2 = Not a Valid recipient
>
> Not what the OP reported:
>
> | Risposta del server: 554 5.5.2 <fcozzinb>: Helo command rejected: need
> | fully-qualified hostname
>
> OP also states that Mozilla Thunderbird will succeed where MS Outlook
> Express fails. Something is FUBAR with his mail server.
VanguardLH
Oops, just noticed you last statement of "The computer is WindowsXP Pro
SP3 and is *not* joined to a Windows domain." That means all or some of
your intranet hosts are within workgroups. There is no domain hierarchy
in a workgroup relationship so how could there be a Fully Qualified
DOMAIN name?
You sure the problem isn't with your SMTP login credentials saved in
your e-mail client? Some SMTP mail hosts require that you not only
specify the username but also include a domain name, as in
<username>@<theirdomain>. That's because they have more than one domain
under which they provide e-mail services. Yahoo.com used to have just
yahoo.com so all you had to enter was <username>. Then Yahoo.com added
ymail.com and rocketmail.com so now the login requires you to specify
under which domain your account is defined, and you now have to use
<username>@yahoo.com or <username>@ymail.com or
<username>@rocketmail.com as your username when logging in. If you are
logging into Windows Live Hotmail services, again you need to specify
the domain in the username, as in <user>@hotmail.com or <user>@live.com.
Just <user> won't tell them under which domain your account is defined.
When you go through the wizard using Tbird, that wizard makes some
guesses as to what are proper usernames based on the domain you specify
for your e-mail provider. For Gmail, Yahoo, and Hotmail, it makes
guesses as to what is probably the correct domain but it may not be
correct. Google has both gmail.com and googlemail.com (and several
others) for domains for their e-mail service. I've already mentioned
different domains for Yahoo and Hotmail. So go check what the Tbird
wizard inserted into the e-mail accounts that it defined and use those
same login credentials in OE and WLM. And make sure the option to
authenticate to the SMTP server is enabled for e-mail accounts defined
in OE and WLM.
VanguardLH
> VanguardLH wrote:
>>
>> Federico Cozzi wrote:
>>>
>>> I'd like to use either Outlook Express or Windows Live Mail (this
>>> question applies to both) but I keep getting the same error when
>>> sending email:
>>>
>>> Risposta del server: 554 5.5.2 <fcozzinb>: Helo command rejected: need
>>> fully-qualified hostname
>>>
>>> What happens is that my company SMTP server requires a FQDN at the
>>> HELO/EHLO greeting when I connect to the server from outside our
>>> corporate network (sounds reasonable), yet my Outlook Express /
>>> Windows Live Mail sends my Netbios name ("fcozzinb") instead of my
>>> FQDN.
>>>
>>> I have tried setting a domain in my network tab but without success.
>>> Can someone please provide the exact steps?
>>> The computer is WindowsXP Pro SP3 and is *not* joined to a Windows
>>> domain.
>>>
>>> Thanks,
>>> Federico
>
> Oops, just noticed you last statement of "The computer is WindowsXP Pro
> SP3 and is *not* joined to a Windows domain." That means all or some of
> your intranet hosts are within workgroups. There is no domain hierarchy
> in a workgroup relationship so how could there be a Fully Qualified
> DOMAIN name?
And on a like note regarding workgroups (which aren't domains), did you
make sure your SMTP mail host is within the *same* workgroup as the
hosts that want to use it?
http://en.wikipedia.org/wiki/Workgroup_(Computer_networking)
Just HOW are you remotely connecting to your company's network? You
mention connecting to the mail server (on your company's network) but
from "outside our corporate network". Just how is that done? Using
VPN? If so, you sure that your host is not connecting (logging into) to
the domain at your company (over the VPN)? When connecting over the
VPN, you'll need to login into their domain which leads back to my prior
reply about TCP configuration.
Does your company actually allow connections from external hosts? Most
don't because there is a security risk and also more easily allows DOS
attacks which prevents outside employees from using the mail host. Most
companies don't want their mail hosts exposed to outsiders. As such,
they might have some imposed security restrictions so talk them about
those.
Federico Cozzi
> Whatever & wherever the problem is, it lies somewhere outside of OE.
Well,
Thunderbird works and Outlook Express doesn't, so I am led to believe
that the problem lies within Outlook Express, or at least my (mis)
configuration of it.
Bye,
Federico
Federico Cozzi
> What do you mean by "Live Mail"?
http://en.wikipedia.org/wiki/Windows_Live_Mail
It's the latest mail client from Microsoft which supercedes Outlook
Express.
Bye,
Federico
Federico Cozzi
> >Something is FUBAR with his mail server
>
> Definitely since 554 5.5.2 = Not a Valid recipient
We agree that requiring a FQDN from a mail client is a silly
requirement, however this is how our corporate mail server is
configured and I can't change it.
Anyway it works with Tbird, so I would like to make it work with
Outlook Express / Live Mail (which I prefer)
Bye,
Federico
Federico Cozzi
> And on a like note regarding workgroups (which aren't domains), did you
> make sure your SMTP mail host is within the *same* workgroup as the
> hosts that want to use it?
I am sure it is *not*.
Why should it be? SMTP is completely independent from Windows
workgroups/domains.
Our mail server runs on a Unix box and relies exclusively on Internet
technologies (SMTP, DNS, SSL etc.)
> Just HOW are you remotely connecting to your company's network? You
I am using a rather obscure thing called "the internet".
I plug my laptop at a client's corporate network and get assigned an
IP address with DHCP.
I then start Outlook Express, write an email and send it. Ops, I get
the "need FQDN" error.
If I start Thunderbird, everything works fine.
My mail account is configured, both in Outlook Express and
Thunderbird, to send mail through my corporate SMTP mail server using
port 25 and TLS. It also asks for a username and password.
It works fine with Thunderbird, so I guess that I can reach our
corporate mail server from the client's network.
> Does your company actually allow connections from external hosts? Most
Yes they do.
However they require TLS and username+password, which I set up (both
in Thunderbird and Outlook Express). Thunderbird works, Outlook
Express doesn't.
However, since the SMTP connection is secured with TLS, I can not fire
a network sniffer so I don't know what Outlook Express is sending to
our mail server.
> they might have some imposed security restrictions so talk them about
> those.
Yes, their security restrictions are:
1.TLS
2.username+password
3.HELO requires a FQDN
The point is that I don't know how to satisfy requirement no. 3 with
Outlook Express.
Bye,
Federico
Federico Cozzi
> Oops, just noticed you last statement of "The computer is WindowsXP Pro
> SP3 and is *not* joined to a Windows domain." That means all or some of
> your intranet hosts are within workgroups. There is no domain hierarchy
> in a workgroup relationship so how could there be a Fully Qualified
> DOMAIN name?
Windows domains are completely independent from DNS domains, otherwise
no Unix host would have a "domain".
My laptop is configured with "fcozzinb" as hostname and "comdata.it"
as domain name (System properties->Computer name->Change->Other-
>Primary DNS suffix)
Even if it were joined to a Windows domain, the domain name would be
"comdata", not "comdata.it" so I wouldn't get a FQDN anyway.
> You sure the problem isn't with your SMTP login credentials saved in
> your e-mail client? Some SMTP mail hosts require that you not only
Yes, because the same mail client (Outlook Express) with the same
settings works fine when I use it within our corporate network. In
those cases, our corporate SMTP mail server does not ask for a FQDN
and everything works fine.
I get the problem only when I connect to our corporate SMTP mail
server from outside our corporate network.
Bye,
Federico
Federico Cozzi
> Look at the headers of the e-mail. Look at the first Received header.
Very good idea!
Here is what Thunderbird sends:
Received: from [10.130.216.45] (unknown [151.96.3.241])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by spl-mail09a.comdata.it (Postfix) with ESMTPSA id 2827E5A
for <xxxx...@gmail.com>; Thu, 14 May 2009 12:24:24 +0200 (CEST)
Here 10.130.216.45 is my current IP address at the client's corporate
network (private IP address) and 151.96.3.241 is (what I presume is)
its public counterpart (the client's corporate network is surely
behind a NAT).
The mail was sent with ESMTP on port 25 using TLS + username&password.
Our corporate mail server is Postfix, which apparently is configured
to ask for a FQDN for messages coming from outside our corporate
network.
I can't get the same headers using Outlook Express / Live Mail since
the message is rejected. However I guess that Outlook Express / Live
Mail send my Netbios name (fcozzinb) which is not recognized as a
valid FQDN and therefore our mail server rejects the message.
I would like Outlook Express / Live Mail to send either my FQDN
(fcozzinb.comdata.it) or my IP address, as Tbird does.
Thanks,
Federico
N. Miller
> >Something is FUBAR with his mail server
> Definitely since 554 5.5.2 = Not a Valid recipient
Stop reading from the RFC. The operator of that mail server has created a
custom error message which has nothing to do with the validity of the
recipient. The cite is:
554 5.5.2 <fcozzinb>: Helo command rejected: need fully-qualified hostname
What part of "Need FQDN" in "HELO command" do you not understand?
N. Miller
> If you send a test e-mail using Thunderbird (which you said works), see
> what <hostname> looks like in the 1st Received header.
A few days back I posted such a comparison:
| Received: from KOZUE (adsl-68-125-48-236.dsl.pltn13.pacbell.net [68.125.48.236])
| (authenticated bits=0)
| by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n1977Qpl029365
| for <******@hotmail.com>; Mon, 9 Feb 2009 01:07:26 -0600
| X-Mailer: Microsoft Outlook Express 6.00.2900.5512
Which is exactly as you describe. And:
| Received: from [192.168.102.31] ([68.127.106.82]) by BLU0-SMTP28.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668);
| Tue, 21 Apr 2009 18:56:18 -0700
| User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
The difference being the NetBIOS name used by Outlook Express and the local
IP address used by Thunderbird.
PA Bear [MS MVP]
PA Bear [MS MVP]
TBird (unless it's set up as a POP3 account).
VanguardLH
> On 14 Mag, 04:09, VanguardLH <V...@nguard.LH> wrote:
>> And on a like note regarding workgroups (which aren't domains), did you
>> make sure your SMTP mail host is within the *same* workgroup as the
>> hosts that want to use it?
>
> I am sure it is *not*.
> Why should it be? SMTP is completely independent from Windows
> workgroups/domains.
> Our mail server runs on a Unix box and relies exclusively on Internet
> technologies (SMTP, DNS, SSL etc.)
SMTP is just an *e-mail* protocol, not a networking protocol. If you
want to allow hosts to access each other in a *workgroup* then they need
to be in the same workgroup. The point is to get the *hosts* networked
together. It could very well be that Thunderbird is going above and
beyond what is expected of a normal e-mail client in somehow adding a
domain but the question is just from WHERE Tbird is going to get a
domain name when the host is in a workgroup. (See below. Could be
Tbird isn't adding a hostname and just an IP address. No DNS resolution
is then needed by the SMTP mail host.)
>> Just HOW are you remotely connecting to your company's network? �You
>
> I am using a rather obscure thing called "the internet".
Which says absolutely nothing about HOW you are connecting your client
host to the mail server host. Could be you are using HTTP with OWA
(Outlook Web Access) which is a web server gateway to the whatever host
on which Exchange is running. Could be you are using a VPN which
tunnels through the mesh network on Internet to keep its traffic secure
and makes you appear to be connecting directly onto the corporate
network (but often within a more secure zone on their network for those
externally-connected hosts). Could be you were using some variant of
VNC to remoted connect your home PC to a workstation at work and then
manipulating OE on the workstation to do e-mails (OE on the workstation
is doing the work and you are just *seeing* it in the copy of its screen
display shown on your home PC). Could be your company allows direct
connects to their SMTP server by outsiders which means they risk
security breaches without a DMZ or other boundary protection of their
network. Hard to tell since you didn't mention HOW you connect from
outside to your company's network.
> I plug my laptop at a client's corporate network and get assigned an
> IP address with DHCP.
> I then start Outlook Express, write an email and send it.
That was supposed to describe HOW you "connect to the server from
outside our corporate network"? Uffda. That makes it now sound like
you are not outside but inside the company network. Are the 2 networks
involved here? One is a "branch office" network and the other is a
separate corporate network where the SMTP mail host is located? If so,
how are those 2 networks linked, or are they linked at all? Maybe
there's no security and, as you say, all traffic between the branch and
corporation are thrown out into the cloud with the hope that SSL will
secure their company's data. Is e-mail the only connection between the
branch and corporate networks?
> Ops, I get
> the "need FQDN" error.
> If I start Thunderbird, everything works fine.
YOU said that you were *not* logging onto a domain, AND that all the
hosts (workstations and servers) are running in workgroups. So where
could the "domain" come into play when there isn't one?
You could enable the troubleshooting logging in both e-mail clients so
see what each one sends during a mail session. If multiple e-mail
accounts are defined in OE, I'd suggest disabling all but one account
and poll only that account. That way, you don't get a mix of different
accounts and their log output into the same logfile. You could then see
what was the difference between the USER, PASS, HELO/EHLO, and other
commands sent by the e-mail client.
> My mail account is configured, both in Outlook Express and
> Thunderbird, to send mail through my corporate SMTP mail server using
> port 25 and TLS. It also asks for a username and password.
>
> It works fine with Thunderbird, so I guess that I can reach our
> corporate mail server from the client's network.
Okay, now it is starting to look like there are 2 networks. "Corporate
mail server" means the SMTP mail host is on the corporate network but
"client's network" is a separate network, like at some branch office.
How does this branch network connect to the corporate network? My guess
is that this "branch office" or client network uses workgroups for their
hosts that all go through a NAT router to then somehow connect (how is
not described) to their corporate network. I would have thought that
the branch office would have a secure channel to the corporate network
rather than use SSL to toss their traffic out through Intranet's mesh
network. Apparently this NAT router simply goes to whomever they pay
for an ISP at that location and SMTP connects to the corporate network
go across the cloud and are secured only by SSL.
By the way: SSL encrypts the login credentials. It does NOT encrypt
the e-mails. Does your client also employ email certificates to
encrypt their e-mails? While they are protecting their logins, do
they really not care about someone getting at the content of their
e-mails? E-mail clients support e-mail certs because SSL does not
encrypt the messages, only the logins. Seems this "company" is rather
callous regarding their security.
I'm starting to think that Thunderbird doesn't even put the hostname
(with no domain because there isn't one) in the HELO command. It may
just put in an IP address. However, that would be the intranet IP
address assigned by the DHCP server in the the client's router (or
whatever acts as their DHCP server). Of course, an IP address like
192.168.1.102 is local in the client's network and is not routable (so
it isn't part of any subnet on the corporate network - but it could
definitely duplicate intranet IP addresses used in the corporate
network). But if a hostname isn't specified and just an IP address,
perhaps the SMTP mail server doesn't care about the non-routable IP
address. If just an IP address is given in the name field of the HELO
command then the server doesn't have to do any domain name resolution to
find the host (but then it probably is pointing at the wrong host). Of
course, when the server is beyond the NAT, both the non-routable IP
address and non-routable IP name (hostname) are meaningless to the mail
server. I suppose the SMTP mail server doesn't care since it is
tracking usage and resources based on accounts, not resolving to a host.
>
>> Does your company actually allow connections from external hosts? �Most
>
> Yes they do.
> However they require TLS and username+password, which I set up (both
> in Thunderbird and Outlook Express). Thunderbird works, Outlook
> Express doesn't.
>
> However, since the SMTP connection is secured with TLS, I can not fire
> a network sniffer so I don't know what Outlook Express is sending to
> our mail server.
You should still be able to review the troubleshooting logfile for OE
and compare to the logfile for Tbird.
>> they might have some imposed security restrictions so talk them about
>> those.
>
> Yes, their security restrictions are:
> 1.TLS
> 2.username+password
> 3.HELO requires a FQDN
>
> The point is that I don't know how to satisfy requirement no. 3 with
> Outlook Express.
Alas, hostnames cannot include domains. The TCP config defines the
fall-through to the domain name (if not provided by the DNS server) but
then that doesn't apply in workgroups. Since there is no VPN between
the branch and corporate networks, the branch cannot join the corporate
domain.
I'm not sure how you are going to get around this unless the SMTP admins
disable the option to require FQDNs. Whatever the e-mail clients use on
the branch hosts is meaningless to the SMTP server. If a hostname is
given in HELO, it's a workgroup host name, not a domain name so there
will be no valid host name resolution. Even the local IP address for
the branch host is meaningless to the SMTP server but, at least, that
would elminate the SMTP server from thinking it had to do any name
resolution (but then that IP address isn't valid on the corporate
network where the SMTP server is located).
Some mail admin doesn't have their head screwed on right. Since
external connects from ANY host from any location (and not just from
their branch office) is allowed to their SMTP server, that server won't
be able to resolve the IP addresses or IP names, anyway. They will be
non-routable IP addresses, like 192.168.x.x, or workgroup hostnames
which obviously have not joined the server's domain or a trusted domain.
If they aren't going to require domains at their branches that are
trusted but still allow cloud connects to their SMTP server, requiring
an FQDN is just stupid. Anything speicified in the HELO/EHLO commands
is meaningless to the server.
Does this mail admin wear a Disney character hat with long floppy ears
and sound like Goofy? If they don't want to permit connects from
Outlook Express whose support died back in 2002 and its dev group
disbanded in 2006 (i.e., it is a long-dead e-mail client) then they
should require their branch users to use a newer e-mail client. From
what I read at RFC 5321 (http://www.rfc-editor.org/rfc/rfc5321.txt),
section 4.1.1.1:
In situations in which the SMTP client system does not have a
meaningful domain name (e.g., when its address is dynamically
allocated and no reverse mapping record is available), the client
SHOULD send an address literal (see Section 4.1.3).
Section 4.1.3 says:
Sometimes a host is not known to the domain name system and
communication (and, in particular, communication to report and repair
the error) is blocked. To bypass this barrier, a special literal form
of the address is allowed as an alternative to a domain name.
What they are saying is that when an FQDN is not available -- which it
will NOT be in the client's branch network setup where they use
workgroups instead of a domain -- then a dotted IP address should be
used.
5321 was ratified in Oct 2008. It typically takes around 6 years for
e-mail clients to catch up to become compliant. Catchup will NEVER
happen for a dead and unsupported product. OE is not going to change.
It cannot change. It present the NetBIOS hostname in the HELO command.
RFC 2821 (that 5321 obsoleted) was ratified in 1998. It also had the
same requirement of using an IP address if an FQDN was not available.
Remember the 6-year lag before clients are, in general, compliant with
new RFCs. That means OE was a dead product before it might've gotten
around to adopting anything specified in RFC 2821. Then remember when
Thunderbird was being developed (which was after these RFCs or during or
after their drafts were available).
So the choices are:
- Your clients at the branch network that uses workgroups instead of
domains will have to cease using outdated e-mail clients and move to
those that comply with RFC 5321 which is being enforced by their mail
server. Windows Live Mail will probably be most familiar in its UI to
these branch office users (although there are some differences, like
e-mail accounts shown separately instead of aggregated into one
Inbox). They need to stop using an e-mail client that went dead over
7 years ago.
- Your SMTP admin realizes that any IP address specified in the e-mail
client's HELO command is absolutely meaningless to the SMTP server.
Since they are not tunneling their branch office into the corporate
network to let those users join the domain, and because they are
permitting external connects by ANYONE outside their network (as long
as they provide valid login credentials) from ANYWHERE then enforcing
an FQDN is stupid and this security option should be disabled in the
mail server. Requiring an FQDN makes no sense in the setup that you
described.
From what I've read through Googling around, Thunderbird inserts an IP
address, not a hostname. It doesn't even try to resolve the hostname
(because it doesn't need to when inserting an IP address). The problem
in not even trying to provide a resolved name is that some spam filters
will tag these e-mails. There is no reverse lookup on the IP address to
get at the hostname. Maybe they fixed it but way too long for me to
read it all; see https://bugzilla.mozilla.org/show_bug.cgi?id=279525.
I can't see which comment is actually the "fix" for its status to change
to FIXED. They have a sh*tload of comments but no parallel code change
list to show how they fixed it, at what point in the comments those
changes were made, or in what version the changes showed up (unless
"fixed1.8.1" means the product version that the fix got inserted and not
some component's version, like a library).
So I think we found the source of the problem: OE (a long-dead product)
inserts the NetBIOS hostname because it doesn't have anything else to
insert and Thunderbird inserts an IP address (even when a resolvable
hostname might be available), and your SMTP mail server only triggers
its security block on IP names although the IP addresses are just as
meaningless to it.
VanguardLH
> On May 14, 3:33�am, VanguardLH <V...@nguard.LH> wrote:
>> Look at the headers of the e-mail. �Look at the first Received header.
>
> Very good idea!
>
> Here is what Thunderbird sends:
>
> Received: from [10.130.216.45] (unknown [151.96.3.241])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by spl-mail09a.comdata.it (Postfix) with ESMTPSA id 2827E5A
> for <xxxx...@gmail.com>; Thu, 14 May 2009 12:24:24 +0200 (CEST)
See my other reply. As you see here, Thunderbird does NOT use the
hostname even if one could be resolved from DNS. It inserts the IP
address. This actually might not be RFC compliant since the e-mail
client is supposed to insert an FQDN if one is available. OE is too old
(and long dead) to be RFC compliant as noted in my other reply about RFC
5821 and using an IP address if an FQDN cannot be obtained. OE existed
long before this RFC (and 2831 that it obsoleted) were ratified but it
died soon after so there will never be a change in OE to fix your
problem.
I mention what possible solutions are available in my other rather
lengthy reply.
Federico Cozzi
> OE is part & parcel of your OS. TBird isn't.
This may be true, but how does this piece of info helps towards the
solution of my problem?
Bye,
Federico
Federico Cozzi
> PS: I'd very much doubt that you're accessing your MSN/Hotmail account in
> TBird (unless it's set up as a POP3 account).
I don't have a MSN/Hotmail account. Why should I access it with Tbird?
I want to access my corporate email account (IMAP/SMTP) with Outlook
Express / Live Mail.
TBird works, Outlook Express doesn't, at least on my PC and with my
configuration.
I am more than willing to change its configuration to make it work
with my corporate mail server.
What should I do?
Bye,
Federico
Federico Cozzi
> - Your clients at the branch network that uses workgroups instead of
> domains will have to cease using outdated e-mail clients and move to
> those that comply with RFC 5321 which is being enforced by their mail
> server. Windows Live Mail will probably be most familiar in its UI to
> these branch office users (although there are some differences, like
> e-mail accounts shown separately instead of aggregated into one
> Inbox). They need to stop using an e-mail client that went dead over
> 7 years ago.
I get the same problem with Windows Live Mail.
How should I configure it to make it work?
Thanks,
Federico
Federico Cozzi
> The difference being the NetBIOS name used by Outlook Express and the local
> IP address used by Thunderbird.
My whole question is this:
Is there a way to change Outlook Express, or Windows Live Mail,
behaviour?
Thanks,
Federico
N. Miller
Not that I am aware of. As I said, when I suggested trying an FQDN as a
computer name, I had never done that with MSOE. You report that MSOE doesn't
want to see dots in the computer name: That precludes typing in an IP
address, as well as an FQDN, as a local machine name.
Unless pulling the machine name is something MSOE does a registry key, which
can be edited, there is nothing you can do. If this behavior is coded in the
executable file, or one of the linked libraries, an edit would be difficult
to accomplish; may well be impossible.
Thunderbird works, why not just use it? I prefer a mail program called,
Pegasus Mail, which allows me to set up a custom "HELO" string. I've used
both, 'pacbell.net', and 'excite.com' in sent email.
N. Miller
> We agree that requiring a FQDN from a mail client is a silly
> requirement, however this is how our corporate mail server is
> configured and I can't change it.
> Anyway it works with Tbird, so I would like to make it work with
> Outlook Express / Live Mail (which I prefer)
I don't know how to make it work with MSOE, or WLM. Unless somebody familiar
with registry information for the MSFT applications can specify a registry
key which controls the content of the HELO command (and there may not be
such a key, that part of the SMTP transaction may be hard coded in the
executable, or one of the libraries), what you see is what you get.
N. Miller
> See my other reply. As you see here, Thunderbird does NOT use the
> hostname even if one could be resolved from DNS. It inserts the IP
> address. This actually might not be RFC compliant since the e-mail
> client is supposed to insert an FQDN if one is available. OE is too old
> (and long dead) to be RFC compliant as noted in my other reply about RFC
> 5821 and using an IP address if an FQDN cannot be obtained. OE existed
> long before this RFC (and 2831 that it obsoleted) were ratified but it
> died soon after so there will never be a change in OE to fix your
> problem.
SMTP is about "mail transfer", not "message submission". Email clients do
not perform "mail transfer", only "message submission". It is not realistic
to expect a "message submission" agent to sent an FQDN in the "HELO/EHLO"
command; how would the mail client know which FQDN to use? If I send email
from 'us...@example.org', but I use 'smtp.test.invalid' to send, the
'example.org' FQDN would be wrong for that server!
In any case, before RFC 2821 was RFC 821; ratified August, 1982.
Ottmar Freudenberger
> Is there a way to change Outlook Express, or Windows Live Mail,
> behaviour?
There's a registry "hack" to get the *local* IP address into the
[HELO] at leat for OE. This "may" trigger rigerous configured Spam
filters. So you're warned:
HKEY_CURRENT_USER\Identities\{Your-CLSID}\Software\Microsoft\Outlook Express\5.0
and a DWORD value named "UseIPForSMTPHELO" and the input "1"
would do it for OE.
Bye,
Freudi