3 Replies Latest reply on Jul 3, 2013 8:58 PM by Ned Freed-Oracle

    Multiple emails and bitbucket in 7u5-28.21


      Good Morning,

      We recently upgraded our test email system to: 


      imsimta version

      Oracle Communications Messaging Server 7u5-28.21( 64bit (built Apr  8 2013)

      libimta.so 7u5-28.21 64bit (built 08:49:56, Apr  8 2013)

      Using /apps/msg/messaging64/config/imta.cnf (compiled)

      SunOS zmailtst 5.10 Generic_147440-01 sun4v sparc SUNW,T5140


      During testing, we have encountered an issue.  When attempting to send emails to our internal test users, this is what we see in the logs.  It appears a copy of the message is being sent to the bitbucket and to the user:


      26-Jun-2013 10:46:22.60 tcp_intranet ims-ms       EE 4 Doug.L.Maxfield@domain.com rfc822;David.D.Riddle@domain.com david-r@ims-ms-daemon <51CB0CCE.3020505@domain.com>

      26-Jun-2013 10:46:22.60 tcp_intranet bitbucket    EE 3 Doug.L.Maxfield@domain.com rfc822;David.D.Riddle@domain.com david-r+domain.com@bitbucket.zmail.domain.com <51CB0CCE.3020505@domain.com>

      26-Jun-2013 10:46:22.60 bitbucket                 DE 3 Doug.L.Maxfield@domain.com rfc822;David.D.Riddle@domain.com david-r+domain.com@bitbucket.zmail.domain.com <51CB0CCE.3020505@domain.com>

      26-Jun-2013 10:46:22.98 ims-ms                    D 4 Doug.L.Maxfield@domain.com rfc822;David.D.Riddle@domain.com david-r@ims-ms-daemon <51CB0CCE.3020505@domain.com>


      On the production server running:


      Oracle Communications Messaging Server 7u4-25.01( 64bit (built Apr 24 2012)

      libimta.so 7u4-25.01 64bit (built 17:15:21, Apr 24 2012)

      Using /apps/msg/messaging64/config/imta.cnf (compiled)

      SunOS zmail 5.10 Generic_147440-01 sun4v sparc SUNW,T5140


      We don't see that issue:


      01-Jul-2013 09:40:04.64 tcp_intranet ims-ms       EE 4 Doug.L.Maxfield@domain.com rfc822;Doug.L.Maxfield@domain.com doug-m@ims-ms-daemon <51D194C4.60408@domain.com>

      01-Jul-2013 09:40:04.65 ims-ms                    D 4 Doug.L.Maxfield@domain.com rfc822;Doug.L.Maxfield@domain.com doug-m@ims-ms-daemon <51D194C4.60408@domain.com>


      The only files that appears to change during the upgrade were the imta.cnf and internet.rules.  The imta.cnf changed from:


      ver 24:

      ! Rules for top level internet domains


      .                             $U%$H@tcp-daemon


      ver 28:

      ! Rules for top level internet domains


      .                                         $U%$H$,$H@TCP-DAEMON


      I do have an imta -rewrite -debug from each system, but it doesn't appear that I can attach them here.


      Any help would be appreciated.



        • 1. Re: Multiple emails and bitbucket in 7u5-28.21
          Ned Freed-Oracle

          Without seeing the output from imsimta test -rewrite it is impossible to say for sure what is going on, but what is clear is that those addresses

          are associated with autoreplies. Normally they are only generated when there are no other recipients available that autoreply information can

          be attached to and should not normally appear if there's a mailbox attribute on the user's LDAP entry, which there appears to be.


          I can't reproduce this behavior, which makes me think you've done something like modify the value of the DELIVERY_OPTIONS option or make

          some other configuration change. Or there may be something odd about the user's LDAP entry.


          As for why this behavior would be different, there are many cases and subcases in vacation handling, and some of them weren't handled

          correctly in 7u4. As a result  some of the logic was rewritten in 7u5. It's entirely possible and even likely that what you are seeing is a bug, but

          it's also possible that the added address is necessary to get the proper semantics to attach. There's just no way to know without seeing that

          debug output, and a copy of the associated LDAP entry as well your options file would also be helpful.


          Finally, I'll note that aside from it's appearance in the logs a bitbucket channel entry doesn't actually cause anything to happen in regards to

          actual message recipients.

          • 2. Re: Multiple emails and bitbucket in 7u5-28.21


            Thanks for the response.  If you wouldn't mind, I have attached the files that you requested for viewing.  Please let me know if you need to see anything else.





            • 3. Re: Multiple emails and bitbucket in 7u5-28.21
              Ned Freed-Oracle

              Thank you very much for supplying the logs. They provided all the information I needed to figure out what is going on.


              In summary, this is a bug introduced as a result of trying to eliminate a different problem. One of the things people sometimes do is set up a pure autoresponder, that is,

              an address that sends back a response and nothing else. Such things typically have a single maildeliveryoption set to the value autoreply.


              The problem arose when someone attempted to impose time limits on an autoresponder. Things worked fine within the limits, but outside the limits mailbox

              delivery was instantiated. This is because the limit check failure removed the bitbucket address associated with that  one delivery option, and when there are

              no options default mailbox delivery was instantiated.


              The (obvious) solution was not to remove the address in this case. There was supposed to be a check to make the nonremoval specific to this case, but it wasn't

              quite right, with the result that the address didn't get removed when there was another active option and hence the address wasn't needed. And this wasn't

              noticed since the thing our tests focus on is the resulting message(s), not log entries, and of course bitbucket channel addresses don't produce messages.


              Anyway, this is now:




              I've already coded and tested the necessary fix, but as to what patch it will be released in, that's not my call. (I'm in development, not sustaining or support.)

              So at this point your next step is contact support regarding the bug.


              Sorry this happened, and thanks again for the report.