Quick question. Can you run Calendar 7u1 CalDAV and Convergence on the same Glassfish server? Messaging Server (64bit) 7u4 (7.4-19.01) from CommsR7u1-solaris_sparc-Septbuild with Patch 137204-19 Comms DSsetup 6.4 (6.4-6.03) from CommsR7u1-solaris_sparc-Septbuild Calendar Server (CALDAV) 7u1 (7.1-1.11) from CommsR7u1-solaris_sparc-Septbuild Convergence 2 (2.0-0.06) from CommsR7u1-solaris_sparc-Septbuild
Hi all, We've run into the problem of no maildeliveryoption=mailbox causing mail to go missing. It seems the interaction between maildeliveryoption and the forwarding options from UWC have still not been ironed out in IWC1 or IWC2 (I've opened SR 3-2680246061 for anyone interested). We have a user who had all their incoming mail get sent to bitbucket for 2 weeks over the Christmas holidays. I've done some testing, trying to replicate this behaviour. It seems that mail addressed to a user will be sent to bitbucket under the following conditions: 1) mailuserstatus=autoreply 2) no other mailuserstatus values 3) the current date is between vacationstartdate and vacationenddate The autoreply still fires and the sender gets the recipient's vacation message, but the original message is then sent to bitbucket. No DSN is generated. If the current date is outside of the vacation start/end dates, the MTA seems to correctly fall back to the default delivery option (as defined in options.dat). We're a bit behind on our MTA updates, currently running 7u2-7.02. Perhaps this has been fixed in a more recent version, but I can't find any mention of a bug specific to this problem so I'm guessing not.(Continue reading)
We submitted a bug report about this for the Convergence UI, but I think there has been some confusion in the problem statement in SR 3-2680246061 and therefore in the subsequent bug report 7010066. In the SR and bug, I thought we were talking about forwarding, and it did not make any sense at all. But what you say here about autoreply makes more sense. The MTA's behavior is that if maildeliveryoption is not set, then it default to delivering the message (or, more exactly, as Ned said previously - below). If you have maildeliveryoption set to only autoreply, then that is all it will do. Kelly On 1/4/2011 12:21 PM, Andrew Culver wrote: > Hi all, > > We've run into the problem of no maildeliveryoption=mailbox causing mail to go > missing. > > It seems the interaction between maildeliveryoption and the forwarding options > from UWC have still not been ironed out in IWC1 or IWC2 (I've opened SR > 3-2680246061 for anyone interested). > > We have a user who had all their incoming mail get sent to bitbucket for 2 > weeks over the Christmas holidays. > > I've done some testing, trying to replicate this behaviour. It seems that mail(Continue reading)
Hi Kelly, Thanks for looking into my SRs. I believe there are two issues here. The first is that by toggling the forwarding options a certain way in IWC a user can remove their maildeliveryoption attributes (SR 3-2680246061). At the time I submitted that SR, I was only able to replicate that portion of the problem. I wasn't able to replicate the user's mail going to the bitbucket. The second problem is with the messaging server not following the default when autoreply is set. When I first tested this, I couldn't duplicate the problem because I just manually set maildeliveryoption=autoreply with and ldapmodify without adjusting the vacationenddate. After properly setting up an active vacation message in IWC, my mail then went to bitbucket. I've opened SR 3-2688038291 for this. With maildeliveryoption=autoreply but no active vacation message (current date > vacationenddate), the MTA does follow the default from option.dat. If the vacation message is active, the MTA processes that and ignores the default. This seems like a bug to me. I believe that the first problem is a bug in IWC and the second problem is a bug in the Messaging Server, even though fixing the first should prevent the second from happening by accident. It doesn't matter to us which one would solve the problem as long as our users don't miss any more mail. :) Another thought. Although I don't fully understand the syntax of the DELIVERY_OPTIONS variable, it seems that the last line is trying to say(Continue reading)
FYI, Support referred me to http://wikis.sun.com/display/CommSuite/Messaging+Server+and+Calendar+Server+LDAP+Object+Classes+and+Attributes#MessagingServerandCalendarServerLDAPAttributes-mailDeliveryOption which notes that this behaviour is expected, so not considered a bug. Just thought I'd relay that message here for anyone else who runs into this problem. I also found the documentation for the DELIVERY_OPTIONS syntax at http://msg.wikidoc.info/index.php?title=Delivery_options_MTA_option&printable=yes and it doesn't seem possible to create a workaround by modifying the delivery options. Andrew Andrew Culver wrote: > Another thought. Although I don't fully understand the syntax of the > DELIVERY_OPTIONS variable, it seems that the last line is trying to say > anything else except autoreply should go to bitbucket. Does this > "anything else" not work correctly if autoreply is the only option? > > DELIVERY_OPTIONS=\ > #*mailbox= <at> $X:$M$_+$2S%$\$2I <at> ims-ms-daemon,\ > #&members=*,\ > #*native= <at> $X.lmtpnative:$M,\ > #*unix= <at> $X.lmtpnative:$M,\ > #/hold=$L%$D <at> hold,\ > #*file= <at> $X.lmtpnative:+$F,\ > #& <at> members_offline=*,\ > #program=$M%$P <at> pipe-daemon,\ > #forward=**,\(Continue reading)
Hey its my favorite MTA feature again!
Here's my workaround:
#*^!autoreply=$M%$\$2I$_+$2S <at> ims-ms-daemon
or, for LMTP
#*^!autoreply= <at> $X.LMTP:$M%$\$2I$_+$2S <at> lmtpcs-daemon
The end result is an account with maildeliveryoption=autoreply will
now reply AND file in mailbox even if they don't have mailbox set. Be
warned this removes the ability for an account to autoreply and discard
via MTA options (but you can still do the discard with a sieve on the
account, users are great at doing that by mistake too).
I'll again add the disclaimer that while this works in my versions
of messaging, doing so is discouraged. It may break or otherwise work
unpredictably in the future if things change in the MTA code. As soon
as the web UI is fixed you'll want to fix up any bad LDAP entries and go
back to the right delivery_options.
On 01/04/2011 02:24 PM, Andrew Culver wrote:
> FYI,
> Support referred me to
> http://wikis.sun.com/display/CommSuite/Messaging+Server+and+Calendar+Server+LDAP+Object+Classes+and+Attributes#MessagingServerandCalendarServerLDAPAttributes-mailDeliveryOption
> which notes that this behaviour is expected, so not considered a bug.
> Just thought I'd relay that message here for anyone else who runs into
> this problem.
>
> I also found the documentation for the DELIVERY_OPTIONS syntax at
> http://msg.wikidoc.info/index.php?title=Delivery_options_MTA_option&printable=yes
(Continue reading)> We've run into the problem of no maildeliveryoption=mailbox causing mail > to go missing. > It seems the interaction between maildeliveryoption and the forwarding > options from UWC have still not been ironed out in IWC1 or IWC2 (I've > opened SR 3-2680246061 for anyone interested). The semantics are actually pretty simple. The maildeliveryoption attribute is a list of names. The meaning of those names, as well as the default for when no maildeliveryoption attribute is present, is specified by the MTA's DELIVERY_OPTIONS option. The usual setting of that option provides a number of names, including: mailbox - deliver to user mailbox autoreply - activate autoreply handling members - forward to group membership The default when no attribute is present is "mailbox" for users, "members" for groups. > We have a user who had all their incoming mail get sent to bitbucket for > 2 weeks over the Christmas holidays. FWIW, the use of the bitbucket channel is more or less an artefact of how the MTA handles aliases and autoreplies - an alias has to expand to *something* or there's an error, but autoreply is done using Sieve, which doesn't require an actual recipient address of it's own. So the autoreply name turns on autoreply processing but has a bitbucket channel address as the destination to prevent nonsense errors from being generated.(Continue reading)
> Hi Kelly, > Thanks for looking into my SRs. > I believe there are two issues here. The first is that by toggling the > forwarding options a certain way in IWC a user can remove their > maildeliveryoption attributes (SR 3-2680246061). At the time I submitted > that SR, I was only able to replicate that portion of the problem. I > wasn't able to replicate the user's mail going to the bitbucket. > The second problem is with the messaging server not following the > default when autoreply is set. See my previous message. This is not how it works. > When I first tested this, I couldn't > duplicate the problem because I just manually set > maildeliveryoption=autoreply with and ldapmodify without adjusting the > vacationenddate. After properly setting up an active vacation message in > IWC, my mail then went to bitbucket. I've opened SR 3-2688038291 for this. > With maildeliveryoption=autoreply but no active vacation message > (current date > vacationenddate), the MTA does follow the default from > option.dat. This, as I previously explained, is actually a bug. > If the vacation message is active, the MTA processes that > and ignores the default. This seems like a bug to me.(Continue reading)
How can I determine who is using shared folders (if possible w/ sharing and permission, details) and who is using direct delivery (e.g. the xxx+folder@...). Thanks, Bill
Wondering still. Is it catastrophic (will I lose data)? On Thu, Dec 16, 2010 at 5:46 PM, <spacegoose@...> wrote: > What happens as you try to move a user to a partition that fills up as > you are moving? > > Thanks, > Bill >
RSS Feed7 | |
|---|---|
10 | |
8 | |
10 | |
5 | |
32 | |
5 | |
4 | |
5 | |
7 | |
3 | |
9 | |
19 | |
37 | |
45 | |
31 | |
37 | |
28 | |
56 | |
9 | |
36 | |
28 | |
13 | |
47 | |
17 | |
71 | |
39 | |
46 | |
73 | |
27 | |
49 | |
59 | |
24 | |
84 | |
47 | |
31 | |
40 | |
70 | |
51 | |
76 | |
60 | |
54 | |
57 | |
112 | |
81 | |
87 | |
118 | |
81 | |
129 | |
82 | |
108 | |
112 | |
80 | |
69 | |
78 | |
79 | |
95 | |
124 | |
259 | |
144 | |
119 | |
125 | |
136 | |
118 | |
73 | |
77 | |
73 | |
103 | |
116 | |
100 | |
122 | |
156 | |
177 | |
250 | |
174 | |
163 | |
124 | |
164 | |
172 | |
142 | |
243 | |
329 | |
188 | |
285 |
