GoogleApps + Postfix + Fetchmail (preparation)

Why all this

So, again about the eternal, about the organization of the mail server in the organization of medium size. It would seem that this is complicated, you take any Linux distibutive, put any time-tested package of mail programs (MTA, MDA, antivirus, antispam) and forget about it. But instead of having a sweet life, you immediately receive spam flows both at the input and at the output (if the health of your internal network leaves much to be desired). And at the same time, user complaints about spam, non-sending mail, etc. System administrators-beginners can give up here. But, there is a simple and quite elegant way out of this situation - to call Big Brother for help, that is Google, and hide behind his broad shoulders. In the proposed solution, Google services are used as backup mail storage, a spam filter and an antivirus, which they can handle and do fine,
This path may also be of interest to organizations engaged in the transition to open source software. Indeed, why pay for an extra Windows license and an Office license on an employee’s computer if the same functionality can be arranged on free software (we will work with mail using Mozilla ThunderBird and the address book on LDAP). In addition, this is not the only savings item; we will not forget about saving on anti-virus and anti-spam software. I am not talking about the increasing reliability of the mail system - the number of calls about problems with the mail has been significantly reduced.
One of the most important ingredients of our recipe is a domain name and the ability to change its DNS records. I think, in most cases, this issue is resolved, otherwise what kind of organization is it that sends mail from public mailboxes. And we need a domain name to change the MX record and pass our mail through Google, which has interesting services for this. For medium-sized organizations, a free package is enough for the eyes, even if you are not worried about the restriction on 50 accounts, there is also a mechanism for mail aliases that can be created up to 30 pieces per account. Total number of valid mailbox names is 30 * 50 = 1500. And this is something.

Where to begin

And it’s worth starting with determining your desires. In many ways, of course, they are dictated by the historical development of the company's IT infrastructure, but I think that the option proposed below will have sufficient generality.
So, we divide users into groups:

• 1. Office users are regular users of the head office local area network.
• 2. Users at branch offices are usually external small groups of users of an organization of 5–20 people, united in their local network.
• 3. Mobile users are users of the organization who should be able to access their mail from anywhere using the most flexible and reliable technology possible.
• 4. External users - users of other organizations, contractors of our mail system.

This division allows us to distinguish between the requirements for the mail system. It is also worth immediately thinking about the mail storage scheme - will the received messages be deleted from the server by users, or will the mail server contain the entire history of correspondence. Depending on this, it is worth considering the storage or backup system of the mail archive, the access protocol opened for mail clients (POP or IMAP), whether it is necessary to open the web interface to mailboxes for users, or will mail agents be used. It’s worthwhile to think over these issues in advance and coordinate them with existing business requirements.
For my organization, a system with centralized storage of all organization mail, using email clients (ThunderBird) and backup access to mail via the web interface (IlohaMail) came up. For scalability, I had to store the mail directory on the LVM partition so that I could connect new drives to increase the size of the storage.

General solution scheme

The local mail server is configured with authorization over all protocols (POP or IMAP, SMTP). Its task is to deliver local mail and relay outgoing to the provider's mail server. External mail for the domain is collected through Fetchmail from Google’s servers. The user base lies on the Ldap server, which can be taken out separately. Access to send and receive letters from the local mail server is restricted to authorized users, which completely excludes the possibility of spammers sending us mail.
The scheme provides for the presence of mobile mail users who communicate with the internal Postfix server through the forwarded POP3 or IMAP ports. For known ip-addresses (branches) may be open SMTP access to the internal server.