On 08/24/2013 08:16 PM, Szőts Ákos wrote:
Dear list members,
I have the following problem:
A 3rd party e-mail provider refuses the HELO/EHLO command if it doesn't
contain a valid FQDN address (which is acceptable from their point of view).
They refuse it with a 501 (permanent) error, which means according to [1]:
"[...] In this case, the sending MTA server should not queue the message, but
delete it from its queue and send back an NDR (Non-Delivery-Response) to the
sender, informing of such error."
The problem is, in spite of the above mentioned, Postfix (and BSD sendmail
also) puts the letter into the mail queue as it was deferred and tries to re-
send it continuously.
I tested it with the following:
$ /> telnet server29.citromail.hu smtp
Trying 91.83.45.29...
Connected to server29.citromail.hu.
Escape character is '^]'.
220 server29 mfiltro ESMTP server ready
HELO google.local
501 HELO requires FQDN address
Connection closed by foreign host.
The server did not wait for the client to start a MAIL transaction, or
send QUIT, in this session.
So far this is ok.
It clearly is not.
But after I sent a message with "sendmail
x...@citromail.hu", the following shows up in the mail queue:
D82A21807CB 300 Sat Aug 24 15:52:28 root@xxxxxx.local
(lost connection with server27.citromail.hu[91.83.45.27] while performing the
HELO handshake)
The same result as from the manual telnet attempt:
501 Syntax error in parameters or arguments
The server then disconnects, thus not allowing postfix to finish the
session.
As RFC5321 says, the server MUST wait for the client to send QUIT.
This would be evident if you had included actual postfix logs.
In Postfix the "soft_bounce" parameter is set to "no".
Doesn't matter, since the remote server incorrectly implements ESMTP.
I know that the problem can be easily circumvented by setting a proper FQDN,
but I want to know the root cause why Postfix (and the plain sendmail) puts the
letter into the queue as a deferred one.
Because it incorrectly implements ESMTP, and disconnects during a session.
This causes postfix to (correctly) treat the disconnect as a transient
network error.
Such an aborted session will be deferred.
FYI, postfix never breaks the connection once a session has been
established, unless it hits a timeout.
Any 5xx reply simply waits for the client to send better data, or QUIT.
If you still think postfix is in error here, show postfix logs of a
rejected message (i.e. one that logs a 5xx response in the postfix mail
log) that is subsequently deferred.
--
J.
