I have also struggled with the inconsistency in the deliverymode implementation. On the one hand, for replies, we allow the data for auto-reply to be stored independent of the flag that toggles the behavior (deliverymode=reply) However for other delivery modes, we use the presence of the data as the flag that toggles the behavior, (mailForwardingAddress, deliveryProgramPath) So, with auto-reply, if you want to turn it off and then turn it back on, you keep your reply message easily. Not so with turning on/off forwarding or program delivery--when you turn them off, you do so by removing the values from the attributes.
Admittedly, there are a few kludgy ways of getting around it and for my personal use I can work with it just fine, but the UI people have a hard time creating a clean interface that mimics the underlying behavior. I don't know of a backwards compatible way of moving towards consistent, separate data/toggle deliveryModes, but it has almost bothered me enough to fork that portion of the code for my own use. Mark. Torgeir Veimo wrote: > > Ok. I still find it a bit strange to unset the mailForwardingAddress to > toggle to localdelivery. The user will still store the forwarding > address in his profile, so to unset mailForwardingAddress, I need to > copy it to some other attribute. > > I just wish there was a deliveryMode=localdeliveryonly, so that I didn't > have to remove mailForwardingAttribute, and that > deliveryMode=forwardOnly didn't even check mailMessageStore attribute. > This would be much more logical in my view. The latter shouldn't be a > problem to make default, since it was like this in qmail-ldap before > 20020501a (to my knowledge), and the former would be possible to > introduce by using a localdeliveryonly value.
