Mailing List Archive

On Monday 22 Feb 2016 23:09:52 francis drake wrote:
> Hi all,
>
> I have email that is being rejected by a mailserver with the following
> error:
>
> Remote_host_said:_553_We_don't_accept_mails_from_MX_with_missing_DNS_A_or_PT
> R_RR

...

Your reverse lookup result for the MX machine is interesting,

> dnsq ANY 26.143.243.162.in-addr.arpa. a.ns.theorb.net.
> answer: 26.143.243.162.in-addr.arpa 3600 PTR 26.143.243.162.theorb.net

esp. note the numbers (IP number) encoded in the name... (see further down)

...

> The only place left to look is the Received header in the email itself:
> Received: from 127.0.0.1 (HELO a.mx.theorb.net) (162.243.143.26)
>
> Could the rejection be because of the 127.0.0.1?

I'd be reasonably confident that's a red herring.

> If so, what settings in qmail must be changed to return the public IP?
> I've tried every control setting I could think of.

You've not told us anything about your config: Are you running via tcpserver
etc, and potentially log entries around the failing incoming email may be
helpful. Also details of the flavour of qmail/netqmail/patches etc. that you're
running.

> I'm very confused. There is only one server that rejects my mail and I'd
> like to cover all my bases to make sure my server is 100% compatible with
> everybody else's :D

I suspect that the remote system is giving an inaccurate error message, or
that you hit a temporary fault.

The temporary fault scenario could be that the remote system is unable to
successfully perform a reverse DNS lookup on the sending IP, but I presume
this is an ongoing rather than a one-off problem, making that scenario unlikely

The inaccurate error message feels more likely - looking at the reverse DNS
lookup I highlight above, the resulting PTR record includes the IP address
within the name. PTR names like this are considered by some systems to be
strong indicators of the sending system being a dynamic IP address, and
therefore suspect (e.g. of being part of a botnet). In this case I suspect the
receiving system acts with extreme prejudice towards such systems like yours;
the error message given may actually include this scenario, even though it
doesn't say so.

Possible solution: Talk to your provider to get the PTR record changed to
something that looks more like a 'normal' DNS name. Bonus points for email
purposes if it looks like the HELO/EHLO name used by the machine; also make
sure that the name you use resolves to the machine's IP.

Please keep the list posted with your progress on this.

cheers,

Andrew.
--
====================================================================
* Custom email solutions * Systems Administration * Networking
http://www.acrconsulting.co.uk/email/qmail.html
====================================================================

Thus said francis drake on Mon, 22 Feb 2016 23:09:52 +0000:

> Remote_host_said:_553_We_don't_accept_mails_from_MX_with_missing_DNS_A_or_PTR_RR

Perhaps it is because you give out strange records for your DNS:

$ dnsq any a.mx.theorb.net 104.131.146.81
255 a.mx.theorb.net:
323 bytes, 1+4+2+4 records, response, authoritative, noerror
query: 255 a.mx.theorb.net
answer: a.mx.theorb.net 86400 28 &\004\250\200\000\001\000\040\000\000\000\000\002O\040\001
answer: a.mx.theorb.net 86400 A 162.243.143.26
answer: a.mx.theorb.net 86400 PTR 1.0.0.2.f.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.8.a.4.0.6.2.ip6.arpa
answer: a.mx.theorb.net 86400 PTR 26.143.243.162.in-addr.arpa
authority: theorb.net 86400 NS a.ns.theorb.net
authority: theorb.net 86400 NS b.ns.theorb.net
additional: a.ns.theorb.net 86400 A 104.131.146.81
additional: a.ns.theorb.net 86400 28 &\004\250\200\000\001\000\040\000\000\000\000\002\005`\000
additional: b.ns.theorb.net 86400 A 162.243.143.26
additional: b.ns.theorb.net 86400 28 &\004\250\200\000\001\000\040\000\000\000\000\002O\040\000

Why are you returning PTR records for a.mx.theorb.net? Do you think that
some DNS resolver is ever going to make a query for PTR a.mx.theorb.net?

Also, there is much gluelessness in your in-addr.arpa zone? Perhaps the
MTA that is rejecting your MTA is unable to effectively resolve the
PTR record for 26.143.243.162.in-addr.arpa due to the number or NS
delegations it must traverse before finally getting an answer? It may be
that there is little you can do about this if this is the case.

You really need to contact the owner of the MTA that is returning the
error because only they know what impositions they are making.

553_We_don't_accept_mails_from_MX_with_missing_DNS_A_or_PTR_RR

What was the domain name of the MAIL FROM that came from your mail
server? Perhaps they are checking that an MX record exists for that
address?

> (note: I'm not really sir francis drake. That is an email throw away)

Well, if we're to believe your signature, you're Mike Write. :-)

Thanks,

Andy
--
TAI64 timestamp: 4000000056cdcf34

Hi Francis/Mike,


Am 23.02.2016 um 00:09 schrieb francis drake <fdrake47@yahoo.com>:
>
> Hi all,
>
> I have email that is being rejected by a mailserver with the following error:
>
> Remote_host_said:_553_We_don't_accept_mails_from_MX_with_missing_DNS_A_or_PTR_RR

This is my server

mail.fehcom.de

you are referring to.

I just found time to look a little deeper into to problem, which actually points to a complete different source ....

So, to recall the situation.

1. You try to setup a SMTP connection from

162.243.143.26 => 85.25.149.179 (that is mail.fehcom.de)

2. My qmail-smtpd run script is:

#!/bin/sh
QMAILDUID=`id -u qmaild`
QMAILDGID=`id -g qmaild`
HOSTNAME="mail.fehcom.de"
export SMTPAUTH="+cram"
export UCSPITLS=""
export BADLOADERTYPE="M"
. /var/qmail/ssl/env
exec softlimit -m 30000000 \
sslserver -seVn -Rp -l $HOSTNAME -c 1200 \
-x /var/qmail/etc/tcpd.smtpd.cdb \
-u $QMAILDUID -g $QMAILDGID 0 smtp \
rblsmtpd -W -r ix.dnsbl.manitu.net \
/var/qmail/bin/qmail-smtpd /var/qmail/bin/qmail-authuser /bin/true 2>&1


The statement 'sslserver -p' means 'paranoid'.

http://www.fehcom.de/ipnet/ucspi-ssl/sslserver.html

=> From the IP sslserver fetches the PTR, gets the CNAME/ANAME and from the ANAME takes the A RDATA (this is the IP) and compares the incoming IP with the DNS deployed one.

3. My sslserver rules are (finally):

=:allow,GREETDELAY="80",HELOCHECK="A",MFDNSCHECK="",BADMIMETYPE="+",BADLOADERTYPE="M",QHPSI="clamdscan",TARPITCOUNT="1",TARPITDELAY="999"
:allow,RBLSMTPD="-We don't accept mails from MX with missing DNS A or PTR RR."

which means: If (=>) succeeds, connection is ok; otherwise reject connection with this error message.

4. Now, lets reconstruct the problem:

i) Your incoming IP is: 162.243.143.26

ii) The inverse DNSName:

dnsname 162.243.143.26
a.mx.theorb.net

iii) The RR I receive from a.mx.theorb.net shows up like:

dnsip a.mx.theorb.net
2604:a880:1:20::24f:2001
162.243.143.26

5. Within sslserver I compare

162.243.143.26 <==> 2604:a880:1:20::24f:2001

to be more precise, since sslserver is IPv6 enabled, I compare the IPv4-mapped IPv6 address:

::ffff:162.243.143.26 <==> 2604:a880:1:20::24f:2001


Bummer.

---

To finish this discussion and come to a conclusive end:

A) Deploying IPv6 addresses in the Internet requires that your applications should be IPv6 enabled too, because IPv6 has precedence over IPv4. The opposite is true as well.

B) I need to enhance UCPSI-SSL and UCSPI-TCP6 to care for multiple A/AAAA records in case of the paranoid comparison.

Hope that helps.

regards.
--eh.


>
>
> The sending mail server is A.MX.THEORB.NET.
>
> Starting at the gtld servers:
>
> dnsq NS a.mx.theorb.net. d.gtld-servers.net.
> 2 a.mx.theorb.net:
> 100 bytes, 1+0+2+2 records, response, noerror
> query: 2 a.mx.theorb.net
> authority: theorb.net 172800 NS a.ns.theorb.net
> authority: theorb.net 172800 NS b.ns.theorb.net
> additional: a.ns.theorb.net 172800 A 104.131.146.81
> additional: b.ns.theorb.net 172800 A 162.243.143.26
>
>
> dnsq A a.mx.theorb.net. a.ns.theorb.net.
> 1 a.mx.theorb.net:
> 172 bytes, 1+1+2+4 records, response, authoritative, noerror
> query: 1 a.mx.theorb.net
> answer: a.mx.theorb.net 86400 A 162.243.143.26
>
> <snip/>
>
> dnsq PTR a.mx.theorb.net. a.ns.theorb.net.
> 12 a.mx.theorb.net:
> 279 bytes, 1+2+2+4 records, response, authoritative, noerror
> query: 12 a.mx.theorb.net
> answer: a.mx.theorb.net 86400 PTR 26.143.243.162.in-addr.arpa<snip/>
>
> dnsq ANY 26.143.243.162.in-addr.arpa. a.ns.theorb.net.
> 255 26.143.243.162.in-addr.arpa:
> 210 bytes, 1+5+0+0 records, response, authoritative, noerror
> query: 255 26.143.243.162.in-addr.arpa
> <snip/>
> answer: 26.143.243.162.in-addr.arpa 3600 PTR 26.143.243.162.theorb.net
> answer: 26.143.243.162.in-addr.arpa 3600 A 162.243.143.26
>
> As you can see the nameservers return authoritative answers for both A and PTR record requests and authoratative replies to the in-addr.arpa. requests.
>
>
> The only place left to look is the Received header in the email itself:
>
> Received: from 127.0.0.1 (HELO a.mx.theorb.net) (162.243.143.26)
>
>
> Could the rejection be because of the 127.0.0.1? If so, what settings in qmail must be changed to return the public IP? I've tried every control setting I could think of.
>
> I'm very confused. There is only one server that rejects my mail and I'd like to cover all my bases to make sure my server is 100% compatible with everybody else's :D
>
> Thanks for your attention,
> Mike Wright
>
> (note: I'm not really sir francis drake. That is an email throw away)


Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65
>