So here's the status of the queue. i'm moving the aliasing stuff (what currently exists of it) out of the smtp agent. i say what little there is because there used to be an aliasing agent that would take care of system aliases for you. that wasn't particularly a good solution as it meant that you had to accept mail for all emails even if there was no valid alias for that user. for example: assume i host feltonline.com. if a mail comes in for [EMAIL PROTECTED] i have to accept the mail, then wait for the aliasing agent (which never got scrubbed) to properly determine if patrickfelt really exists and who that is.
with it all in the queue, available as a queue command, any queue agent can determine if an account is local or not, and who the end destination should be. this should add a fair amount of flexibility into the architecture. i've currently got the system reading out the configuration data from the store and loading it up. what remains is actually searching those arrays for the data that is needed and returning local or remote. then changing smtp to use that code instead of the mess that it currently does. once both of these are done, aliasing will work. a side effect is that virutal hosting comes out of this too. it has taken me a little longer to get going as i've had to step away in large chunks of time to take care of some pressing matters, but it shouldn't be much longer before that particular task is done. as for the release schedule, once the devs are fairly sure that mail processing works, i think we should migrate it to trunk there and get some serious testing going, and take the supported route (this coming from the self proclamed bug man ;) ). pat Alex Hudson wrote: > Hey everyone, > > It's been a while since I updated this list on progress so far. M3 keeps > getting pushed back it seems, and this is mostly because of the MDB > removal: basically, it's taken longer to do this than we expected. This > is a combination of us not having spent enough time on the task, and the > task being bigger than we thought, I think. > > But I'd like to talk a bit about the progress that has been made - > because we've come an awful long way, and people probably don't yet > realise that :) > > MDB has been completely removed from all but five agents, and only two > (rules and mailprox) have much of any significance left. We're in the > home straight with this, now. > > What's a bit of a mess is the order in which we've done some work. Our > M4 targets - CalDAV and i18n support - are underway, and virtually in > the state I hoped they might be for M4. However, some of our M3 targets > - updated bongo-manager, cli tools - haven't even started yet (I _think_ > we have some support for virtual domains and mail aliasing now - Pat, do > you want to talk about your queue work?). > > So, I'm thinking that we'll change M3 and M4 around a little bit, > because otherwise we may as well skip M3 - the gap between 3 and 4 is > going to be pretty small even with this switch around. I'm thinking M3 > will basically be another developer release to test our MDB-less > configuration, rather than the better supported release I had previously > planned. > > The big picture would be that we punt mailprox and rules to M4, as well > as the bongo-manager rework, bring forward CalDav and i18n work. The > mailprox (mail proxy) probably doesn't need much work, but the rules > agent probably needs to be heavily re-worked to make any sense. > > The route I have in mind is basically this: > > * First release of remove-mdb (which will become M3) which has > mailprox and rules turned off, which will be pretty rough and > ready. I intend this to happen within the next week, and will be > purely for people to try basic mail sending/receiving > operations. > * Second release of remove-mdb. At this point, we'll bring the > branch back onto trunk, and would happen once we've sorted out > the egregious issues from the first release, and have it working > the way it used to. > * Third release, which would bring across the caldav work in some > form. This would be more or less M3. > > Once we get past M3, it's going to be a much quicker ride to 1.0 than it > has been previously: all of the big ticket stuff will have been done, > and we'll be then completing features and polishing rather than any more > large-scale work. If we can get a time table like this: > > M3 Mid-September > M4 End of October > M5 Christmas > > I think we'll be in very good shape. M5 will basically be 1.0: the > milestones after that are security and reliability milestones, so while > we still wouldn't proclaim Bongo is production ready, I think a lot of > people will want to use it. > > And what better Christmas present? :D > > Cheers, > > Alex. > > > _______________________________________________ > Bongo-devel mailing list > [EMAIL PROTECTED] > https://mail.gna.org/listinfo/bongo-devel > > _______________________________________________ Bongo-users mailing list [email protected] https://mail.gna.org/listinfo/bongo-users
