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?
So when a Domino server sends an email to an outside SMTP server, what defines which name it provides as its own connecting hostname?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
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
@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.
> 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.
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.
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.
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.
Here's a link from microsoft admitting that they can not send EHLO correctly:
http://support.microsoft.com/kb/957497
http://support.microsoft.com/kb/957497
@fgrushevsky
> It is only recommended.
Recomended but not largely practiced !
> It is only recommended.
Recomended but not largely practiced !
ASKER
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.
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.
ASKER
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?
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?
>>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-ADD