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

Semi-OT: Exchange 2013 SMTP Callout

Expand Messages
  • Bernhard Schmidt
    Hello, this is Semi-OT but since a lot of people run Postfix before Exchange I hope to find some knowledge here. Also heads-up :-) We have a couple of Exchange
    Message 1 of 4 , Jun 14, 2013
    • 0 Attachment
      Hello,

      this is Semi-OT but since a lot of people run Postfix before Exchange I
      hope to find some knowledge here. Also heads-up :-)

      We have a couple of Exchange customers behind our frontend MX servers.
      We don't turn them up until they have configured their HBT servers to
      reject unknown recipients and we have verified SMTP callout to them.

      One customer is migrating from Exchange 2007 to Exchange 2013 and it
      seems to be impossible there. There is some documentation about
      "Recipient filtering" here:

      http://technet.microsoft.com/en-us/library/jj218660%28v=exchg.150%29.aspx

      But it does not work. Until we realized that Exchange started rejecting
      the recipients, but in DATA stage.

      mail from: <test@...>
      250 2.1.0 Sender OK
      rcpt to: <doesnotexist@...>
      250 2.1.5 Recipient OK
      data
      354 Start mail input; end with <CRLF>.<CRLF>
      test
      .
      550 5.1.1 User unknown

      This gets even worse when the mail has two recipients ... doesnotexist@
      does not exist, t1@ does...

      mail from: <test@...>
      250 2.1.0 Sender OK
      rcpt to: <doesnotexist@...>
      250 2.1.5 Recipient OK
      rcpt to: <t1@...>
      250 2.1.5 Recipient OK
      data
      354 Start mail input; end with <CRLF>.<CRLF>
      test
      .
      550 5.1.1 User unknown

      mail from: <test@...>
      250 2.1.0 Sender OK
      rcpt to: <t1@...>
      250 2.1.5 Recipient OK
      data
      354 Start mail input; end with <CRLF>.<CRLF>
      test
      .
      250 2.6.0 <MSGID> [InternalId=2740189134859] Queued mail for delivery

      This is not only unusable for Recipient validation, but will reject
      legitimate mail since you cannot reject individual recipients in DATA
      with SMTP.

      According to this threat:

      http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/91c26fd2-aa0c-4006-9326-ece609bf4f67/

      this is expected. I can hardly believe that.

      We do not have in-house experience with 2013 yet. Can anyone shed some
      light at this?

      Verification against AD (LDAP) would be an option but requires a lot
      more configuration and coordination with the customer, and some of them
      are uncomfortable opening those ports anyway.

      Bernhard
    • Tomoyuki Murakami
      ... quick and rough work-around might be smtp_destination_recipient_limit = 1 for the Postfix before E-2013. ... Unbelievable... it s harmful threat X-(.
      Message 2 of 4 , Jun 14, 2013
      • 0 Attachment
        On Fri, 14 Jun 2013 17:10:16 +0200, Bernhard Schmidt <berni@...> wrote:

        > This gets even worse when the mail has two recipients
        > ... doesnotexist@ does not exist, t1@ does...
        >
        > mail from: <test@...>
        > 250 2.1.0 Sender OK
        > rcpt to: <doesnotexist@...>
        > 250 2.1.5 Recipient OK
        > rcpt to: <t1@...>
        > 250 2.1.5 Recipient OK
        > data
        > 354 Start mail input; end with <CRLF>.<CRLF>
        > test
        > .
        > 550 5.1.1 User unknown

        quick and rough work-around might be
        smtp_destination_recipient_limit = 1

        for the Postfix before E-2013.


        > According to this threat:
        >
        > http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/91c26fd2-aa0c-4006-9326-ece609bf4f67/
        >
        > this is expected. I can hardly believe that.

        Unbelievable... it's harmful threat X-(.
      • Wietse Venema
        ... That is really awful. Your gateway will need to use smtp_recipient_limit=1 for all inbound mail (whether a RAV probe message or not). As for people who
        Message 3 of 4 , Jun 14, 2013
        • 0 Attachment
          Bernhard Schmidt:
          > This gets even worse when the mail has two recipients ... doesnotexist@
          > does not exist, t1@ does...
          >
          > mail from: <test@...>
          > 250 2.1.0 Sender OK
          > rcpt to: <doesnotexist@...>
          > 250 2.1.5 Recipient OK
          > rcpt to: <t1@...>
          > 250 2.1.5 Recipient OK
          > data
          > 354 Start mail input; end with <CRLF>.<CRLF>
          > test
          > .
          > 550 5.1.1 User unknown
          >
          > mail from: <test@...>
          > 250 2.1.0 Sender OK
          > rcpt to: <t1@...>
          > 250 2.1.5 Recipient OK
          > data
          > 354 Start mail input; end with <CRLF>.<CRLF>
          > test
          > .
          > 250 2.6.0 <MSGID> [InternalId=2740189134859] Queued mail for delivery
          >
          > This is not only unusable for Recipient validation, but will reject
          > legitimate mail since you cannot reject individual recipients in DATA
          > with SMTP.

          That is really awful. Your gateway will need to use smtp_recipient_limit=1
          for all inbound mail (whether a RAV probe message or not). As for
          people who have to expose their Exchange 2013 server to the Internet
          there is no such workaround.

          Wietse
        • LuKreme
          ... I can confirm this is how Exchange 2013 works .
          Message 4 of 4 , Jun 16, 2013
          • 0 Attachment
            On Jun 14, 2013, at 9:10, Bernhard Schmidt <berni@...> wrote:

            > According to this threat:
            >
            > http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/91c26fd2-aa0c-4006-9326-ece609bf4f67/
            >
            > this is expected. I can hardly believe that.
            >
            > We do not have in-house experience with 2013 yet. Can anyone shed some light at this?

            I can confirm this is how Exchange 2013 "works".
          Your message has been successfully submitted and would be delivered to recipients shortly.