Which setting in Domino Server 7 defines its connecting hostname when sending email to the world?

I'm prepping for an ISP migration and I wanted to setup the reverse DNS entries.  When I went to do that I found an inconsistency in how they were setup for the 2 different mail servers.  On one server, the servername as defined in the FQDN setting and the PTR record match, which is what I would expect.  On the other server, the PTR record doesn't match any FQDN I can find anywhere in the configuration.  (I do not receive any SMTP 550 messages, so somehow we're still OK as far as servers that check the reverse DNS entry)

So when a Domino server sends an email to an outside SMTP server, what defines which name it provides as its own connecting hostname?
LVL 8
ITDharamAsked:
Who is Participating?
 
fgrushevskyCommented:
It is "Fully qualified Internet host name" on the basic tab of the server document
0
 
Kerem ERSOYPresidentCommented:
Hi,

These are all governed by DNS in that:
- When an SMTP host (domino is an SMTP host when delivering to some other SMTP server) connets to another to send e-mail, the receivng server gets the IP adddress from the connection and queries it to resolve to a name. It might succeed or not. If not it can be isntructed to close the cunnestion with a 4.7.1 Relaying deined error or a 4.5.0 temprary error through its configuration settings.

If it resolves the name then it queries the DNS with the obtained FQDN from the reverse query. After it gets the name depending on its configuration it might reject the mail if DNS and Reverse DNS entries don't much. Then again it might not. Instead it might be configured to requery the DNS for an SPF TXT record. An SPF record is a test record and it returns configured E-mail forwarders for the domain it can whether be a catch-all record saying then any server is permitted t forward mail on its behalf or lists some  servers which are authorized to deliver mail on the domains behalf. After this query , even if Reverse and forward DNS queries disagree the mail could be accepted.

As you see this is all DNS related. There are also several problems with reverse lookup zones:
- First of all reverse zones are not as flexible as forward zones which could be easily changed on registrar's page. They are assigned to ISP's and Reverse DNS could be set-up only on the intended server and contain full zone data only. Until recently it was a problem nad only resolved with some recent RFC's allowed for subnet delegation in Reverse DNS. For this reason they must be maintained mnually by ISP's and much of them don't care about it at all.  I guess this is the case for your second DNS. I'll suggest you to both insist on to get it corrected by the ISP and also add an SPF record to your zone to prevent any further problems.

For further reference:
On SPF Records: http://www.openspf.org/
On Subnetting the Reverse DNS (classless in-addr.arpa delegation) http://www.faqs.org/rfcs/rfc2317.html
On Reverse DNS lookup: http://en.wikipedia.org/wiki/Reverse_DNS_lookup
On Reverse DNS Delegation practices: http://www.zytrax.com/books/dns/ch9/reverse.html

I hope this helps.

Cheers,
K.


0
 
Kerem ERSOYPresidentCommented:
@fgrushevsky:
>>It is "Fully qualified Internet host name" on the basic tab of the server document

The initial question specified that:

> On the other server, the PTR record doesn't match any FQDN I can find anywhere in the configuration.

So this is not an issue with Server Forward DNS that could be set-up from the Domino. IT is rather the Reverse DNS could not be properly configured by ISP.

If they can not confgure it you'd either ask them to redirect the traffic to your DNS as per RFC 2317
or you might have a temporary solution in that instead of entering ptr records like..
23.12       IN PTR dominomail.company.com

They'd rather enter such that your DNS servers could be used instead of theirs.  ( Of course it requires full acces to your corporate DNS's and some good sys admins who won't gaze at you when you as hm/her to define a new reverse dNS zone which as delegated from your ISP.)

64/16         IN  NS  ns1.example.com.

OR

65              IN  CNAME   65.64/27.23.168.192.IN-ADDR.ARPA.


0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
fgrushevskyCommented:
K

I am not particulary agree with your statements.

"When an SMTP host (domino is an SMTP host when delivering to some other SMTP server) connets to another to send e-mail, the receivng server gets the IP adddress from the connection and queries it to resolve to a name.  If not it can be isntructed to close the connestion " - This is correct

After that there are several other checks that might happenedon the receiving server configuration

1. The receiving server can check if FQDN obtained from the reverse query is matching server name from SMTP HELO (or EHLO) command.  If FQDNs don't match, the receiving server might be instructed to close the connection.  In my expirience, this particular check is quite popular on mail servers in Germany. IMHO, the original question was about server name presented in HELO (EHLO) command and it is set in "Fully qualified Internet host name" on the basic tab of the server document

2. There are other servers that would check that only domain part of the FQDN obtained from the reverse query is matching server name from SMTP HELO (or EHLO) command.

3. The receiving server can query DNS with FQDN received from reverse query to check if returned IP will match connecting server IP.

so as you can see not everything is DNS driven, but sending server FQDN from HELO command is verified as well

As for SPF records, they are verified  (if verified) on the next step after smtp MAIL FROM command, after all previous checks are succesful






0
 
Kerem ERSOYPresidentCommented:
@fgrushevsky:

> 1. The receiving server can check if FQDN obtained from the reverse query is matching server name
> from SMTP HELO (or EHLO) command.  If FQDNs don't match, the receiving server might be instructed > to close the connection.  In my expirience, this particular check is quite popular on mail servers in
> Germany.  IMHO, the original question was about server name presented in HELO (EHLO) command
> and it is set in "Fully qualified Internet host name" on the basic tab of the server document

I am also aware that EHLO checks are possible but when I've tried the EHLO FQDN checks. I had to quit it in 2 days. In fact nearly no Exchange servers return the correct FQDN!. So enabling EHLO checks would easily render you without any mail from at least Exchange servers! Furthermore there are servers located in intranets that return their internal domains automatically in EHLO strings. So it is not possible to apply practically and  being a consultant for large enterprises for the last 15 years I know no company that could successfully enable EHLO checks as the RCF suggests. I am currently rejecting only if EHLO string specifies my name or specify localhost. In this case I'm rejecting them using a permanent error saying "You are not me!". So this is why I've omitted to talk about EHLO checks. Oh I've just remember all Microsoft software implements SMTP from as obsolete RFC which does not cover full EHLO syntax. I've even complained about this problem to Microsoft!

> 2. There are other servers that would check that only domain part of the FQDN obtained from the
> reverse query is matching server name from SMTP HELO (or EHLO) command.

> 3. The receiving server can query DNS with FQDN received from reverse query to check if returned > IP will match connecting server IP.

My article covers that too. I told it may or might not reject and if it does not it might query SPF record and
then decide to reject or not.

> so as you can see not everything is DNS driven, but sending server FQDN from HELO command is
> verified as well

Even the domain specified in HELO requires DNS validation to determine if it is valid.

> As for SPF records, they are verified  (if verified) on the next step after smtp MAIL FROM command, > after all previous checks are succesful

I'm sorry but this is incorrect too. Here's the excerpt form the RFC-4408 wihch specifies:

   This document defines a protocol by which domain owners may authorize
   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
   Compliant domain holders publish Sender Policy Framework (SPF)
   records specifying which hosts are permitted to use their names, and
   compliant mail receivers use the published SPF records to test the
   authorization of sending Mail Transfer Agents (MTAs) using a given
   "HELO" or "MAIL FROM" identity during a mail transaction.

So as you see SPF is active during HELO checks too. Plaese check the full document here:

http://www.ietf.org/rfc/rfc4408.txt

In fact the whole idea behinf SPF checking is to find a credible way since they already know that HELO has never been used as its planned due to bad implementation processes and it is not easy to re-enforce them.

Cheers,
K.
0
 
Kerem ERSOYPresidentCommented:
If EHLO checks could be inforced  we'd have lesser SPAM mails. Since most of the mass mailing programs around using invailid text such as "ommo.net" / "ZLONBD" /  "kdybvgyjf" and still they can deliver billions and biliions of emials everyday.
0
 
fgrushevskyCommented:
It is possible and quite easy to configure Exchange to return any given FQDN.  As I mentioned before, I've seen a fair share of the servers checking HELO/EHLO FQDN (mostly in Germany).  

RFC 4408 says that
"It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
   identity, but also separately check the "HELO" identity by applying
   the check_host() function (Section 4) to the "HELO" identity as the
   <sender>."
It is only recommended.
0
 
Kerem ERSOYPresidentCommented:
Here's a link from microsoft admitting that they can not send EHLO correctly:
http://support.microsoft.com/kb/957497
0
 
Kerem ERSOYPresidentCommented:
@fgrushevsky

> It is only recommended.

Recomended but not largely practiced !
0
 
ITDharamAuthor Commented:
Some good info here guys.  Your exchange is enlightening.  So here is my problem, IT SEEMS TO WORK FINE!  Why is this a problem, because based on what I'm seeing, I should be getting bounces.  I have over 600 users here, and this particular setup has been in place for a couple years, and I don't get SMTP 550 returns.

I'll spell out the naming scheme here, and maybe something is being missed.  I'm changing the company name to make it interesting.

Local server name:  Alpha.company.local
FQDN in Domino Basics:  Alpha.company.com
FWD DNS Entries:  mail.company.com   Alpha.company.com, and  Alpha.company2.com
Reverse DNS Entry:  Bravo.company.com

Seeing this, would you expect me to be getting bounces?  My users email lots of people, including AOL users, and that can be a pain.
 
0
 
ITDharamAuthor Commented:
I've done a little more reading on this, and I've basically come up with this.  Of the many different steps you can take to block spam, two of them are 1.) Forward DNS lookups (HELO Lookup) and 2.) Reverse DNS lookups

These are two different processes, which can be enabled individually, and they do not 'cross check'.

This explains why my forward and reverse entries are different, but still acceptable.

Is this contrary to what you know?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.