Jump to content

Connection refused due to abuse ??? Lists of poor Standing


Tanquen

Recommended Posts

We have had an issue in the past with an infected computer sending spam. We got that taken care of and got off the all the blacklist that I know of. At that same time I was introduce the world of sites that rate your mail server. We were on this one a few times http://unblock.secureserver.net and one other but now we appear to be on one but the rejection email we get back is void of any info suggesting what list or how to get off it.

This is what we get:

You do not have permission to send to this recipient. For assistance, contact your system administrator.

<mail.ourserver.com #5.7.1 smtp;550 5.7.1 H:MXB<71.6.48.162>Connection refused due to abuse>

What is the best way to find out what list it is or if it even is a list?

Link to comment
Share on other sites

This is what we get:

You do not have permission to send to this recipient. For assistance, contact your system administrator.

<mail.ourserver.com #5.7.1 smtp;550 5.7.1 H:MXB<71.6.48.162>Connection refused due to abuse>

What is the best way to find out what list it is or if it even is a list?

This is likely not from a "blocklist". When people spam, and that spam is not blocked by the RBLs, many sysadmins will block the source IP directly on their mail server.

I run many mail servers, and I have my own internal "blocklist". It returns "Rejected due to spam abuse". Once a site makes this list, chances are they will remain there forever. The only reason I ever remove a listing is if one of my customers complains of not receiving email from a particular source, and that source is being blocked by one of my entries. I never respond to non-customer requests for delisting.

The other likely reason your connection was refused is because it looks like an end-user IP address; IE NOT a real mail server.

71.6.48.162 resolves to 71-6-48-162.static-ip.telepacific.net. This is NOT a valid mail server address, but rather an end-user address. 90% of all spam originates from end-user addresses (botnets, infected PC... etc), so blocking ALL email requests from end-users has become an effective way to mitigate the spam problem. None of my mail servers will communicate with any end-users as a matter of policy.

To get around this, use your ISP's mail server instead of sending direct from your PC. If 71.6.48.162 is a legitimate mail server (Ie IP and RDNS'ed to the same domain as the email being sent) , then change the RDNS to reflect it. If you don't control the RDNS, or can't get the owner to do so, you will have increasing difficulty getting your mail accepted.

Bob

Link to comment
Share on other sites

Lets see:

Address lookup

canonical name 71-6-48-162.static-ip.telepacific.net.

addresses 71.6.48.162

No help there it is a generic reverse DNS most mail servers would refuse mail from this address.

Lets see who it belongs to

CustName: CONTROL MANUFACTURING

NetRange: 71.6.48.160 - 71.6.48.175

CIDR: 71.6.48.160/28

NetName: CONTROL-MANUFACTURING

Now we have something lets try

fluidiqs.com

Resolved fluidiqs.com to 208.35.253.205

fluidiqs.com has no MX records

Thats not it lets try this

www.fluidiqs.com

Resolved www.fluidiqs.com to 216.148.233.77

www.fluidiqs.com has no MX records -> [fluidiqs.com has 1 MX record mail.controlmanufacturing.com.(50)]

Now we finally have a mail server

Resolved mail.controlmanufacturing.com to 71.6.48.162

mail.controlmanufacturing.com has no MX records -> [controlmanufacturing.com has 2 MX records mail.controlmanufacturing.com.(50) mailqueue.telepacific.net.(100)]

Bingo!

Looks like you just have a small dns problem but probably big enough for some mail admins who require a valid reverse DNS. mail.controlmanufacturing.com points to 71.6.48.162 but 71.6.48.162 does not point to mail.controlmanufacturing.com it points to 71-6-48-162.static-ip.telepacific.net

Don't see ya in any blocklists.

Parsing input: 71.6.48.162

No recent reports, no history available

Nothing in spamcop except:

Statistics:

71.6.48.162 not listed in bl.spamcop.net

More Information..

71.6.48.162 not listed in dnsbl.njabl.org

71.6.48.162 not listed in dnsbl.njabl.org

71.6.48.162 not listed in cbl.abuseat.org

71.6.48.162 not listed in dnsbl.sorbs.net

No valid email addresses found, sorry!

Senderbase looks ok

Last day 1.8 -49%

Last month 2.1

Link to comment
Share on other sites

Merlyn thanks so much.

I had spoken with our DNS host a few months ago and they had already made a change that was supposed to fix some kind of issue like reverse lookup. I don’t know much about MX records but I thought that the priority (50) for mail.controlmanufacturing.com meant that it would be found or talked to first and if it was not there or communicating then the next record would be used. Are you saying for a reverse lookup to pass you can’t have more than one record?

Link to comment
Share on other sites

Your priority is ok it's just your reverse dns that is the problem. Have it link properly back and forth and you should be just fine. The way it is right now it would be blocked on our servers but if it worked both ways it would pass.

Good luck.

Link to comment
Share on other sites

...Are you saying for a reverse lookup to pass you can’t have more than one record?

No. Each MX host must reverse resolve to your domain, not some generic name. You can have as many MXs as you want, each must be set up correctly.

Bob

Link to comment
Share on other sites

The reverse DNS entry, or PTR record, needs to be setup by the owner of the IP address, not the DNS host that handles your A records. Most ISPs are happy to do this for their static IP customers, as static IPs aren't a great deal of good without PTR records. You need to contact your account rep at telepacific.net and have them get a PTR records created that matches your existing A record for your mail server.

Link to comment
Share on other sites

No. Each MX host must reverse resolve to your domain, not some generic name. You can have as many MXs as you want, each must be set up correctly.

On the right lines, but not 100% correct.

controlmanufacturing.com has the highest priority MX as mail.controlmanufacturing.com

mail.controlmanufacturing.com resolves to 71.6.48.162

The PTR record for 71.6.48.162 should point to mail.controlmanufacturing.com (not to the domain name)

If the forward and reverse lookups do not match, mail servers will usually tag the received lines with "may be forged". Some systems may reject mail under these conditions and others will probably use it as a criteria for scoring after receipt.

The machine should also know that its FQDN is mail.controlmanufacturing.com and HELO/EHLO as that name. Though this is a lot less likely to cause problems than a DNS mismatch.

Link to comment
Share on other sites

The machine should also know that its FQDN is mail.controlmanufacturing.com and HELO/EHLO as that name. Though this is a lot less likely to cause problems than a DNS mismatch.

Please tell me more about this FQDN and HELO/EHLO. I would like everything to be set as correct as possible and remove as many future head scratchers as possible. "The machine" This setting is on the Exchange server?

Thanks to everyone for the info.

Also, is there any issue with the fact that we have changed our company name and email to FluidIQs.com? Should we be updating the MX record to mail.FluidIQs.com or is all good as long as we handle it on our end?

Link to comment
Share on other sites

Please tell me more about this FQDN and HELO/EHLO. I would like everything to be set as correct as possible and remove as many future head scratchers as possible. "The machine" This setting is on the Exchange server?

FQDN is Fully Qualified Domain Name. That is the name of the machine with the domain added to the end. In your case that would be mail.controlmanufacturing.com. Unless set up correctly, Windows boxes have the tendency to use only their host name without the domain on the end. You should be able to set it from the system properties control panel. There will be an option to change the computer name. There you set the host name. If you click on the more button on that panel, it will let you add the DNS suffix for the machine. A quick Google also found this in reference to Exchange.

Also, is there any issue with the fact that we have changed our company name and email to FluidIQs.com? Should we be updating the MX record to mail.FluidIQs.com or is all good as long as we handle it on our end?

There shouldn't be a problem with setting up an MX DNS record for FluidIQs.com pointing to mail.controlmanufacturing.com as long as the mail server is configured to handle mail for that domain too.
Link to comment
Share on other sites

Thanks again for all the help. I got this email from TelePacific today:

Your request for a PTR record was completed. I verified it has propagated out to the internet:

How I am searching:

Asking c.root-servers.net for 162.48.6.71.in-addr.arpa PTR record:

c.root-servers.net says to go to basil.arin.net. (zone: 71.in-addr.arpa.)

Asking basil.arin.net. for 162.48.6.71.in-addr.arpa PTR record:

basil.arin.net [192.55.83.32] says to go to NS1.TELEPACIFIC.NET. (zone: 48.6.71.in-addr.arpa.)

Asking NS1.TELEPACIFIC.NET. for 162.48.6.71.in-addr.arpa PTR record: Reports mail.controlmanufacturing.com. [from 64.60.0.10]

My guess is though, if this was the issue we are now permanently blocked by these mail servers as we are on no external black or block list that I can find and the emails are still rejected.

TelePacific also said something about verifying our SPF record with our host freerun.com

Also, we had passed this test before but now that we have the barracuda ckecking our email we no longer pass this test. Could this cause us to get blocked as well?

WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.

mail.controlmanufacturing.com claims to be non-existent host barracuda.fluidiqs.com: <br /> 220 barracuda.fluidiqs.com ESMTP (a17151d77f6dc31b33e5604beffbaca0) <br />

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...