Here is a similar incident with a milter not understanding multiline
responses, as well as shooting out the query without waiting for a
greeting. Below is my side of the correspondence with its author
and with the postmaster of the site where it was first observed.
From: Mark Martinec <mark.marti...@ijs.si>
To: Eugene Kurmanin <...>
Subject: smf-sav shoots HELO without waiting for full greeting,
violating SMTP protocol
Date: Tue, 27 Oct 2009 15:41:40 +0100
I know the smf-sav hasn't been maintained for a while now, but my guess
is that some sites are still using it. I wonder if you are aware of the
SMTP protocol violation caused by smf-sav, which can cause the receiving
MTA to drop the connection right away, so subsequently the SAV fails
on the sending site.
The key problem here is that a SMTP protocol allows continuation of
responses (a '-' instead of a ' ' after the status code), while the
smf-sav fails to read all response lines first, but goes straight to
sending a HELO command. A more picky MTAs will disconnect the session
at that point.
Below is my message to postmasters of "Max Planck Institute for chemical
physics of solids", which possibly is using your software, according to
tcpdump.
Please consider fixing the issue in the next release.
( my message to mpg.de : )
While investigating mail delivery problems for messages sent from our
institute (e.g. from x...@ijs.si) to xxx.mpg.de, I discovered
that the reason for rejections like:
550 5.7.1 <x...@xxx.mpg.de>...
Sender address verification failed
is that your sender address verification implementation violates the
SMTP protocol by shooting out a command:
HELO mailgate.xxx.mpg.de
without first waiting for the reception of the complete greeting message.
I have now listed the xxx.xxx.xxx.xxx and xxx.xxx.xxx.xxx as broken mailers,
so as to ignore the violation in the future, but it would be nice
to fix your SAV, as it may give you trouble with other mail as well.
I wonder what software are you using for the SAV component.
Could it be that you are using an old smf-sav milter, which is
known to suffer from this defect?
[...]
Eugene writes:
> Sure, you are right. This bug was fixed in commercial software
> more than 2 years ago.
> This is a fixed code (replaced code of buggy function):
Hmmm. I don't think this will work reliably.
I see two problems there. One is that it assumes the SMTP response lines
will start at a TCP segment boundaries - which happens to be true in
most cases, but may not be, perhaps due to anti-spam firewalls stalling
the SMTP response and feeding it back by a slow trickle in several
packets, or perhaps due to packet fragmentation. The SMTP response code
can only start at a line boundary (first line, or following a CRLF).
The other problem, which affects us here directly is that the while loop
exits as soon as it encounters a LF at the end of a TCP segment.
It should continue reading the response continuation lines for as long
as the continuation character indicates 'more' (i.e. '2xx-...').
Let me illustrate what happens in case of a Postfix MTA with postscreen
enabled. It sends it greeting in two lines, the first line indicates
(with a '-') that continuation follows. There is also a few seconds
pause between the first and the second response line:
220-mail.ijs.si ESMTP Postfix
220 mail.ijs.si ESMTP Postfix
Only after a line with no 'more' mark is received, is the client
allowed to speak.
So I don't see a shortcut way out here, the client code needs
to recognize the concept of 'lines', and it must understand the
concept of multiline SMTP responses to be truly SMTP-compliant.
I've seen other mailers responding with multi-line greetings too.
I think some OpenBSD anti-spam sw is even more challenging to the client,
breaking the initial response into multiple TCP segments, with pauses
inbetween. The idea is to allow SMTP-compliant clients to send mail,
while stopping some quick-and-dirty malware mail-sending software
which tries to cut corners.
Regards
Mark
> But it works, as far as I know :)
> It was tested with OpenBSD spamd anti-spam daemon smth like that
> techniques.
Here is a SMTP SAV session as captured by a tcpdump between my [...] computer
running sendmail + smf-sav with your patch applied, and our institute's
main mailer (as a SAV response to my message sent from office to home):
220-mail.ijs.si ESMTP Postfix
HELO xxx.ijs.si
521 5.5.1 Protocol error
RSET
As you can see, the smf-sav does not wait for the complete greeting
message, it only waits until the end of the first line. The greeting
is a multiline response with a short pause between the
first line and its continuation line:
220-mail.ijs.si ESMTP Postfix
(pause)
220 mail.ijs.si ESMTP Postfix
and the client must not send a SMTP command until it receives
the complete SMTP response (as dictated by RFC 2821).
The session should have looked like:
220-mail.ijs.si ESMTP Postfix
220 mail.ijs.si ESMTP Postfix
HELO xxx.ijs.si
250 mail.ijs.si
[...]
Btw, I checked another SAV-capable milter (spamilter by Neal Horman),
and it does not suffer from this defect, it understands multiline
SMTP responses properly.
As postscreen is a relatively new feature of Postfix, you may not
encounter it often yet, but as time passes, more sites will be turning
it on.
Mark
