Email and Calendar
Email and calendar systems provide asynchronous communication and time coordination across distributed organisations. Email transmits messages between users through a store-and-forward architecture where messages traverse multiple servers before delivery, while calendar systems maintain scheduling data that synchronises across devices and shares availability information between users. These systems form the foundation of organisational communication, handling everything from routine correspondence to time-sensitive operational coordination, meeting scheduling, and resource booking.
- Mail Transfer Agent (MTA)
- Server software that routes email between systems using SMTP. The MTA accepts outbound messages from users, performs DNS lookups to locate destination servers, and delivers messages to receiving MTAs. Examples include Postfix, Exim, and Microsoft Exchange Transport.
- Mail Delivery Agent (MDA)
- Software that accepts messages from the MTA and deposits them into user mailboxes. The MDA handles final delivery, applying filters, sorting rules, and quota enforcement. Dovecot and Cyrus IMAP function as MDAs.
- Mail User Agent (MUA)
- Client software through which users read and compose email. MUAs connect to mail servers using IMAP or POP3 for retrieval and SMTP for sending. Outlook, Thunderbird, and mobile mail applications are MUAs.
- CalDAV
- Calendar Distributed Authoring and Versioning protocol extending WebDAV for calendar data access. CalDAV enables calendar synchronisation between servers and clients using the iCalendar format over HTTP.
- Free/Busy
- Calendar availability data showing when a user has scheduled commitments without revealing appointment details. Free/busy information enables meeting scheduling without exposing confidential calendar content.
Email architecture
Email delivery operates through a chain of servers that receive, route, and store messages. When a user sends an email, their MUA submits the message to an outbound MTA using SMTP on port 587 with authentication. The sending MTA queries DNS for the recipient domain’s MX records, which specify the mail servers authorised to receive email for that domain. The MTA then connects to the receiving server, typically on port 25, and transfers the message. The receiving MTA passes the message to an MDA, which deposits it in the recipient’s mailbox. The recipient’s MUA retrieves the message using IMAP (port 993 with TLS) or POP3 (port 995 with TLS).
+------------------------------------------------------------------+| EMAIL DELIVERY FLOW |+------------------------------------------------------------------+
Sender's MUA Recipient's MUA | ^ | SMTP (587/TLS) | IMAP (993/TLS) v |+------+-------+ +-------+------+| Sending | | Mailbox || MTA | | Store || | | (MDA) |+------+-------+ +-------+------+ | ^ | 1. Query DNS for MX | v |+------+-------+ SMTP (25/TLS) +-------+------+| DNS | 2. Deliver | Receiving || MX Lookup +---------------------------------->| MTA |+--------------+ +--------------+
MX Record Example: example.org. IN MX 10 mail1.example.org. example.org. IN MX 20 mail2.example.org.
Priority 10 = primary server, Priority 20 = backupFigure 1: Email message flow from sender to recipient showing MTA routing via DNS MX records
The MX record priority determines server preference. Lower priority values indicate preferred servers; sending MTAs attempt delivery to the lowest-priority server first, falling back to higher-priority servers if the primary is unreachable. Organisations with redundancy requirements configure multiple MX records with different priorities, ensuring mail delivery continues when the primary server fails.
Message storage follows one of two models. IMAP maintains messages on the server, synchronising state across multiple devices. Users accessing email from a laptop, phone, and webmail interface see consistent read/unread status, folder organisation, and message flags because all clients interact with the same server-side mailbox. POP3 downloads messages to the client device and optionally deletes them from the server, providing offline access but preventing multi-device synchronisation. IMAP dominates modern deployments because staff access email from multiple devices.
Mailbox storage and quotas
Mailbox storage consumes substantial resources in organisations with long retention practices. A single user generating 50 emails daily with average message size of 75KB accumulates approximately 1.4GB annually from sent and received messages alone. Attachments inflate this figure considerably; organisations permitting 25MB attachments see individual mailboxes reaching 10-20GB within two years. Storage planning requires understanding actual usage patterns rather than theoretical limits.
Quota enforcement prevents individual users from consuming disproportionate storage. Quotas operate at two thresholds: a warning threshold (commonly 80% of allocation) triggering user notification, and a hard limit preventing further message receipt or sending. Setting quotas requires balancing operational needs against infrastructure costs. A 5GB quota accommodates most users for 2-3 years with moderate email volume; power users handling high-volume correspondence or large attachments require 10-25GB allocations.
Quota Calculation Example:
Organisation: 150 staffBase allocation: 5GB per userPower users (15%): 15GB per user
Standard users: 128 × 5GB = 640GBPower users: 22 × 15GB = 330GBShared mailboxes: 10 × 10GB = 100GBGrowth buffer (25%): 268GB
Total planned storage: 1,338GB ≈ 1.4TBShared mailboxes and distribution lists
Shared mailboxes provide a common inbox accessible by multiple users, enabling team-based email handling without exposing individual accounts. The finance team receiving invoices at accounts@example.org uses a shared mailbox where any team member can read, respond to, and organise messages. Unlike forwarding to individual mailboxes, shared mailboxes maintain a single authoritative message store with consistent read status visible to all members.
Shared mailbox permissions separate reading from sending. Members with read access can view and organise messages but cannot send email appearing to originate from the shared address. Members with send-as permission can compose messages displaying the shared address as the sender, making responses appear to come from the team rather than an individual. Send-on-behalf permission includes the member’s identity in the sender field, showing “User Name on behalf of shared@example.org”.
Distribution lists expand a single address into multiple recipients during delivery. Sending to staff-nairobi@example.org results in individual message copies delivered to each list member’s personal mailbox. Unlike shared mailboxes, distribution lists provide no shared storage; each member receives and manages their own copy. Distribution lists suit announcements and broad communications where recipients handle messages independently.
+------------------------------------------------------------------+| SHARED MAILBOX vs DISTRIBUTION LIST |+------------------------------------------------------------------+
SHARED MAILBOX (finance@example.org)+------------------+| Shared Inbox | +-------+| |<----| User A| (read, send-as)| - Invoice 1 | +-------+| - Invoice 2 |<----| User B| (read only)| - Invoice 3 | +-------+| |<----| User C| (read, send-as)+------------------+ +-------+
All users see same inbox state, same read/unread status
DISTRIBUTION LIST (all-staff@example.org) +-------+ +----------+ +--->| User A|---->| Mailbox A|+------------+ | +-------+ +----------+| Incoming |------+| Message |------+ +-------+ +----------++------------+ +--->| User B|---->| Mailbox B| | +-------+ +----------+ | + +-------+ +----------+ +--->| User C|---->| Mailbox C| +-------+ +----------+
Each user receives independent copy in personal mailboxFigure 2: Shared mailbox maintains single message store; distribution list delivers copies to individual mailboxes
Email security layers
Email security requires multiple defensive layers because the original SMTP protocol includes no authentication or encryption. Messages transmitted over unencrypted SMTP can be read by any intermediate server, and the sender address is trivially forgeable. Modern email security adds authentication mechanisms proving sender legitimacy and encryption protecting message content in transit.
SPF, DKIM, and DMARC
Sender Policy Framework (SPF) publishes DNS records listing servers authorised to send email for a domain. When a receiving MTA accepts a message claiming to originate from example.org, it queries DNS for example.org’s SPF record and verifies that the sending server’s IP address appears in the authorised list. Messages from unauthorised servers fail SPF validation, indicating potential forgery.
SPF Record Example:
example.org. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"
Components: v=spf1 - SPF version identifier ip4:203.0.113.10 - Authorised sending IP include:_spf.google.com - Include Google's SPF (for Google Workspace) ~all - Soft fail for all other sources
Policies: +all - Pass (allows all, defeats purpose) -all - Hard fail (reject unauthorised) ~all - Soft fail (mark but accept) ?all - Neutral (no policy)SPF limitations arise from forwarding scenarios. When a user forwards email through a third-party service, the message arrives at its final destination from the forwarding server rather than the original sender’s authorised servers, causing SPF failure despite legitimate forwarding.
DomainKeys Identified Mail (DKIM) cryptographically signs messages using private keys held by the sending server. The sending MTA generates a signature covering message headers and body, then adds this signature to the message as a DKIM-Signature header. Receiving servers retrieve the corresponding public key from DNS and verify the signature matches the message content. Valid signatures prove the message passed through a server controlling the domain’s private key and was not modified in transit.
DKIM DNS Record:
selector1._domainkey.example.org. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
DKIM-Signature Header:DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=selector1; c=relaxed/relaxed; q=dns/txt; h=From:To:Subject:Date; bh=2jUSOH9NhtVGCQWNr9BrIA==; b=AuUoFEfDxTDkHlLXSZEpZj9PS9...DKIM survives forwarding because the signature travels with the message. However, mailing lists that modify message content (adding footers, altering subject lines) invalidate DKIM signatures by changing the signed data.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM by specifying how receivers should handle authentication failures and requesting aggregate reports. A DMARC policy instructs receiving servers to quarantine or reject messages failing both SPF and DKIM, closing the gap where either mechanism alone permits forgery. DMARC also requires identifier alignment: the domain in SPF or DKIM authentication must match the visible From header domain, preventing attackers from authenticating as one domain while displaying another.
DMARC Record:
_dmarc.example.org. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.org; pct=100"
Components: v=DMARC1 - Version p=reject - Policy: reject failures (quarantine, none are alternatives) rua=mailto:... - Aggregate report destination ruf=mailto:... - Forensic report destination (optional) pct=100 - Apply policy to 100% of messages sp=reject - Subdomain policy
DMARC Alignment Check: Mail From (envelope): sender@mail.example.org From (header): sender@example.org DKIM domain: example.org
SPF alignment: FAIL (mail.example.org ≠ example.org, unless relaxed) DKIM alignment: PASS (example.org = example.org) DMARC result: PASS (one alignment sufficient)Deploying DMARC requires a phased approach. Organisations first publish a policy of “p=none” to collect reports without affecting delivery, identifying legitimate sending sources that require SPF and DKIM configuration. After ensuring all authorised sources authenticate properly, the policy advances to “p=quarantine” then “p=reject” over weeks or months. Rushing to reject without identifying all legitimate sources causes business-critical email to fail delivery.
Transport encryption
TLS encryption protects email during transmission between servers. Opportunistic TLS (STARTTLS) upgrades an initially unencrypted connection to encrypted when both servers support it, but falls back to unencrypted transmission if negotiation fails. This fallback vulnerability allows attackers to force unencrypted connections through protocol downgrade attacks.
MTA-STS (MTA Strict Transport Security) eliminates fallback by publishing a policy requiring TLS for message delivery. Receiving domains publish an MTA-STS policy via HTTPS specifying that sending servers must use TLS with valid certificates. Sending servers retrieving this policy refuse to deliver over unencrypted connections, preventing downgrade attacks. MTA-STS adoption remains limited but provides meaningful protection when implemented.
MTA-STS Policy (hosted at https://mta-sts.example.org/.well-known/mta-sts.txt):
version: STSv1mode: enforcemx: mail1.example.orgmx: mail2.example.orgmax_age: 604800
DNS Record:_mta-sts.example.org. IN TXT "v=STSv1; id=20240115"Calendar architecture
Calendar systems store scheduling data as structured events with start times, durations, locations, and attendee lists. The iCalendar format (RFC 5545) provides a standard representation exchanged between calendar applications regardless of vendor. Calendar servers store these events and handle operations including creating, modifying, and deleting appointments; managing attendee responses; and publishing free/busy information.
CalDAV extends WebDAV to provide calendar access over HTTP. Clients synchronise with servers using standard HTTP methods: GET retrieves events, PUT creates or updates events, DELETE removes events, and REPORT queries for events within date ranges. This protocol-level standardisation enables interoperability between calendar clients and servers from different vendors, though proprietary extensions and inconsistent implementations sometimes complicate cross-platform scenarios.
+------------------------------------------------------------------+| CALENDAR ARCHITECTURE |+------------------------------------------------------------------+
+-------------+ CalDAV/HTTPS +------------------+| Desktop |<-------------------->| || Client | | Calendar |+-------------+ | Server | | |+-------------+ CalDAV/HTTPS | +-----------+ || Mobile |<-------------------->| | Event | || Client | | | Store | |+-------------+ | +-----------+ | | |+-------------+ CalDAV/HTTPS | +-----------+ || Web |<-------------------->| | Free/Busy | || Interface | | | Cache | |+-------------+ | +-----------+ | +--------+---------+ | Free/Busy Queries | iMIP (email) (iSchedule) | for invitations v +--------+--------+ | External | | Calendars | +-----------------+Figure 3: Calendar system architecture showing client synchronisation and external calendar federation
Meeting scheduling
Meeting invitations flow through the iCalendar Transport-Independent Interoperability Protocol (iTIP), which defines message types for scheduling workflows. An organiser creates a meeting and sends VEVENT objects with METHOD:REQUEST to attendees. Attendees respond with REPLY messages indicating acceptance, tentative acceptance, or decline. The organiser’s calendar aggregates responses and displays attendance status. Cancellations use METHOD:CANCEL, propagating to attendee calendars.
When attendees exist on different calendar systems, invitations travel via iMIP (iCalendar Message-based Interoperability Protocol), which transmits iTIP messages as email attachments. The organiser’s server sends an email containing the iCalendar VEVENT to the attendee’s email address. The attendee’s calendar system extracts the attachment and presents the invitation. Replies follow the reverse path. This email-based transport ensures cross-platform invitation delivery regardless of whether systems support direct CalDAV federation.
Free/busy queries enable scheduling without revealing calendar details. A user scheduling a meeting queries potential attendees’ calendars for availability during candidate time slots. The calendar server returns aggregate availability showing busy/free status without exposing appointment subjects, locations, or other confidential details. This separation allows efficient scheduling while maintaining calendar privacy.
Resource scheduling
Meeting rooms, vehicles, and equipment function as calendar resources with bookable schedules. Resource calendars accept or decline meeting invitations based on availability and booking policies. An auto-accept policy immediately confirms requests when the resource is available; a moderated policy queues requests for administrator approval.
Resource configuration includes capacity (room size), equipment (projector, video conferencing), and booking constraints. Constraints control maximum booking duration, advance booking limits (preventing reservations more than 30 days ahead), and permitted bookers (restricting certain resources to specific groups). These controls prevent resource hoarding and ensure equitable access.
Resource Calendar Configuration:
Resource: Nairobi Conference Room ACapacity: 12 peopleEquipment: Projector, Video conferencing, Whiteboard
Booking Policy: Auto-accept: Yes Maximum duration: 4 hours Advance booking: 30 days Permitted bookers: All staff Conflict resolution: First-come-first-served Working hours only: Yes (08:00-18:00 EAT)
Delegate: facilities@example.org (receives notifications)Platform options
Email and calendar platforms divide into self-hosted solutions providing complete control over infrastructure and data, and cloud-hosted services transferring operational responsibility to vendors. Selection involves trade-offs between operational overhead, data sovereignty, feature richness, and cost.
Self-hosted platforms
Self-hosted email requires substantial operational investment. A minimal production deployment includes redundant MTAs, spam filtering, virus scanning, webmail, and monitoring. Staff with Linux administration skills must maintain servers, apply security patches, manage storage, and troubleshoot delivery issues. The operational burden proves prohibitive for organisations lacking dedicated IT staff.
Mailcow bundles Postfix (MTA), Dovecot (IMAP), SOGo (webmail and calendar), rspamd (spam filtering), and ClamAV (antivirus) into a Docker-based deployment. A single server with 4GB RAM handles 50-100 mailboxes. The integrated package reduces component integration complexity but still requires Docker and Linux administration expertise for maintenance and troubleshooting.
Mail-in-a-Box provides a more opinionated deployment targeting administrators wanting functional email without extensive customisation. The installation script configures a complete mail server on Ubuntu, handling DNS, TLS certificates, spam filtering, and webmail. Simplicity comes with reduced flexibility; organisations requiring custom configurations find the opinionated defaults constraining.
Zimbra offers an open-source collaboration suite including email, calendar, contacts, and document sharing. The open-source edition provides core functionality; advanced features including mobile synchronisation and backup require commercial licensing. Zimbra’s integrated approach suits organisations wanting more than basic email without assembling components.
Self-hosted calendar typically integrates with the email platform. SOGo and Zimbra include CalDAV servers. Standalone calendar servers like Radicale and Baïkal serve organisations using separate email systems or requiring only calendar functionality.
Cloud platforms
Cloud email eliminates operational overhead by transferring infrastructure management to vendors. Organisations consume email as a service, paying subscription fees rather than managing servers. This model suits organisations prioritising staff time for mission delivery over IT infrastructure management.
Google Workspace (formerly G Suite) provides Gmail, Google Calendar, and integrated productivity applications. The Nonprofit edition offers discounted or free access for qualifying organisations. Gmail’s spam filtering effectiveness and calendar’s scheduling features mature after two decades of development. Data resides in Google’s infrastructure; organisations must evaluate whether Google’s data processing practices align with their data protection requirements and donor expectations. Google operates under US jurisdiction, subjecting data to CLOUD Act provisions regardless of storage location.
Microsoft 365 combines Exchange Online (email), Outlook calendaring, and Office applications. Microsoft’s nonprofit programme provides substantial discounts. Exchange’s administrative controls and compliance features suit organisations with complex requirements including litigation hold, journaling, and granular permissions. Microsoft’s infrastructure operates under the same US jurisdictional considerations as Google.
Proton Mail emphasises privacy through end-to-end encryption and Swiss jurisdiction. Messages between Proton users encrypt client-side before transmission; messages to external recipients use standard TLS. The business tier includes Proton Calendar. Proton suits organisations prioritising data protection and operating in contexts where US jurisdiction poses concerns. Feature limitations compared to Google or Microsoft include less sophisticated calendar sharing and fewer integrations.
Tutanota provides encrypted email from German jurisdiction. Like Proton, Tutanota encrypts data client-side, protecting contents from provider access. Calendar functionality remains less mature than established platforms. German jurisdiction provides GDPR enforcement without US CLOUD Act exposure.
Fastmail offers privacy-focused email and calendar from Australian jurisdiction. Fastmail emphasises standards compliance (JMAP, CalDAV) enabling client choice and data portability. Pricing lacks nonprofit discounts, making per-user costs higher than subsidised alternatives.
Federation considerations
Organisations collaborating with external partners require calendar federation enabling cross-organisation scheduling. Federation complexity varies by platform combination. Google Workspace to Google Workspace federation works seamlessly. Microsoft 365 to Microsoft 365 federation requires tenant configuration but functions reliably. Cross-platform federation (Google to Microsoft, either to self-hosted) introduces friction through inconsistent free/busy availability, delayed invitation delivery, and response synchronisation failures.
External sharing configurations balance collaboration needs against security. Permitting free/busy queries allows external partners to check availability without revealing appointment details. Full calendar sharing exposes appointment subjects and locations, appropriate only for trusted relationships. Organisations implement tiered sharing policies based on partner classification.
Field deployment considerations
Email and calendar access in field contexts faces bandwidth limitations, intermittent connectivity, and device constraints. A field office with 256kbps satellite connectivity and 50% packet loss cannot synchronise 10GB mailboxes or reliably complete CalDAV operations.
Offline capability determines field usability. Desktop clients (Outlook, Thunderbird) cache messages locally, enabling offline reading and composition with queued sending. Mobile clients vary in offline robustness; native platform clients generally outperform third-party alternatives. Webmail provides no offline access without additional browser-based caching mechanisms.
Bandwidth optimisation reduces synchronisation data volume. Limiting synchronisation to recent messages (30-90 days) dramatically reduces initial sync and ongoing bandwidth. Disabling automatic attachment download allows users to selectively retrieve large files. Compressing messages during IMAP synchronisation (where server and client support) achieves 30-60% bandwidth reduction for text-heavy messages.
Field Office Email Configuration:
Connection: 512kbps VSAT, 600ms latency, 40% reliabilityUsers: 8 staff
Recommended Settings: Synchronisation window: 30 days Attachment download: Manual (not automatic) Max attachment size: 5MB (enforce via policy) Compression: Enabled Offline cache: Enabled, 2GB per user Sync frequency: Every 30 minutes (not continuous)
Expected Bandwidth: Initial sync per user: ~200MB (30 days typical) Daily sync per user: ~15MB Total daily: ~120MB (8 users × 15MB) Monthly: ~3.6GBCalendar synchronisation proves less bandwidth-intensive than email but latency-sensitive. CalDAV operations complete through multiple HTTP round-trips; 600ms satellite latency compounds across requests, making calendar operations feel sluggish. Caching calendar data locally and synchronising periodically rather than on each operation improves responsiveness.
Implementation considerations
Organisations with limited IT capacity
Organisations without dedicated IT staff should use cloud-hosted email. The operational burden of self-hosted email exceeds the capacity of staff managing technology alongside other responsibilities. Google Workspace Nonprofit or Microsoft 365 Nonprofit provide enterprise-grade email without infrastructure management.
Platform selection for small organisations prioritises simplicity. Choose one platform and use its integrated calendar rather than mixing vendors. Ensure mobile device configuration procedures exist so staff can self-serve setup. Document shared mailbox and distribution list creation to prevent ad-hoc workarounds.
Email security configuration remains essential regardless of organisation size. SPF, DKIM, and DMARC protect the organisation’s domain from spoofing in phishing attacks targeting partners and beneficiaries. Cloud platforms simplify this configuration through administrative interfaces rather than manual DNS editing, though DNS record creation still requires access to the domain registrar.
Organisations with established IT functions
Larger organisations balance standardisation against operational flexibility. A primary platform serves most users while accommodating exceptions for specific requirements. Mergers and acquisitions commonly produce multi-platform environments requiring consolidation roadmaps.
Advanced email security features available in enterprise platforms warrant evaluation. Microsoft 365’s Defender for Office 365 and Google Workspace’s advanced protection add threat detection beyond basic spam filtering. These features provide value proportional to threat exposure; organisations facing targeted phishing attacks benefit more than those receiving only commodity spam.
Calendar resource management scales with complexity. Organisations with dozens of meeting rooms across multiple locations require systematic resource naming, consistent booking policies, and delegated administration. Integration with room display panels and booking kiosks improves utilisation visibility.
Migration planning
Email migration complexity scales with data volume and user count. A 50-user migration with 5GB average mailboxes (250GB total) completes differently than 500 users with 15GB averages (7.5TB total). Large migrations require staged approaches, migrating user cohorts over weeks rather than attempting single-cutover events.
Migration tools vary in capability and licensing. Native platform migration tools (Google Workspace Migration, Microsoft 365 migration service) handle common source platforms without additional licensing. Third-party tools (BitTitan MigrationWiz, Quest On Demand Migration) support broader source platforms and offer features including delta synchronisation and user mapping.
Coexistence during migration requires attention to calendar federation and directory synchronisation. Users on the legacy platform must schedule meetings with users already migrated; free/busy queries must function across platforms. GAL (Global Address List) synchronisation ensures all users appear in address books regardless of current platform.
Migration Planning Calculation:
Source: On-premises Exchange 2016Target: Microsoft 365Users: 200Average mailbox: 8GBTotal data: 1.6TB
Migration bandwidth: 100Mbps dedicatedEffective throughput: ~50Mbps (overhead, throttling)Daily migration window: 12 hours (outside business hours)Daily capacity: 270GB
Migration duration: 1.6TB ÷ 270GB/day = 6 days data transferAdd: Pilot group (1 week), Delta sync (2 days), Buffer (2 days)Total timeline: 3 weeks
Staged approach: Week 1: Pilot group (20 users), validate Week 2: Department A (60 users), Department B (60 users) Week 3: Remaining users (60), cutover, decommissionMX record cutover marks the point when incoming email routes to the new platform. Plan cutover during low-volume periods. Communicate the cutover date to staff and external partners. Retain the legacy system for 30-90 days post-cutover to capture messages delivered to cached MX records and handle any overlooked forwarding rules.