SMTP error code compliance

Question

I'm not too sure if this is the best place to pose this question (or at serverfault). I'm using a 3rd party .NET SMTP component to send email directly to the recipients' mail server. I need to do this to get real-time result of the delivery. Sending via another SMTP server requires me to get the result asynchronously via DSN reporting which is too much hassle for the nature of my app.

Anyway, I'm having problem with the target SMTP server returning error code that does not tally with the error message. As such, I cannot tag the delivery as a hard or soft bounce. E.g. Reply error code is 450 (meaning mailbox not available), but the reply message is something to do with a timeout. When I send the same message again, it went through. Clearly a timeout issue for the previous send.

I realised also, the problem might not be the receiving SMTP server but the firewall/proxy (whatever you call it), that is protecting the server.

Does anyone has encountered similar problem and how do you deal with it.

PS: I'll try to provide more details from my log when I'm back to my office.

Answer 1

Sounds like greylisting. Which is funny, because as I began to read your question, that was one of the first hurdles I could anticipate.

Greylisting is an anti-spam method that works by soft-failing a delivery on the basis that legitimate MTAs will attempt to re-submit the message after a period of time. Unfortunately two things don't work in your favour:

• The greylisting period can be chosen at random. Which means that sometimes it will take multiple retries before a message is accepted for delivery.
• Although 4xx codes should always be treated as soft-failures and are used for this purpose, there isn't any requirement for the server to tell you that it is due to greylisting. Some will be so kind and some won't.

How you deal with that will depend on whether soft-failures are considered an ultimate failure for the purposes of what your application is doing. If they aren't, then you will have to devise some reliable queueing and retries. My honest advice to you would be that it is probably easier to implement reliable DSN or log checking than it is inventing your own RFC (and quirk) compliant MTA.