itgolfer
asked on
Bounce Back Message From Specific Domain
We have a business in town that sends different users emails. They're occasionally getting bounce back messages with the following errors: '550 4.4.7 QUEUE.Expired; message expired' and '421 4.4.0 Remote server response was not RFC conformant'. I spoke with our spam filter provider and they don't show the emails hitting the spam filter and said that their domain is doing a PTR look up before sending the mail to recipient end. Since the the mx record of our domain points to the spam filter server and does not match up to their A records it is sending the mail out to the MX record.
Not all of their emails are being returned, just occasionally. I'm hoping to get some more information so I can pass it on to them if it is their problem. I know they said they were getting returned emails from other businesses that they send to so it could be on their end.
Not all of their emails are being returned, just occasionally. I'm hoping to get some more information so I can pass it on to them if it is their problem. I know they said they were getting returned emails from other businesses that they send to so it could be on their end.
ASKER
Correct, I don't really have control over the sending server. I was just hoping if something was in the those errors that I could help them diagnose the problem.
Sometimes an error code is enough indeed, but only when the problem is as clear as day (ex "Attachment too large, 15MB")
In this case, while there is text explaining what's wrong, it's not specific enough (it says a response was not compliant, but not EXACTLY which response).
At the source server, you could capture the entire traffic, and the line JUST before it gives the error, should be the offending one.
In this case, while there is text explaining what's wrong, it's not specific enough (it says a response was not compliant, but not EXACTLY which response).
At the source server, you could capture the entire traffic, and the line JUST before it gives the error, should be the offending one.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Right now what is happening is your exchange server is saying my name is itgolpher.contoso.com and IP is x.x.x.x
When other end server try to resolve x.x.x.x they are getting different name like Pune.contoso.com but server says I am itgolpher and dns says I am Pune so it is creating mismatch.
Where is your DNS records is hosted ?
When other end server try to resolve x.x.x.x they are getting different name like Pune.contoso.com but server says I am itgolpher and dns says I am Pune so it is creating mismatch.
Where is your DNS records is hosted ?
ASKER
I do have the forwarded bounce back message if that helps. It contains the headers but I'm not sure if that's enough info.
Please post.
All these questions are quite useless if you're not in full control of that Exchange server. Bounce back messages are usually not enough information.
@ kimcomuter : please see following article what Can You Find in an Email Header?
http://www.howtogeek.com/108205/htg-explains-what-can-you-find-in-an-email-header/
http://www.howtogeek.com/108205/htg-explains-what-can-you-find-in-an-email-header/
@PuneTech: I know all about headers. What you seem to forget is that the REAL FAILING email, is sent from an Exchange server OUTSIDE the asker's control. The REAL FAILING email WILL HAVE NO HEADERS as the email fails and doesn't actually exist. The EMAIL HEADER is from the bounce, and will be generated on that exact same server, and this is the bounce message that the asker has (which is useless except for the SMTP error!)
You need the FULL CONVERSATION from the original Exchange Server with the next hop to find out WHICH RFC rule is being broken. because you need to follow up on this error: 421 4.4.0 Remote server response was not RFC conformant'
Obviously, it may very well be a reverse DNS entry causing it, but again, the DNS will be just as likely out of asker's control.
You need the FULL CONVERSATION from the original Exchange Server with the next hop to find out WHICH RFC rule is being broken. because you need to follow up on this error: 421 4.4.0 Remote server response was not RFC conformant'
Obviously, it may very well be a reverse DNS entry causing it, but again, the DNS will be just as likely out of asker's control.
Please don't mind , I do apologize.
But if you read itgolpher last comment it says . "it contains the headers"
So I said please post.
Bye good night going for sleep
But if you read itgolpher last comment it says . "it contains the headers"
So I said please post.
Bye good night going for sleep
ASKER
My apologies, I was waiting to hear back from our spam filter provider. They made a change and things seem to be coming in without issue now. Thanks for all of your help.
Nice to here from you and thanks for the update, have a good day.
Usually you need the FULL SMTP logs to figure out what exactly the destination server doesn't like.
Sending servers do not check PTR records, as delivering the mail is the most important job of a sending server. Receiving servers do PTR records check, as they don't want the receive spam.
Your concern that your MX records points to a cloud spam filter is not warranted, unless YOU are the sending server.