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

Strange conversion of 5.2.2 into 4.1.0 error

Expand Messages
  • Ralf Hildebrandt
    On our Postfix gateway we re using a policy query to our backend dovecot server to check if the mail would fit into the mailbox. Recently I noticed that the
    Message 1 of 5 , May 3, 2013
    • 0 Attachment
      On our Postfix gateway we're using a policy query to our backend
      dovecot server to check if the mail would fit into the mailbox.

      Recently I noticed that the hu-berlin.de Mailserver keeps retrying in
      spite of a 522 error:

      May 1 05:32:36 mail postfix/smtpd[5185]: NOQUEUE: reject: RCPT from ir2.cms.hu-berlin.de[141.20.1.148]: 552 5.2.2
      <marietta.xxxxx@...>: Recipient address rejected: Quota exceeded (mailbox for user is full);
      from=<xxxxxxxx@...-berlin.de> to=<marietta.xxxxx@...> proto=ESMTP helo=<ir2.cms.hu-berlin.de>

      May 1 06:32:38 mail postfix/smtpd[17803]: NOQUEUE: reject: RCPT from ir2.cms.hu-berlin.de[141.20.1.148]: 552 5.2.2
      <marietta.xxxxx@...>: Recipient address rejected: Quota exceeded (mailbox for user is full);
      from=<xxxxxxxx@...-berlin.de> to=<marietta.xxxxx@...> proto=ESMTP helo=<ir2.cms.hu-berlin.de>

      Their postmaster checked the logs and found this:

      Tue Apr 30 20:05:04 2013 Info: Delivery start DCID 4678286 MID 15335505 to RID [0]
      Tue Apr 30 20:05:06 2013 Info: Delayed: DCID 4678286 MID 15335505 to RID 0 - 4.1.0 -
      Unknown address error ('552', ['5.2.2 <marietta.xxxxx@...>: Recipient address rejected: Quota exceeded (mailbox for user is full)',
      '5.2.2 Contact your postmaster/admin for technical assistance. Or send a fax to: +49 (0)30 450 7570600 In any case: Please provide the following information in your problem report: This error message, time (Apr 30 20:05:06), client (141.20.1.148) and server (mail.charite.de).']) []
      Tue Apr 30 20:05:06 2013 Info: MID 15335505 to RID [0] pending till Tue Apr 30 20:06:06 2013 [Default]

      "4.1.0 - Unknown address error" -- anybody seen that before?

      Maybe a multiline-reply-problem?

      I just tried a little something:

      220 mail.charite.de ESMTP
      EHLO foo.bar
      250-mail.charite.de
      250-PIPELINING
      250-SIZE 36700160
      250-ETRN
      250-STARTTLS
      250-ENHANCEDSTATUSCODES
      250-8BITMIME
      250 DSN
      MAIL FROM:<test@...>
      250 2.1.0 Ok
      RCPT TO:<anne.xxxxx@...>
      552-5.2.2 <anne.xxxxxx@...>: Recipient address rejected: Quota exceeded (mailbox for user is full)
      552 5.2.2 Contact your postmaster/admin for technical assistance. Or send a fax to: +49 (0)30 450 7570600 In any case: Please provide the following information in your problem report: This error message, time (May 03 10:14:52), client (127.0.0.1) and server (mail.charite.de).
      QUIT
      221 2.0.0 Bye
      Connection closed by foreign host.

      That looks fairly OK.


      --
      [*] sys4 AG

      http://sys4.de, +49 (89) 30 90 46 64
      Franziskanerstraße 15, 81669 München

      Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
      Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
      Aufsichtsratsvorsitzender: Florian Kirstein
    • Bastian Blank
      ... This does not look like postfix. ... Google shows a few occurances. This seems to be a Cisco IronPort. ... Would be some pretty broken piece of software.
      Message 2 of 5 , May 3, 2013
      • 0 Attachment
        On Fri, May 03, 2013 at 10:18:43AM +0200, Ralf Hildebrandt wrote:
        > Tue Apr 30 20:05:04 2013 Info: Delivery start DCID 4678286 MID 15335505 to RID [0]
        > Tue Apr 30 20:05:06 2013 Info: Delayed: DCID 4678286 MID 15335505 to RID 0 - 4.1.0 -
        > Unknown address error ('552', ['5.2.2 <marietta.xxxxx@...>: Recipient address rejected: Quota exceeded (mailbox for user is full)',
        > '5.2.2 Contact your postmaster/admin for technical assistance. Or send a fax to: +49 (0)30 450 7570600 In any case: Please provide the following information in your problem report: This error message, time (Apr 30 20:05:06), client (141.20.1.148) and server (mail.charite.de).']) []
        > Tue Apr 30 20:05:06 2013 Info: MID 15335505 to RID [0] pending till Tue Apr 30 20:06:06 2013 [Default]

        This does not look like postfix.

        > "4.1.0 - Unknown address error" -- anybody seen that before?

        Google shows a few occurances. This seems to be a Cisco IronPort.

        > Maybe a multiline-reply-problem?

        Would be some pretty broken piece of software.

        Bastian

        --
        The man on tops walks a lonely street; the "chain" of command is often a noose.
      • Ralf Hildebrandt
        ... Yes, it s an IronPort. Their support says: Section 4.5.3.1 of RFC 2821 (4.5.3.1.10 in RFC 5321) recommends to treat a 552 response after the RCPT TO
        Message 3 of 5 , May 3, 2013
        • 0 Attachment
          * Bastian Blank <bastian+postfix-users=postfix.org@...>:
          > On Fri, May 03, 2013 at 10:18:43AM +0200, Ralf Hildebrandt wrote:
          > > Tue Apr 30 20:05:04 2013 Info: Delivery start DCID 4678286 MID 15335505 to RID [0]
          > > Tue Apr 30 20:05:06 2013 Info: Delayed: DCID 4678286 MID 15335505 to RID 0 - 4.1.0 -
          > > Unknown address error ('552', ['5.2.2 <marietta.xxxxx@...>: Recipient address rejected: Quota exceeded (mailbox for user is full)',
          > > '5.2.2 Contact your postmaster/admin for technical assistance. Or send a fax to: +49 (0)30 450 7570600 In any case: Please provide the following information in your problem report: This error message, time (Apr 30 20:05:06), client (141.20.1.148) and server (mail.charite.de).']) []
          > > Tue Apr 30 20:05:06 2013 Info: MID 15335505 to RID [0] pending till Tue Apr 30 20:06:06 2013 [Default]
          >
          > This does not look like postfix.

          Yes, it's an IronPort.

          Their support says:

          Section 4.5.3.1 of RFC 2821 (4.5.3.1.10 in RFC 5321) recommends to treat
          a 552 response after the RCPT TO command as if it was actually a 452
          response. This behaviour was intended for cases where the number of
          recipients exceeds the MTA's limits, and the idea was that the sending
          MTA should requeue the extra recipients.

          Section 6.4 of RFC 1870 contradicts this, and explicitly says that a
          552 response must not requeue the recipient. This is intended for cases
          where the message size limit is imposed on specific recipients.

          So generally, the smtp response code 552 can be used for multiple
          incidents, like the recipient count and also for the message size. In
          order to address this kind of issue on the Email Security appliance, we
          have logged a 'defect' with number ...... "Per-recipient rejection based
          on message size in response to a RCPT command", and our engineering team
          is working on an implementation which works in all cases that all
          messages get soft or hard bounced correctly without any issues.

          --
          [*] sys4 AG

          http://sys4.de, +49 (89) 30 90 46 64
          Franziskanerstraße 15, 81669 München

          Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
          Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
          Aufsichtsratsvorsitzender: Florian Kirstein
        • Viktor Dukhovni
          ... RFCs have bugs, this is one of them. In practice MTAs don t return 552 for too many recipients , and the 552- 452 mapping creates more problems than it
          Message 4 of 5 , May 3, 2013
          • 0 Attachment
            On Fri, May 03, 2013 at 02:25:15PM +0200, Ralf Hildebrandt wrote:

            > Section 4.5.3.1 of RFC 2821 (4.5.3.1.10 in RFC 5321) recommends to treat
            > a 552 response after the RCPT TO command as if it was actually a 452
            > response. This behaviour was intended for cases where the number of
            > recipients exceeds the MTA's limits, and the idea was that the sending
            > MTA should requeue the extra recipients.

            RFCs have bugs, this is one of them. In practice MTAs don't return
            552 for "too many recipients", and the 552->452 mapping creates more
            problems than it solves.

            > Section 6.4 of RFC 1870 contradicts this, and explicitly says that a
            > 552 response must not requeue the recipient. This is intended for cases
            > where the message size limit is imposed on specific recipients.
            >
            > So generally, the smtp response code 552 can be used for multiple
            > incidents, like the recipient count and also for the message size. In
            > order to address this kind of issue on the Email Security appliance, we
            > have logged a 'defect' with number ...... "Per-recipient rejection based
            > on message size in response to a RCPT command", and our engineering team
            > is working on an implementation which works in all cases that all
            > messages get soft or hard bounced correctly without any issues.

            In the interim you can use 554 5.2.2 ... which won't be misunderstood.

            --
            Viktor.
          • Ralf Hildebrandt
            ... Yeah, I ll do that instead. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München,
            Message 5 of 5 , May 3, 2013
            • 0 Attachment
              * Viktor Dukhovni <postfix-users@...>:

              > In the interim you can use 554 5.2.2 ... which won't be misunderstood.

              Yeah, I'll do that instead.

              --
              [*] sys4 AG

              http://sys4.de, +49 (89) 30 90 46 64
              Franziskanerstraße 15, 81669 München

              Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
              Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
              Aufsichtsratsvorsitzender: Florian Kirstein
            Your message has been successfully submitted and would be delivered to recipients shortly.