mrl72
asked on
E-mail bounce back 550 5.7.1
So I've been trying to send email to any address @optonline.net. I submitted a request through their email abuse department but had no help whatsoever. This is a copy of the bounce back email:
Final-Recipient: rfc822;name@optonline.net
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;550 5.7.1 Your mail from IP 206.222.5.211 was rejected. We can't currently accept your message. : name@optonline.net
Optonline support say our server is an open relay, it's not. I checked our server relay access and it's restricted to both our IP and localhost.
Does anyone know what could be causing this?
Final-Recipient: rfc822;name@optonline.net
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;550 5.7.1 Your mail from IP 206.222.5.211 was rejected. We can't currently accept your message. : name@optonline.net
Optonline support say our server is an open relay, it's not. I checked our server relay access and it's restricted to both our IP and localhost.
Does anyone know what could be causing this?
Have you checked if your public IP has been listed by some blacklist?
One more thing, does your public Ip have an associated domain name ? Some time the receipient's email server will do a reverse lookup of your IP and if no domain name is assocated, they will treat this as spam.
ASKER
If I go to mxtoolbox and lookup 206.222.5.211 this is what I see:
No MX records found for 206.222.5.211
We do not seem to be on any blacklists.
No MX records found for 206.222.5.211
We do not seem to be on any blacklists.
one easy way to test.
do a nslooup from any machine, try lookup your public IP (not your domain name). Do you have any record associated with that IP? If no, you probably need to call up your ISP and ask them to put a DNS record for your public IP for reverse lookup purpose.
do a nslooup from any machine, try lookup your public IP (not your domain name). Do you have any record associated with that IP? If no, you probably need to call up your ISP and ask them to put a DNS record for your public IP for reverse lookup purpose.
ASKER
This is what I get:
211.5.222.206.in-addr.arpa
Authoritative answers can be found from:
5.222.206.in-addr.arpa nameserver = ns2.ee.net.
5.222.206.in-addr.arpa nameserver = ns1.ee.net.
ns1.ee.net internet address = 206.222.1.23
ns2.ee.net internet address = 206.222.1.24
211.5.222.206.in-addr.arpa
Authoritative answers can be found from:
5.222.206.in-addr.arpa nameserver = ns2.ee.net.
5.222.206.in-addr.arpa nameserver = ns1.ee.net.
ns1.ee.net internet address = 206.222.1.23
ns2.ee.net internet address = 206.222.1.24
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok, i tried the abuse.net relay test and it is confusing. It runs about 5 tests and tests 1-4 fails with cannot relay. On the 5th attempt it appears to send the message but gives a warning "Hmmn, at first glance, host appeared to accept a message for relay. THIS MAY OR MAY NOT MEAN THAT IT'S AN OPEN RELAY.".
When I try to re-run the test I get this: "This host was recently tested. The host appeared to accept a test message for relay.". Which is not true.
When I try to re-run the test I get this: "This host was recently tested. The host appeared to accept a test message for relay.". Which is not true.
ASKER
Just to add:
The 5th relay test from abuse.net actually sent an email to our own domain and it was received successfully (email content below) but not to the address specified in the "To" in the header.
Received: from www.abuse.net ([208.31.42.77]) by group2call.com with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 11 Nov 2008 11:50:40 -0500
To: mrl72@yahoo.com
From: securitytest@abuse.net
Subject: Test for susceptibility of group2call.com to third-party mail relay
Date: Tue, 11 Nov 2008 16:55:05 GMT
Message-Id: <rlytest-1226422505-17765@
Sender: mrl72@yahoo.com
X-Sender-IP: 12.43.131.254
X-Envelope: <spamtest@group2call.com> -> <mrl72%yahoo.com@group2cal
Return-Path: spamtest@group2call.com
X-OriginalArrivalTime: 11 Nov 2008 16:50:40.0203 (UTC) FILETIME=[A0F6A9B0:01C9441
This is a test of third-party mail relay, generated via the
Network Abuse Clearinghouse at http://www.abuse.net.
Target host = group2call.com [206.222.5.211]
Test performed by <mrl72@yahoo.com> from 12.43.131.254
A well-configured mail server should NOT relay third-party email.
Otherwise, the server is subject to abuse by vandals and spammers,
and probable blacklisting by recipients of the unwanted third-party
e-mail.
For information on how to secure a mail server against third-party
relay, visit <URL: http://www.mail-abuse.com/support/an_sec3rdparty.html>.
The 5th relay test from abuse.net actually sent an email to our own domain and it was received successfully (email content below) but not to the address specified in the "To" in the header.
Received: from www.abuse.net ([208.31.42.77]) by group2call.com with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 11 Nov 2008 11:50:40 -0500
To: mrl72@yahoo.com
From: securitytest@abuse.net
Subject: Test for susceptibility of group2call.com to third-party mail relay
Date: Tue, 11 Nov 2008 16:55:05 GMT
Message-Id: <rlytest-1226422505-17765@
Sender: mrl72@yahoo.com
X-Sender-IP: 12.43.131.254
X-Envelope: <spamtest@group2call.com> -> <mrl72%yahoo.com@group2cal
Return-Path: spamtest@group2call.com
X-OriginalArrivalTime: 11 Nov 2008 16:50:40.0203 (UTC) FILETIME=[A0F6A9B0:01C9441
This is a test of third-party mail relay, generated via the
Network Abuse Clearinghouse at http://www.abuse.net.
Target host = group2call.com [206.222.5.211]
Test performed by <mrl72@yahoo.com> from 12.43.131.254
A well-configured mail server should NOT relay third-party email.
Otherwise, the server is subject to abuse by vandals and spammers,
and probable blacklisting by recipients of the unwanted third-party
e-mail.
For information on how to secure a mail server against third-party
relay, visit <URL: http://www.mail-abuse.com/support/an_sec3rdparty.html>.
>When I try to re-run the test I get this: "This host was recently tested. The host appeared to accept a test message for relay.". Which is not true.
I think it's referring to your test, nothing to worry about.
Difficult to know how to proceed - you really need to find out from the recipient what tools they are using to determine you are an open relay. As far as I can see the only think you can do to improve matters is to investigate having an SPF record, but I doubt very strongly that this is the real reason for their bouncing your messages.
I think it's referring to your test, nothing to worry about.
Difficult to know how to proceed - you really need to find out from the recipient what tools they are using to determine you are an open relay. As far as I can see the only think you can do to improve matters is to investigate having an SPF record, but I doubt very strongly that this is the real reason for their bouncing your messages.
Ah, messages crossed.
>but not to the address specified in the "To" in the header.
this is good. I think this proves you are ok
>but not to the address specified in the "To" in the header.
this is good. I think this proves you are ok
An alternative to them divulging their methods of testing is to get them to do a re-test of your server (get them on the phone whilst looking at your system), and see what comes up in your Firewall and SMTP logs during that test. If you are not seeing anything that could reasonably be from them, or any third-party test tools (similar to the one you've just run) then it sounds to me like they have some kind of issue at their end.
On the logs where you sent a message to them, which of their MX records handled the message? mx1 has the following issue:-
mx1.optonline.net claims to be host mta21.srv.hcvlny.cv.net [but that host is at 167.206.5.182 (may be cached), not 167.206.4.77]. <br />
Interestingly, both their MX records have the same priority of 2. Try seeing if you can get the other MX to handle the message, and that might prove something.
mx1.optonline.net claims to be host mta21.srv.hcvlny.cv.net [but that host is at 167.206.5.182 (may be cached), not 167.206.4.77]. <br />
Interestingly, both their MX records have the same priority of 2. Try seeing if you can get the other MX to handle the message, and that might prove something.