This is a discussion on Re: ISP converting to automation with LDAP within the mailing.postfix.users forums, part of the Mail Servers and Related category; I appreciate the info. Devdas Bhagat wrote: >On 07/06/05 10:02 -0400, Ron Wheeler wrote: > > &...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
I appreciate the info.
Devdas Bhagat wrote: >On 07/06/05 10:02 -0400, Ron Wheeler wrote: > > >>I am really having trouble with the idea that there are 50 ways to setup >>an ISP using Postfix. I am almost sure that 90-95% of Postfix >>installations could be almost exactly the same and the user's would have >>the same or better level of satisfaction as they do now. >> >> > >This depends on what the other 5 to 10% of Postfix installations need. >Then there are also sites migrating from other MTAs. Enforcing a >specific schema requires workarounds for its limitations. > > > I am not suggesting enforcing anything or restricting possibilities. I want a "best practice" howto for the 90% >>There has to be a consensus by now about what constitutes an appropriate >>core setup for an ISP or major corporation using LDAP, Postfix, IMAP and >>SASL/PAM. >> >> > >Ok, basic issues: >Postfix does not insist on any particular LDAP schema element names. >Postfix uses the abstract concept of a "map" to look up information. >This lookup is basically a query with a specified key and zero or more >responses. This query is basically an implementation of a policy statement. > >Quite a few ISPs prefer to use a RDBMS (or MySQL) to store the account >information. > > > Not trying to stop anyone from going their own way. Just want a concensus about what is the "best" way to set this up. You have raised a key point that requires expert discussion. MySQL vs LDAP. My natural inclination as a old database expert from the 1980's is to go SQL. However, LDAP seems to have a good following and "seems" to be some sort of standard for directory implementation. Having one Active Directory under my control, I can see how easy LDAP and flexible can be with the right tools. I know that it can be made to play well with Linux. I have already expressed by problems with the OpenLDAP schema set. I would like to see the group here have a run at creating a Postfix-Imap schema for virtual hosting. This would be a big simplification of the current state. What I would like to know is "What would the brightest and most experienced guys here do if they had to do it all again? MySQL or LDAP?" Why? What is the minimum schema required to get the whole ISP set up. >>We seem to have narrowed the web server down to 2 (IIS and Apache hold >>95% of the market between them) and we are all happy about that. The >>shakeout in development architectures is still a long way off but that >>is another story. >> >>I understand that each ISP or IT department will want to create an USP >>by adding features and applications but just as I can do this with >>Microsoft Server, I should be able to get the core functionality up and >>running with a set of open source packages glued together by a uniform >>set of configuration files that look almost the same as everyone elses. >> >> > >Your configuration files look the same as everyone elses. The difference >is that your query may be different from someone elses. The query is a >policy statement. Policies vary across organisations. > > > The policies should not vary very much. There are certain "best practices" that should be followed in controlling e-mail and providing secure IMAP services to clients. The basic set of policies that a system administrator should apply should be specified and optional variances to account for local taste and government regulations should be described. For example No one should run an open relay. SMTP authorization should be done in a certain way. If the president is the only one that is allowed to use SMTP relay service then you are on your own and you will have to read the documentation. >>Then, augment the LDAP schema and basic configuration to support my >>value added applications. >> >> >> >Postfix does not care about the schema. Postfix only cares about the >results. It is upto the organisation to decide on a schema according to >its requirements and policies. > > > This is where the whole thing breaks down and Microsoft wins the TCO argument. We are all reinventing the wheel and then showing up here for help. >>How many ways are there to write an email address? It is not like the >>old days with sendmail supporting uucp and 50 other address schemes. >> >> >> >You are confusing the data with the data store. > > > Possibly but I hope my point was still clear. We are in the 21st century, we are no longer building toys for experimenting with ways of doing things. That was fine in the early days of the Internet. Now we need to get it organiozed and make it easy to build a properly constructed server without having to become experts in each piece. The software is strong enough, it is the administrative structures around the software that is lacking in strength. >>How many ways are there to support virtual domains? >> >>Maybe we can start with a comparison chart of different virtual domain >>architectures. >> >> >> >The clearest example of a Postfix lookup that I can think of right now >is a SQL query. > >SELECT <information> >FROM <store> >WHERE <condition> AND <condition> AND ... > > > But is that the "best" way to handle IMAP? >>What about IMAP - what is the big difference between the 3 main contenders? >> >> >> >UW-imap: Uses mbox files, is good for a small site with small mailboxes >and few users. Hard to use with virtual accounts. > >Courier-imap: Uses maildir, is fantastic at scaling up, and quite good >at virtual accounts. > >Cyrus-IMAP: Uses an indexed MH store, gives up the ability to use >standard Unix tools in return for higher performance. Has its own user >database. > >There are also Dovecot, binc-imap, and the various pop3d servers out >there. > > > Excellent input. This is a very good start to a "best practice". Nice set of choices and a reasoned set of criteria for making the choice. I would like to hear from others on this topic. >>If we can do this, there will be an incentive for open source projects >>like web service support for administrative tasks and more >>administrative tools. The current "every man for himself" environment is >>extremely costly and contributes to Microsoft's ability to claim a lower >>TCO than Linux. >> >> >> >One size does not fit all. > >I recommend understanding the Postfix system first. As Victor said, >keeping things simple is best. Come up with a design, and then try to >simplify it. Multiple domains are trivial to do, once you understand how >all your components interact. > >Your basic mail flow is: >Outside world --> Postfix ---> Mail store --> POP3/IMAP server ---> User. > >Now, Postfix needs to query the database to decide on where to store the >mail. The POP3/IMAP server has to query the database to 1) Authenticate >the user, 2) Authorize the user, and 3) To obtain the location where the >mail is stored by Postfix. > >Figuring out the specific queries required by the database is left as an >exercise for the reader. > > > What makes the reader qualified to do this? We all have different backgrounds and experiences. I have a lot of experience as a system administrator and a M.Sc in Computer Science. I am not worried about getting this done. I am concerned about the fact that it is much hard than it needs to be and there is an expectation that each person will have to go though this struggle for the good of their souls. I have real work to do and this is not what brings in the revenue. I suspect that most system administrators are in the same boat and we just need to get this set up quickly and move on. We would like to have the guys that really know, set up a series of best practice documents that we can read, and follow. Where we can not follow them, then we will have to work out the variances - change our policies to match the best practices or modify our implementation of best practices. >Oh, and please do not top post to a mailing list. > >Devdas Bhagat > > > > |