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

Re: test submission on 587

Expand Messages
  • Daniel Bromberg
    ... Yes, but it s troublesome with little reward. Manually learning and typing in the SMTP specification is nice to know, but not necessary and probably
    Message 1 of 23 , Feb 28, 2011
    • 0 Attachment
      On 2/28/2011 11:17 AM, Wietse Venema wrote:
      > jeffrey j donovan:
      >> Thanks
      >> I guess blew past that,.. okay so just kill the session and use
      >> a client. I thought i would be able to then send or type a test
      >> message like MAIL FROM: soandso
      >> -j
      > You can (
      >
      > openssl s_client -connect host:port
      >
      > provided that you avoid the R and Q characters.
      >
      > Just use lowercase input.
      >
      > Wietse
      Yes, but it's troublesome with little reward. Manually learning and
      typing in the SMTP specification is nice to know, but not necessary and
      probably confusing for the stage the OP is at. For example, to use AUTH
      properly, you have to manually Base64-encode your inputs (I used a
      web-site utility to do so). In any case, I've enclosed an example
      transaction with private data redacted. My comments are in [].

      # openssl s_client -connect smtp.example.com:465
      220 smtp.example.com ESMTP Postfix
      HELO example.com
      250 example.com
      AUTH login
      334 VXNlcm5hbWU6 [the base64 encoding of "Username:"
      ZGFuaWVsQGJhc2V6ZW4uY29t [base64 encoding of "daniel@..."]
      334 UGFzc3dvcmQ6 [and of "Password:"]
      <redacted> [base64 encoding of my password]
      235 2.7.0 Authentication successful
      MAIL FROM: <daniel@...>
      250 2.1.0 Ok
      RCPT TO: <daniel@...>
      RENEGOTIATING [this and the next 3 lines is SSL protocol chatter you can
      ignore]
      depth=1 /C=BE/OU=Domain Validation CA/O=GlobalSign nv-sa/CN=GlobalSign
      Domain Validation CA
      verify error:num=20:unable to get local issuer certificate
      verify return:0
      rcpt to: <daniel@...> [note lowercase is important here]
      250 2.1.5 Ok
      data
      354 End data with <CR><LF>.<CR><LF>
      From: daniel@...
      To: daniel@...
      Subject: None

      Boy, This was a lot of Work.
      .
      250 2.0.0 Ok: queued as 143086FC0E9
      quit
      221 2.0.0 Bye
      read:errno=0
      #
    • Daniel Bromberg
      ... Interestingly, I also encountered The Quoting Problem again. By putting in the end of a *sample* SMTP conversation in the middle of a *real* one, I cut off
      Message 2 of 23 , Feb 28, 2011
      • 0 Attachment
        >
        > # openssl s_client -connect smtp.example.com:465
        > 220 smtp.example.com ESMTP Postfix
        > HELO example.com
        > 250 example.com
        > AUTH login
        > 334 VXNlcm5hbWU6 [the base64 encoding of "Username:"
        > ZGFuaWVsQGJhc2V6ZW4uY29t [base64 encoding of "daniel@..."]
        > 334 UGFzc3dvcmQ6 [and of "Password:"]
        > <redacted> [base64 encoding of my password]
        > 235 2.7.0 Authentication successful
        > MAIL FROM: <daniel@...>
        > 250 2.1.0 Ok
        > RCPT TO: <daniel@...>
        > RENEGOTIATING [this and the next 3 lines is SSL protocol chatter you
        > can ignore]
        > depth=1 /C=BE/OU=Domain Validation CA/O=GlobalSign nv-sa/CN=GlobalSign
        > Domain Validation CA
        > verify error:num=20:unable to get local issuer certificate
        > verify return:0
        > rcpt to: <daniel@...> [note lowercase is important here]
        > 250 2.1.5 Ok
        > data
        > 354 End data with <CR><LF>.<CR><LF>
        > From: daniel@...
        > To: daniel@...
        > Subject: None
        >
        > Boy, This was a lot of Work.
        Interestingly, I also encountered The Quoting Problem again. By putting
        in the end of a *sample* SMTP conversation in the middle of a *real*
        one, I cut off my own message. See, frustrating messing with the
        protocol. :-) Here's the last part again, with the terminating '.'
        moved in a space:


        data
        354 End data with <CR><LF>.<CR><LF>
        From: daniel@...
        To: daniel@...
        Subject: None

        Boy, This was a lot of Work.
        .
        250 2.0.0 Ok: queued as 143086FC0E9
        quit
        221 2.0.0 Bye
        read:errno=0
        # [back at unix prompt]
      • Claus Assmann
        ... Wrong. If you want to use extensions, you have to use EHLO. ... Wrong. See the RFC, no space after : . ... See above.
        Message 3 of 23 , Feb 28, 2011
        • 0 Attachment
          On Mon, Feb 28, 2011, Daniel Bromberg wrote:

          > HELO example.com

          Wrong. If you want to use extensions, you have to use EHLO.

          > 250 example.com
          > AUTH login

          > MAIL FROM: <daniel@...>

          Wrong. See the RFC, no space after ":".

          > RCPT TO: <daniel@...>

          See above.
        • Daniel Bromberg
          ... This is at least somewhat trollish and ignores the context. Obviously my example was from a Postfix server, and obviously it worked. So I have a little
          Message 4 of 23 , Feb 28, 2011
          • 0 Attachment
            On 2/28/2011 12:25 PM, Claus Assmann wrote:
            > On Mon, Feb 28, 2011, Daniel Bromberg wrote:
            >
            >> HELO example.com
            > Wrong. If you want to use extensions, you have to use EHLO.
            >
            >> 250 example.com
            >> AUTH login
            >> MAIL FROM:<daniel@...>
            > Wrong. See the RFC, no space after ":".
            >
            >> RCPT TO:<daniel@...>
            > See above.
            >
            This is at least somewhat trollish and ignores the context. Obviously
            my example was from a Postfix server, and obviously it worked. So I have
            a little trouble with "wrong". We are not implementing an SMTP
            specification. In fact I am actively discouraging the OP from getting
            to know the intimate details of SMTP. We are running a simple protocol
            test. If the Postfix server was not permissive about the extra space, we
            could easily adapt and remove it. As it happens, the space improves
            readability. Because the Postfix server is under our control, we know it
            accepts AUTH and thus EHLO is not needed.

            When someone is being helpful, it is nice to continue the thread in the
            spirit of helpfulness.

            -Daniel
          • Victor Duchovni
            ... Sure, but for posterity the list archives can reasonably steer future readers away from incorrect (even if tolerated) syntax. As for testing via openssl
            Message 5 of 23 , Feb 28, 2011
            • 0 Attachment
              On Mon, Feb 28, 2011 at 01:53:39PM -0500, Daniel Bromberg wrote:

              > Obviously my
              > example was from a Postfix server, and obviously it worked. So I have a
              > little trouble with "wrong".

              Sure, but for posterity the list archives can reasonably steer future
              readers away from incorrect (even if tolerated) syntax.

              As for testing via 'openssl s_client', more complete testing can be done
              via stunnel.

              [stunnel.smtp]
              accept = localhost:25
              connect = stunnel.example.com:587
              protocol = smtp

              --
              Viktor.
            • Noel Jones
              ... But it was a helpful post. Just because the version of postfix you re using works with invalid syntax doesn t mean it will always work, so wrong examples
              Message 6 of 23 , Feb 28, 2011
              • 0 Attachment
                On 2/28/2011 12:53 PM, Daniel Bromberg wrote:
                > On 2/28/2011 12:25 PM, Claus Assmann wrote:
                >> On Mon, Feb 28, 2011, Daniel Bromberg wrote:
                >>
                >>> HELO example.com
                >> Wrong. If you want to use extensions, you have to use EHLO.
                >>
                >>> 250 example.com
                >>> AUTH login
                >>> MAIL FROM:<daniel@...>
                >> Wrong. See the RFC, no space after ":".
                >>
                >>> RCPT TO:<daniel@...>
                >> See above.
                >>
                > This is at least somewhat trollish and ignores the context.
                > Obviously my example was from a Postfix server, and obviously
                > it worked. So I have a little trouble with "wrong". We are not
                > implementing an SMTP specification. In fact I am actively
                > discouraging the OP from getting to know the intimate details
                > of SMTP. We are running a simple protocol test. If the Postfix
                > server was not permissive about the extra space, we could
                > easily adapt and remove it. As it happens, the space improves
                > readability. Because the Postfix server is under our control,
                > we know it accepts AUTH and thus EHLO is not needed.
                >
                > When someone is being helpful, it is nice to continue the
                > thread in the spirit of helpfulness.
                >
                > -Daniel
                >

                But it was a helpful post. Just because the version of
                postfix you're using works with invalid syntax doesn't mean it
                will always work, so wrong examples that just happen to work
                don't belong here.

                And while I'm at it, I'll repeat that when testing with
                openssl, you must use lower case "rcpt to:" as the "R"
                triggers a protocol renegotiation, which in some cases can
                cause a "bad syntax" or "command not recognized" error, or
                terminate the session.

                I appreciate your time spent creating and posting the example.
                However, the next guy might not be so lucky and waste
                valuable time troubleshooting a problem that doesn't exist.

                All this leads me to repeat that once you get a postfix
                response to "EHLO world", it's better to continue testing with
                a real mail client.

                Over and out.


                -- Noel Jones
              • Daniel Bromberg
                The discussion over the invalid space syntax got me thinking, so I tracked my SMTP traffic for about 45 minutes. The only non-compliant clients were clear
                Message 7 of 23 , Feb 28, 2011
                • 0 Attachment
                  The discussion over the invalid space syntax got me thinking, so I tracked my SMTP traffic for about 45 minutes. The only non-compliant clients were clear spammers, save for two gray-area clients, one using StrongMail -- surprise, surprise a purveyor of mass marketing software, and the other also a mass-marketing, if legitimate, campaign. (Sorry, jacintajp@....com, enravishingly@...com, and ...@..., but thou doth giveth thyself away.)

                  Is this a useful option to add to _postcreen(8)_? I can't find anywhere postscreen can classify anything as "meeeh" rather than accept/reject, but from a few hundred samples (admittedly, quite small), this is a 100% mass-marketing-positive classifier.

                  -Daniel

                • Jerry
                  On Mon, 28 Feb 2011 16:47:45 -0500 ... PLEASE, do not hi-jack a thread. While you are at it, lose the HTML formatting. Plain ASCII text works fine. -- Jerry
                  Message 8 of 23 , Feb 28, 2011
                  • 0 Attachment
                    On Mon, 28 Feb 2011 16:47:45 -0500
                    Daniel Bromberg <daniel@...> articulated:

                    > The discussion over the invalid space syntax got me thinking, so I
                    > tracked my SMTP traffic for about 45 minutes. The only non-compliant
                    > clients were clear spammers, save for two gray-area clients, one
                    > using StrongMail <http://www.strongmail.com/> -- surprise, surprise a
                    > purveyor of mass marketing software, and the other also a
                    > mass-marketing, if legitimate, campaign. (Sorry, jacintajp@....com,
                    > enravishingly@...com, and ...@..., but thou doth
                    > giveth thyself away.)
                    >
                    > Is this a useful option to add to _postcreen(8)_? I can't find
                    > anywhere postscreen can classify anything as "meeeh" rather than
                    > accept/reject, but from a few hundred samples (admittedly, quite
                    > small), this is a 100% mass-marketing-positive classifier.

                    PLEASE, do not "hi-jack" a thread. While you are at it, lose the HTML
                    formatting. Plain ASCII text works fine.

                    --
                    Jerry ✌
                    postfix-user@...
                    _____________________________________________________________________
                    TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
                    TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
                  • Wietse Venema
                    ... Postscreen answers one YES/NO question: is this client allowed to talk to a Postfix SMTP server process. It makes this ruling on the basis of a single
                    Message 9 of 23 , Feb 28, 2011
                    • 0 Attachment
                      Daniel Bromberg:
                      > The discussion over the invalid space syntax got me thinking, so I
                      > tracked my SMTP traffic for about 45 minutes. The only non-compliant
                      > clients were clear spammers, save for two gray-area clients, one using
                      > StrongMail <http://www.strongmail.com/> -- surprise, surprise a purveyor
                      > of mass marketing software, and the other also a mass-marketing, if
                      > legitimate, campaign. (Sorry, jacintajp@....com, enravishingly@...com,
                      > and ...@..., but thou doth giveth thyself away.)
                      >
                      > Is this a useful option to add to _postcreen(8)_? I can't find anywhere
                      > postscreen can classify anything as "meeeh" rather than accept/reject,
                      > but from a few hundred samples (admittedly, quite small), this is a 100%
                      > mass-marketing-positive classifier.

                      Postscreen answers one YES/NO question: is this client allowed to
                      talk to a Postfix SMTP server process. It makes this ruling on
                      the basis of a single SMTP connection. Spambots rarely come back.

                      Currently, some 90% of mail is spam, some 90% from zombies. If
                      you believe that address syntax checks will catch a significant
                      fraction of that, then it would be something to consider in
                      postscreen.

                      Right now, postscreen's most effective measures are DNSBL, pregreet
                      detection (over 55% of spambots on my server trigger this defense),
                      and detecting clients that connect to the backup MX only (some 10%
                      of spambots on my server trigger this defense).

                      Everything else can easily be stopped with non-postscreen features.

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