Loading ...
Sorry, an error occurred while loading the content.

Re: postscreen vs. (all?|some?) address verification milter(s) in sendmail

Expand Messages
  • Mark Martinec
    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
    Message 1 of 9 , Sep 30, 2010
      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.Martinec@...>
      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

      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 xxx@...) to xxx.mpg.de, I discovered
      that the reason for rejections like:

      550 5.7.1 <xxx@...>...
      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.


      > 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

      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
      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.