Cheers, Rolf.

Having read the Mercury/32 manual, I can see that this is a recommended configuration. I was intending to leave it in just in case anything changed in the future.

Thanks :)

Hi

I am in the process of documenting how DNS is configured in our network. I am also documenting the email setup. Whilst doing this I have come across something that I cannot quite understand.

I thought I had read that as part of the authentication procedure after the sending mail server has opened a transmission channel, the receiving server will carry out a reverse lookup against the connecting IP address to make sure the IP address is associated with the sender's domain. For example, our IP address is a static address assigned by our ISP. I have added 'mail' DNS records to each of the domains we send mail as and have assigned our public IP address.

But, when I do a reverse lookup on our static IP I see just one result and the record is from our ISP, and not any of the mail domains we manage.

Have I misunderstood this? Does a receiving server only check the 'mail' records? Or is the reverse check not intended as I thought?

Thanks

The way I understand it hosts in MX records are required to have a reverse lookup address (PTR record). Mail servers can check if there is a reverse DNS record but are not required to do so. There is no requirement or suggestion that the domain part of the reverse DNS should match the domain(s) handled by the server, but unfortunately some MTAs may check for that anyway.

Thanks Rolf

I obviously got this muddled in my head some time ago. I asked because there will be gazillions of mail servers out there which handle mail via ISP assigned addresses as opposed to the domain registrar's originally assigned address for that domain.

Thanks for putting me right :)

Cheers!

Here's another question - when configuring the Local Domains section of the Mercury Core Module I have included the domain literal [xx.xx.xx.xx]

But, I have never been able to get this to work. When I address mail to greenman@xx.xx.xx.xx Mercury/32 receives the connection but then refuses it: 554 connection refused

I have the following in transflt.mer

H, "*xx.xx.xx.xx*", R, "554"
D, "[EHeh][EHeh]LO *emailfirewall.spamina.com*", R-N, "554 connection refused."
R, "*honeypot@aphrodite.pmail.gen.nz*", RS, "554 Fraudulent RCPT rejected."
S, "*viagra*", D, "'Viagra' encountered in subject line - connection dropped."
S, "*vicodin*", R, "554 'Vicodin' encountered in subject line - message refused."
H, "[EHeh][EHeh]LO +[0-9]+.[0-9]+.[0-9]+.[0-9]*", R, "554 Invalid HELO format"
H, "[EHeh][EHeh]LO domain1*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO mail.domain1*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO domain2*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO mail.domain2*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO domain3*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO mail.domain3*", R, "554 Illegal HELO, connection refused."
# S, "/c*CONGRATULATIONS*WON*", BS, "554 Possibly Nigerian 419 Variant - please change and re-send."
# S, "*for job*", BS, "554 Possibly employment spam - please change and re-send."

Is the mailer attempting to connect directly to our IP address? The D argument would account for the response. I know that mail servers are technically supposed to accept mail delivered to the IP address, but the spammers use this to try and by-pass the filtering.

Haha - have I just answered my own question?

So, using the domain literal means that SMTP senders will not use the MX records. Is that correct?

[Edit]

Thinking about this more - you can ignore this question....

Anyway, I think you should keep having the external IP address listed in Local domains, even though incoming mail connecting directly to that IP address will be stopped by the D rule just as you say.