SMTP error code matching
I'm not too sure if this is the best place to ask this question (or on serverfault). I am using a third party .NET SMTP component to send email directly to the recipients mail server. I need to do this in order to get the delivery result in real time. Sending via a different SMTP server requires me to receive the result asynchronously via DSN reports, which is too complex for the nature of my application.
Anyway, I am having a problem returning the target SMTP server with an error code that does not match the error message. As such, I cannot mark the delivery as hard or soft bounce. For example. The response error code is 450 (meaning the mailbox is unavailable), but the response message is due to a timeout. When I send the same message again, it went through. Obviously there is a timeout problem for the previous send.
I also realized that the problem might not be with the receiving SMTP server, but with the firewall / proxy (whatever you call it) that is protecting the server.
Has anyone come across a similar problem and how do you deal with it.
PS: I will try to provide more details from my magazine when I return to my office.
source to share
Sounds like greylisting. It's funny because when I started reading your question, it was one of the first hurdles I could expect.
Greylisting is an anti-spam technique that fails on delivery based on the fact that legitimate MTAs will try to resend the message after a while. Unfortunately, two things don't work in your favor:
- The greylisting period can be freely selected. This means that sometimes it takes several tries before a message is accepted for delivery.
- Although 4xx codes should always be treated as soft failures and are used for this purpose, there is no requirement for the server to tell you that it was greylisting. Some of them will be so kind and some will not.
How you deal with this will depend on whether soft disclaimers are considered final disclaimers for the purposes of your application. If it is not, then you will have to design reliable queues and try again. My honest advice to you would be that it is probably easier to implement a robust DSN or log validation than coming up with your own RFT (and quirk) compliant MTA.
source to share