Topic: Sudden Email rejections - reported PTR/Domainname mismatch

[Ness]

Hello there - I'm really struggling to get someone (probably my ISP) to understand a recent problem that has arisen.

My SME Server sits on a static IP, using Tiscali (was Pipex, soon to be Opal) as the ISP. For a long time, I have had no problems sending email however about 2 weeks ago, one recipient domain started to reject my emails. At first I received the following failure messages:

Hi. This is the qmail-send program at tapiochre.co.uk.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<user@uoa.com>:
Connected to 193.115.162.131 but my name was rejected.
Remote host said: 554 No SMTP service here
I'm not going to try again; this message has been in the queue too long.

--- Below this line is a copy of the message....
...
...

Two days later, this error mesage stopped but a phone call revealed that further emails from me were not arriving at the recipient's email account.

The sysadmin at the recipient site asked me to send a test email, which I did, and he sent me back (I'm getting his emails fine) this note:

There is something wrong with your MX records in DNS.

We use "Mailmarshall" and it rejects any e-mail from a sender if the sending e-mail server doesn’t match the DNS records. Its done to stop spoofing of e-mail addresses. Since it is a standard feature of receiving e-mail server to verify who the sender says they are then there isn’t anything for me to do.

Here is the Mailmarshal message:-

2720 00:56:44.546 Got: <HELO tapiochre.co.uk>
2720 00:56:44.562 Event - PTR record for <81.86.45.77> does not match hello <tapiochre.co.uk>, rejecting Ptrs = 81-86-45-77.dsl.pipex.com

You need to resolve it at your end. I either have the feature ON or OFF and can’t do an exception rule. Its done to protect us from Spam and Spoof. It sometimes happens if a company with a registered DNS uses a mail server that isn’t registered as a legit Mail server for that organisation.

This last part sounds like nonsense to me, but if the only way I can resolve this is by getting the PTR record modified, then I don't know how or where to do this. My ISP (Tiscali/Pipex/Opal) say its not their problem, Netpivotal are the Nameserver guys and they say its not them ('its a problem in your mail server...").

Would anyone be able to guide me to a good resolution, who to talk to and what to say?

Many, many thanks

Chris

[CharlieBrady]

This last part sounds like nonsense to me, ...

It is. A mail server can send mail for many domains. The reverse DNS can match at most one of those domains.

... but if the only way I can resolve this is by getting the PTR record modified, then I don't know how or where to do this.

You can't. Only your network provider could do that (PTR record == reverse DNS).

[byte]

Problem here is your ISP who is now TalkTalk do not allow reverse DNS, so you will need to configure the SME Server to send via TalkTalk's own servers.

Note. Tiscali UK brought out Pipex, then TalkTalk brought Tiscali UK

[Ness]

Thank you Charlie and byte for that.

I just got on the line to the ISP (who still like to be known as Pipex!) and told them that I WANT the PTR set up to be as I need. They told me it wasnt necessary but I told em it was! Lets see what they come up with eh?

Many thanks

Chris

[janet]

Ness

See
http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Appendix

[CharlieBrady]

It is. A mail server can send mail for many domains. The reverse DNS can match at most one of those domains.

I note however that they are not matching the PTR record against your domain name, but merely against the string used in the SMTP "hello".

You could configure this for SME server. Do:

config setprop smtp HeloHost 81-86-45-77.dsl.pipex.com
signal-event email-update

Don't do this if you have a dynamic IP address, and if you do this, you will need to undo it if your ISP arrangements change.

[mmccarn]

This was one of AOL's *first* anti-spam techniques - back in the late 90's.  Just as you describe the current situation, their servers would silently accept the incoming message but not deliver it.   AOL dropped this particular spam filter technique quite a while ago, presumably because it either didn't work or generated too many false positives.

Of course it doesn't help with your particular problem, but I suspect that the mail admin currently rejecting your emails will reconfigure his system once his users figure out he's blocking email from a significant percentage of the planet...

[robwellesley]

It is. A mail server can send mail for many domains. The reverse DNS can match at most one of those domains.

You can't. Only your network provider could do that (PTR record == reverse DNS).

You sure about that Charlie?
http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

[CharlieBrady]

You sure about that Charlie?
http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records

OK I stand corrected - it is possible to have more than one PTR record. It's not recommended however, and only your ISP can do it.

[mercyh]

and only your ISP can do it.

And as stated before, if you ISP won't play, you are left with sending your email through your ISP's servers.

[andy_wismer]

Hello

It might help, if the domain has SPF entries in the DNS, pointing to the domain and server.

In this particular case, the DNS shows the following:

-----

nslookup -query=any tapiochre.co.uk
Server:  xxxxxxxxxx
Address:  xx.xx.xx.xx

Non-authoritative answer:
tapiochre.co.uk
        origin = ns1.netpivotal.com
        mail addr = rose.netpivotal.com
        serial = 1275817551
        refresh = 10800
        retry = 3600
        expire = 604800
        minimum = 86400
Name:   tapiochre.co.uk
Address: 66.98.188.22
tapiochre.co.uk nameserver = ns1.netpivotal.com.
tapiochre.co.uk nameserver = ns2.netpivotal.com.
tapiochre.co.uk mail exchanger = 10 mail.tapiochre.co.uk.

-----

nslookup -query=mx tapiochre.co.uk
Server:  xxxxxxxxxx
Address:  xx.xx.xx.xx

Non-authoritative answer:
tapiochre.co.uk mail exchanger = 10 mail.tapiochre.co.uk.

-----

nslookup -query=mx tapiochre.co.uk
Server:  xxxxxxxxxx
Address:  xx.xx.xx.xx

Non-authoritative answer:
tapiochre.co.uk mail exchanger = 10 mail.tapiochre.co.uk.

-----

nslookup mail.tapiochre.co.uk
Server:  xxxxxxxxxx
Address:  xx.xx.xx.xx

Non-authoritative answer:
Name:   mail.tapiochre.co.uk
Address: 81.86.45.77

-----

nslookup -query=spf tapiochre.co.uk
Server:  xxxxxxxxxx
Address:  xx.xx.xx.xx

Non-authoritative answer:
Name:   tapiochre.co.uk
Address: 66.98.188.22

----------------------------------------

In short, SPF says 66.98.188.22 is your mail server, when you're actually sending from 81.86.45.77 (Reverse-Lookup).

These things happen quite often if

A) You use Provider "X" to host your DNS and Webpages.
B) You use Provider "Y" to provide your connectivity.

Solution:
=======

- Have the MX entry corrected to point to your IP
- Have SPF entries created pointing to your domain and server (1 each
- Have your Connectivity-Provider (ISP) give you an IN-ADDR.ARPA entry, also known as a Reverse-Lookup.
- The Reverse-Entry must exist both ways, if you use sme-server-name.domainname.com, it should also be entried.
- Mail entries should be "A" records, not "CNAME", but CNAMEs do mostly work.

Some providers do not give Reverse-DNS entries, unless you point your globel DNS to them, and pay for a "business" connection - usually costing 10x the price...

That should help.

My 2 cents

Andy Wismer