OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Aaron D. Gifford (agifford_at_infowest.com)
Date: Mon Sep 16 2002 - 13:59:33 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Hi,

    I'm running the FreeBSD port of Postfix (postfix-1.1.11-20020719). I've
    read the various messages in the archives about Postfix's PIX work-around
    code. The bug I'm seeing appears somehow related, but it IS a Postfix
    problem.

    Using tcpdump to grab the session in question, I sent an e-mail to a test
    e-mail account whose server sits behind a up-to-date Cisco PIX firewall
    (one without the bug). The message body contained exactly four lines. The
    first was a single period on a line by itself. The next line was empty.
    The third line was the word "END". The fourth line was empty. Like this:

    ----MESSAGE-BODY-FOLLOWS----
    .

    END

    ----END-OF-MESSAGE-BODY----

    Looking at the tcpdump output file, the ENTIRE message, including all
    headers and the entire message body, as well as the SMTP message
    termination sequence <CR><LF>.<CR><LF> and the SMTP "QUIT" command, was
    sent in a SINGLE TCP/IP packet. This is what I saw:

    ---IP-PACKET-DATA-CONTENTS---
    ...message headers...
    <CR><LF>
    ..<CR><LF>
    .<CR><LF>
    END<CR><LF>
    <CR><LF>
    <CR><LF>
    .<CR><LF>
    QUIT<CR><LF>
    ---END-OF-PACKET---

    Postfix correctly prepended the "." line with a leading "." character. But
    Postfix THEN screwed up and prepended a "." character to the EMPTY line
    following it. This caused the remote end to believe that the message was
    finished.

    I then sent this exact same message to another non-PIX address and did a
    dump. The ONLY difference in the TCP/IP packet that contained the message
    (besides the message ID and date stuff in the headers), was that Postfix
    did NOT mistakenly prepend a "." to the blank line.

    Both tcpdump data files were grabbed on the Postfix machine, so the data was
    seen as seen from the Postfix side, NOT the behind-the-PIX firewall side.

    Looking at the Postfix logs, they show both messages (the PIX one and the
    non-PIX one) delivered just fine with no problem. Also, the logs do NOT
    show a "PIX workaround" message.

    So what's up? Has this been fixed in a more recent version?

    Sincerely,
    Aaron Gifford

    -
    To unsubscribe, send mail to majordomopostfix.org with content
    (not subject): unsubscribe postfix-users