Re: [luv-beginners] email delivery problem
Thanks for the reply. This was what I figured may be the case. The problem is that they [the recipient] deny the presence of any log entries showing rejection from our address. I know the DNS entries are correct, I can send to the address from a number of remote emailers, but it will just not accept [or, apparently even acknowledge the existence of] our messages. They say that they have opened all possible channels for our emails - these are vital commercial negotiations, and so I believe them here - but we still cannot get through. Are there any settings I can make in OUR dns records or IP settings that may correct the problem? Are there other tools that I can use to obtain a better diagnosis? THanks again, Michael On 20/04/2012, at 3:19 PM, Piers Rowan wrote:
stat=Deferred: Connection refused
The other host is not accepting email.
This could be because of reverse MX, the originating IP address being on a LAN and not a FQDN or some other measure THEY have in place.
Ask them if the do reverse MX lookups or other anti spam measures.
Cheers
P
On 04/20/2012 02:44 PM, Michael Gapper wrote:
I have been asked to investigate a problem with undeliverable emails.
The problem is that email to a particular domain is not being sent but all other emails from the same server are apparently working correctly. The administrator of the receiving domain insists that our server is not handing the mail off correctly to the internet.
Our set-up consists of a windows network using a windows 2003 server domain with a gateway server running Fedora 9 and using Sendmail 8.14.12. Both servers are due for replacement in the near future.
Mail transport from Outlook on the windows network appears to have no problem using the mail server, only in the case of this one particular domain does delivery fail. I have tried sending an email to the "undeliverable" domain and cc'ing it to another external address. The message failed on one address but succeeded immediately on the other. The entry in the sendmail log is as follows:
Apr 19 11:51:03 gw sendmail[467]: q3J1p3w2000467: from=<Administrator@yyyyy.com.au>, size=1510, class=0, nrcpts=2, msgid=<64001D94702C3545B284436BFA4D2932457EAB@xxx.yyy.local>, proto=ESMTP, daemon=MTA, relay=[192.168.xx.xx] Apr 19 11:51:04 gw sendmail[470]: q3J1p3w2000467: to=<xxx@zzzz.com>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=151510, relay=extmail.zzzz.com. [xx.x.xxx.xxx], dsn=2.0.0, stat=Sent (Message received: 20120419015104.WMYJ5617.nskntingx06p.mx.zzzz.com@gw.yyyy.com.au) Apr 19 11:51:07 gw sendmail[470]: q3J1p3w2000467: to=<AAA@BBBB.com>, delay=00:00:04, xdelay=00:00:03, mailer=esmtp, pri=151510, relay=BBBB.com.inbound15.CCCCC.net. [xxx.xx.xxx.xx], dsn=4.0.0, stat=Deferred: Connection refused by BBBB.com.inbound15.CCCCC.net
dig finds the correct MX entries for the outside domain and traceroute has no problems locating the foreign server.
Any suggestions would be gladly received.
Thanks
Michael
_______________________________________________ luv-beginners mailing list luv-beginners@lists.luv.asn.au http://lists.luv.asn.au/listinfo/luv-beginners
--
Piers Rowan Director
Tel: (+61) (0)8 7324 1004 Mobile: (+61) (0)418 770 331
<rol_logo.png> piers.rowan@recruitonline.com.au www.recruitonline.com.au <logo_linkedin_92x22.png> My Profile Join User Group Online Recruitment Software
Thanks Trent but . . . If by your reply you mean that you cannot help unless all addresses are in plain text then perhaps you should say so. I would have thought that the structure of the log entry was important in its diagnosis, but if you feel that the specific addresses are vital to an understanding of the problem and think you can help more with a clear text version then I can provide one. All are obviously FQDN which seemed to be one point of contention. It is a beginners list and perhaps the"I TL;DR'd your post as soon as I saw the security-through-obscurity IPs." line deserves some explanation for those of us who admit to being beginners! cheers Michael On 22/04/2012, at 4:39 PM, Trent W. Buck wrote:
DR'd
Michael Gapper wrote:
If by your reply you mean that you cannot help unless all addresses are in plain text then perhaps you should say so.
More accurately: I *won't* help. Knowing the FQDNs and IPs means I can examine those hosts directly, and sometimes when people are hiding that information they make transcription errors e.g. Him: what's wrong with iptables -A PREROUTING -o eth0 -j DNAT --to a.b.c.d ? Me: you forgot -t nat. Him: oops, I fogot it there, but my real code has -t nat. Likewise sometimes the problem is that the querent doesn't notice that the log says example.net where it says example.com, and that is a key point to isolating the actual fault. The argument for suppressing such information is [0] which is practically useless in isolation but has some merit as part of [1]. The argument against it is that it makes life more difficult for people providing support, i.e. me. Since I'm volunteering my time and it's finite, I generally ignore such questions entirely and go help someone else. Since this *is* the beginner list, I thought I'd at least point that out, since usually there's a dozen other people in the same position who won't respond at all. [0] https://en.wikipedia.org/wiki/Security_through_obscurity [1] https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
It is a beginners list and perhaps the"I TL;DR'd your post as soon as I saw the security-through-obscurity IPs." line deserves some explanation for those of us who admit to being beginners!
Sorry about that.
On 23/04/2012, at 11:46 AM, Trent W. Buck wrote:
The argument for suppressing such information is [0] which is practically useless in isolation but has some merit as part of [1].
Or it can in be that there is a matter of commercial confidentiality which requires that the sender and receiver not be linked in a public forum. However, as you say it is possible to examine the hosts and IP's directly. Given that this is the case a more reasonable [and less time-wasting for all concerned] answer would therefore be to simply say "Have you tried to use x or y to query the domain?". I shall therefore rephrase my question: Can anyone provide either a comprehensive list of tools for use in troubleshooting email connectivity and/or a link to sources of such information? Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/04/2012 13:31, Michael Gapper wrote:
I shall therefore rephrase my question:
Can anyone provide either a comprehensive list of tools for use in troubleshooting email connectivity and/or a link to sources of such information?
I've found Telnet to be incredibly useful to diagnose some SMTP issues. Clearly, your server is logging that the connection is being refused by whatever "BBBB.com.inbound15.CCCCC.net" is. Irrespective of what level this is being refused at, they are highly unlikely to have logs as most systems won't be configured to log refused connections. IF it was at SMTP level, then you'd have SMTP error codes in the logs - - 4xx and 5xx error codes would be in those log lines AND they would have them at their end as well. As they have no logs and you've got a "Connection Refused", it would be incredibly unlikely to be anything other than something on BBBB.com.inbound15.CCCCC.net denying the connection attempt from your SMTP server. Hope this helps you fight this battle. Cheers, Tim Lyth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPmQtUAAoJEENQGX7xOJnV/E4H/0iOgTd/Q1ho4WHzvDTU1HTl 6btg+mwg9R5S1HVWVVCt2wXA37b4ltxCTCHUEUlMzYlCTDp5j+RzyYjImgtBCVWU HGl59IPfTn1MFgP2YVE1ChcbKhcdEOYh0HwgviQTFgZo0f+GEiC+Vu+bEC0xfKdq 21tTUfyCbpg5H2kWhmiWgxQcC0gcSpxV5onb7ykc7Q2iueLHLoK8IB4MSmS82UhW Z7rTq75Gx0UEsqlpNSNILA7QtipopjbN3B9LTarNPStj4wr5zo6qU3+QYFsZnCge G9ITxHaUCA7pwfrT3cM315IIRfpFtyiAgPY/CCkbK7/u5AT1ThjUVEumMaUrI/Y= =OFU0 -----END PGP SIGNATURE-----
Thanks to Tim Lyth this problem appears to have now been resolved. Firewall issues at the receiving end! Thanks again for your assistance Tim On 26/04/2012, at 6:46 PM, Tim Lyth wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23/04/2012 13:31, Michael Gapper wrote:
I shall therefore rephrase my question:
Can anyone provide either a comprehensive list of tools for use in troubleshooting email connectivity and/or a link to sources of such information?
I've found Telnet to be incredibly useful to diagnose some SMTP issues.
Clearly, your server is logging that the connection is being refused by whatever "BBBB.com.inbound15.CCCCC.net" is. Irrespective of what level this is being refused at, they are highly unlikely to have logs as most systems won't be configured to log refused connections.
IF it was at SMTP level, then you'd have SMTP error codes in the logs - - 4xx and 5xx error codes would be in those log lines AND they would have them at their end as well. As they have no logs and you've got a "Connection Refused", it would be incredibly unlikely to be anything other than something on BBBB.com.inbound15.CCCCC.net denying the connection attempt from your SMTP server.
Hope this helps you fight this battle.
Cheers, Tim Lyth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPmQtUAAoJEENQGX7xOJnV/E4H/0iOgTd/Q1ho4WHzvDTU1HTl 6btg+mwg9R5S1HVWVVCt2wXA37b4ltxCTCHUEUlMzYlCTDp5j+RzyYjImgtBCVWU HGl59IPfTn1MFgP2YVE1ChcbKhcdEOYh0HwgviQTFgZo0f+GEiC+Vu+bEC0xfKdq 21tTUfyCbpg5H2kWhmiWgxQcC0gcSpxV5onb7ykc7Q2iueLHLoK8IB4MSmS82UhW Z7rTq75Gx0UEsqlpNSNILA7QtipopjbN3B9LTarNPStj4wr5zo6qU3+QYFsZnCge G9ITxHaUCA7pwfrT3cM315IIRfpFtyiAgPY/CCkbK7/u5AT1ThjUVEumMaUrI/Y= =OFU0 -----END PGP SIGNATURE----- _______________________________________________ luv-beginners mailing list luv-beginners@lists.luv.asn.au http://lists.luv.asn.au/listinfo/luv-beginners
participants (3)
-
Michael Gapper -
Tim Lyth -
Trent W. Buck