RE: [Exim] rejecting based on HELO

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Kevin Reed
Date:  
À: 'Suresh Ramasubramanian', exim-users
Sujet: RE: [Exim] rejecting based on HELO
Suresh Ramasubramanian
> At 09:31 AM 9/5/2003, Shane Wegner wrote:
> >On Thu, Sep 04, 2003 at 09:36:00AM +0100, gARetH baBB wrote:
> > > I also require at least one dot, there have been several rules
> > > posted over the past few weeks - unqualified HELOs I regard as
> > > invalid.
> >
> >This is a bit offtopic but I just input a rule to do
> >something similar and I have this MS-windows host using Outlook XP
> >which is heloing with its hostname (centauri) rather than its fully
> >qualified domain name (centauri.localnet.cm.nu). Is there a way to
> >tell outlook about its fqdn that anyone knows of?
>
>
> Set the DNS domain (in the network settings) ... the windows
> equivalent of "domain cm.nu" in resolv.conf


I'm not sure that makes a lot of sense.

I doubt that his workstation is acting as a mail server to an outside mail
server. It looks like his mail arrives from a server which uses a HELO of
continuum.cm.nu. So he is only talking to his own local server for delivery
of mail. Why would it care if he had a proper HELO or not. So having him
set his FQDN to be centauri.cm.nu would have no meaning would it, especially
if internally it were known as centauri.localnet.cm.nu.

For example, all of my workstations at home are on a LAN. Internally, they
are identified in a domain called home.kev which is obviously not routable
outside my LAN. I don't see much point in making my windows box say it is
spider.home.kev when that means nothing outside. Now this particular box is
connected to Cox.net. It talks to their mail server for email. Calling my
windows box spider.cox.net would not be any more proper since it is still
not a valid FQDN. The only really valid hostname would be the one assigned
to the IP that my connection currently uses and that changes from time to
time.

There isn't a lot of point making all the workstations and home that are on
the same connection be ipxx-x-xx-xx.ph.ph.cox.net either since it can change
and then would actually be pointing to someone different. Mail is never
going to be routed that way anyways.

Now if my windows box were to start acting as a mail server, that might be
different since then it would need to have a FQDN to respond to. But for a
workstation that uses smtp to a smart relay and pop back, I don't see the
point.

The same thing goes for at work where we have thousands of windows boxes,
everything from NT Win2K and XP. None of those are addressible outside on
the Internet, only their user email address is and obviously goes to my mail
server for proper delivery to them. They each have a unique hostname inside
the net, but that means nothing outside the net. As a user to the outside
world I am only known as username@???.

As for mail arriving from my workstation to your mail server, that should be
via a real server, not my workstation so the HELO should be proper. Cox
does use a valid HELO... Nice to see them do something right. :-)

Enforcing FQDN for a local LAN box talking to its own mail server doesn't
seem to make much sense.