On 12/02/12 18:23, Steve Holdoway wrote:

Could I lean on your good nature and ask for advice on how to fix this situation properly.

This charity receives emails from another organization, and the mail log goes like this...

Feb 12 18:09:49 mail sm-mta[18000]: q1C59mrc018000: ruleset=check_rcpt, arg1=, relay=122-56-8-123.cid.global-gateway.net.nz [122.56.8.123] (may be forged), reject=450 4.7.1 ... Access denied. IP name possibly forged [122.56.8.123]

If I investigate the IP address, it comes out in the telecom domain, but if I lookup 122-56-8-123.cid.global-gateway.net.nz, it comes back as NXDOMAIN.

Who should I be directing this problem to? I don't really want to drop this validation, as it does stop a metric shedload of spam.

Hi Steve, There are several fundamental basics that a mail server administrator needs to have in place if they expect the world to trust mail originating from their IP. The first of these is a matching forward/reverse DNS pair for your Mail server IP address. blakjak(a)hawkeye:~$ host 122.56.8.123 123.8.56.122.in-addr.arpa domain name pointer 122-56-8-123.cid.global-gateway.net.nz. blakjak(a)hawkeye:~$ host 122-56-8-123.cid.global-gateway.net.nz Host 122-56-8-123.cid.global-gateway.net.nz not found: 3(NXDOMAIN) The other organisation should not be expecting the world to accept their mail until they can get over that particular hump. The fact their mail is getting out at all, is probably a bonus to them. A useful reference for them may be http://www.linuxmagic.com/best_practices/ Meanwhile your choices are to a) communicate this to the remote party, and leave it at that b) suggest the other party use their ISP smarthost/smtp server, assuming one is provided (I don't know if Global Gateway have a public SMTP server for their customers... oncuponatime smtp.xtra.co.nz may have accepted connections from CID, unsure if this is true anymore) c) relax your inbound filtering rules as applied to this particular IP (aka whitelist it as a known-trusted source). Cheers Mark.