I have some code that does an email address validation. It works by attempting a mail delivery via SMTP and then quitting without sending anything. It works most of the time, but in some fringe cases it does not. I have one of these cases and I would like to know if anyone has a clue as to what the mail server might be unhappy about in my request?
Here is the TCP session on port 25 to smtp.hp.com (I have substituted real email addresses here)
220-g1t6210.austin.hp.com ESMTP Postfix
HELO ednasmtp.beweb.co.nz
250 g1t6210.austin.hp.com
MAIL FROM: <a_real_email@beweb.co.nz>
250 2.1.0 Ok
RCPT TO: <a_real_hp_user_email@hp.com>
550 5.5.1 Protocol error
QUIT
550 5.5.1 Protocol error
My question is, why is HP's postfix server saying "Protocol error"? Isn't my mail delivery valid?
Best Answer
smtp.hp.com
resolves to 4 different IP addresses. Each of them responds to SMTP, but they are configured in different ways. Without knowing which of the 4 you connected to it is difficult to say exactly why it failed. But I can go over your session step by step and explain multiple errors made by the client side along the way.This is a partial status message from the server as indicated by the
-
. The last line of the status will have ain that location. 3 of the 4 SMTP servers responds with a 2-line status message this way with a delay between the two lines. One of them responds with a 1-line status message, which rules out that one as having handled your session. The client will need to keep reading the status message until it has seen it all.
At this point the client violates the protocol by sending a command before receiving the full status.
Here the server violates the protocol by sending a different status code in what a standards compliant client would interpret as continuation of the
220-
status line from above.Here the client violates the protocol by the extraneous space between
:
and<
. A space is never permitted in that location, though there exist mail servers which will ignore that space and allow the transaction to continue.Here the client violates the protocol again in the same way as in the
MAIL
command.It's correct that there was a protocol error. It's hard to tell which of the protocol errors mentioned above it is complaining about. The
RCPT
command itself is erroneous, but it suffers from no error which haven't been seen earlier in the transaction as well.At this point it is hard to guess which side closed the connection. And given that both sides have violated the protocol it's probably no longer important. We can't even be sure which status codes applies to which commands.