Mercury Suggestions
MercuryE SMTP Client Not Using Host Table for MX Records

[quote user="rshouts"] I resolved the problem by creating in our internal DNS server a forward lookup zone for the domain in the other mail server and added all of the A and MX records with internal addresses.  Mercury now sends directly to the other mail server via the internal network.[/quote]

Interesting solution, & I agree to the wish of either a separate config file, to allow direct host forwarding - would prefer not to mess up the hosts file.

<P>[quote user="rshouts"] I resolved the problem by creating in our internal DNS server a forward lookup zone for the domain in the other mail server and added all of the A and MX records with internal addresses.  Mercury now sends directly to the other mail server via the internal network.[/quote]</P> <P>Interesting solution, & I agree to the wish of either a separate config file, to allow direct host forwarding - would prefer not to mess up the hosts file.</P>

It appears that the MecuryE SMTP Client bypasses the local host table when resolving the IP address for MX records.  It is only using the IP address from a DNS lookup of the URL obtained from the MX records.

I have two different email servers on my internal network, Mercury and another one.  When a user on a domain on the other server sends an email to a user on a domain on Mercury, the other email server looks up the MX records for the domain, properly resolves the IP address using the host table on the local machine, and then connects to Mercury directly within the internal network.  This is the proper behavior and the email is sent with no problems.

When a user on a domain on Mercury sends an email to a user on a domain on the other server, Mercury looks up the MX records for the domain, resolves the IP address using DNS ( improperly bypassing the host table on the local machine), and then connects to the external address of the spam filter appliance (that sits in front of both Mercury and the other mail server for incoming email originating from the internet) instead of connecting directly to the other mail server via the internal network.  This is improper behavior.

I don't want internal email going through the spam filter, as it is unnecessary, drains resources on the spam filter, and oftentimes gets blocked, quarantined, or tagged as potential spam.

MercuryE needs to honor the local host table.  In fact, anything that uses DNS should check the host table first.  There is currently no setting in the MercuryE configuration dialog concerning this.  I am using Mercury v4.52 (August 21 2007).

<P>It appears that the MecuryE SMTP Client bypasses the local host table when resolving the IP address for MX records.  It is only using the IP address from a DNS lookup of the URL obtained from the MX records.</P> <P>I have two different email servers on my internal network, Mercury and another one.  When a user on a domain on the other server sends an email to a user on a domain on Mercury, the other email server looks up the MX records for the domain, properly resolves the IP address using the host table on the local machine, and then connects to Mercury directly within the internal network.  This is the proper behavior and the email is sent with no problems.</P> <P>When a user on a domain on Mercury sends an email to a user on a domain on the other server, Mercury looks up the MX records for the domain, resolves the IP address using DNS ( improperly bypassing the host table on the local machine), and then connects to the external address of the spam filter appliance (that sits in front of both Mercury and the other mail server for incoming email originating from the internet) instead of connecting directly to the other mail server via the internal network.  This is improper behavior.</P> <P>I don't want internal email going through the spam filter, as it is unnecessary, drains resources on the spam filter, and oftentimes gets blocked, quarantined, or tagged as potential spam.</P> <P>MercuryE needs to honor the local host table.  In fact, anything that uses DNS should check the host table first.  There is currently no setting in the MercuryE configuration dialog concerning this.  I am using Mercury v4.52 (August 21 2007).</P>

MercuryE only does UDP(53) queries. If it doesn't find an MX pointer, it uses the A record stored with the domain, if this too fails, the message is undeliverable.

Mercury/32 also lacks domain forwarding, though there are some daemons that can accomplish this by altering the email to: headers. (domain forwarding is on manys wish list, ie mailto:domain.com -> host.domain.com:port) - this is essentially the same thing as using the hosts file instead of proper dns lookup.

<P>MercuryE only does UDP(53) queries. If it doesn't find an MX pointer, it uses the A record stored with the domain, if this too fails, the message is undeliverable.</P> <P>Mercury/32 also lacks domain forwarding, though there are some daemons that can accomplish this by altering the email to: headers. (domain forwarding is on manys wish list, ie <A href="mailto:domain.com">mailto:domain.com</A> -> host.domain.com:port) - this is essentially the same thing as using the hosts file instead of proper dns lookup.</P>

What about the A record not stored in the DNS zone, but in the hosts file?

Previous versions of Mercury were able to deliver the message if a "A record" (note the quotes) was present in the host file. I wonder why this feature was dropped from 4.52.

 

Regards.
<DIV>What about the A record not stored in the DNS zone, but in the hosts file?</DIV> <DIV>Previous versions of Mercury were able to deliver the message if a "A record" (note the quotes) was present in the host file. I wonder why this feature was dropped from 4.52. </DIV> <DIV> </DIV> <DIV>Regards.</DIV>

Don't think it was dropped, I presumed there was a proper DNS zone - have actually never tested scrapping dns lookup. But as far as I know, it is windows that does this lookup, the dns client looks at the hosts file, then does udp(53) lookup  - not Mercury itself, but this is dependent on what dns call is being used from mercury - you can programmatically call dns like: DNS_QUERY_NO_HOSTS_FILE - but I don't know which windows call David uses. There are also angry voices raised that MS sabotaged the dns hosts lookup after the WGA was introduced (f.ex. at securityfocus.com) - but - as I said, I haven't tested it in a real world test.

Don't think it was dropped, I presumed there was a proper DNS zone - have actually never tested scrapping dns lookup. But as far as I know, it is windows that does this lookup, the dns client looks at the hosts file, then does udp(53) lookup  - not Mercury itself, but this is dependent on what dns call is being used from mercury - you can programmatically call dns like: DNS_QUERY_NO_HOSTS_FILE - but I don't know which windows call David uses. There are also angry voices raised that MS sabotaged the dns hosts lookup after the WGA was introduced (f.ex. at securityfocus.com) - but - as I said, I haven't tested it in a real world test.

I may be wrong about this, but from a name server problem some year ago I got the impression that Mercury always makes its own lookups - it only gets the name server IPs from Windows (unless there has been other name servers specified in Mercury settings).

/Rolf 

<p>I may be wrong about this, but from a name server problem some year ago I got the impression that Mercury always makes its own lookups - it only gets the name server IPs from Windows (unless there has been other name servers specified in Mercury settings).</p><p>/Rolf </p>

[quote user="Peter Strömblad"]...this is dependent on what dns call is being used from mercury - you can programmatically call dns like: DNS_QUERY_NO_HOSTS_FILE - but I don't know which windows call David uses...[/quote]

Hopefully if it is coded to not use the hosts file then it can easily be changed to use the hosts file.

[quote user="Peter Strömblad"]There are also angry voices raised that MS sabotaged the dns hosts lookup after the WGA was introduced...[/quote]

I don't think that it was sabotaged, after all the other mail server works properly and I don't believe it has any special code for it (i.e. they didn't code in a host table lookup before the DNS lookup).

I resolved the problem by creating in our internal DNS server a forward lookup zone for the domain in the other mail server and added all of the A and MX records with internal addresses.  Mercury now sends directly to the other mail server via the internal network.

I really shouldn't have had to do this, though.  I would still like for Mercury to be changed to honor the host table, if it's not too much work.

<P>[quote user="Peter Strömblad"]...this is dependent on what dns call is being used from mercury - you can programmatically call dns like: DNS_QUERY_NO_HOSTS_FILE - but I don't know which windows call David uses...[/quote]</P> <P>Hopefully if it is coded to not use the hosts file then it can easily be changed to use the hosts file.</P> <P>[quote user="Peter Strömblad"]There are also angry voices raised that MS sabotaged the dns hosts lookup after the WGA was introduced...[/quote]</P> <P>I don't think that it was sabotaged, after all the other mail server works properly and I don't believe it has any special code for it (i.e. they didn't code in a host table lookup before the DNS lookup).</P> <P>I resolved the problem by creating in our internal DNS server a forward lookup zone for the domain in the other mail server and added all of the A and MX records with internal addresses.  Mercury now sends directly to the other mail server via the internal network.</P> <P>I really shouldn't have had to do this, though.  I would still like for Mercury to be changed to honor the host table, if it's not too much work.</P>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft