Skip to content

Architecture Design

SirrChat adopts a modular architecture to provide a flexible and extensible email server solution.

Overall Architecture

┌─────────────────────────────────────────────┐
│           Client Layer                      │
│  (Thunderbird, Outlook, Mobile Apps)        │
└──────────────┬──────────────────────────────┘


┌─────────────────────────────────────────────┐
│           Protocol Layer                    │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │  SMTP   │  │  IMAP   │  │Submission│    │
│  └─────────┘  └─────────┘  └─────────┘    │
└──────────────┬──────────────────────────────┘


┌─────────────────────────────────────────────┐
│           Authentication Layer              │
│  ┌──────────┐  ┌─────┐  ┌─────┐  ┌──────┐ │
│  │Blockchain│  │LDAP │  │ PAM │  │Custom│ │
│  └──────────┘  └─────┘  └─────┘  └──────┘ │
└──────────────┬──────────────────────────────┘


┌─────────────────────────────────────────────┐
│           Processing Layer                  │
│  ┌─────────┐  ┌──────┐  ┌─────────┐       │
│  │  Filter │  │Modify│  │  Check  │       │
│  │  (Sieve)│  │(DKIM)│  │(SPF/etc)│       │
│  └─────────┘  └──────┘  └─────────┘       │
└──────────────┬──────────────────────────────┘


┌─────────────────────────────────────────────┐
│           Storage Layer                     │
│  ┌──────────┐  ┌────────────┐             │
│  │ Database │  │  Storage   │             │
│  │(PG/MySQL)│  │(Local/S3)  │             │
│  └──────────┘  └────────────┘             │
└─────────────────────────────────────────────┘

Core Components

Protocol Handlers

SMTP Server

  • Receive and send emails
  • Support STARTTLS encryption
  • Implement rate limiting and anti-spam measures

IMAP Server

  • Email storage and retrieval
  • Folder management
  • Email search functionality
  • Support IDLE push notifications

Submission Server

  • Email submission (port 587)
  • Mandatory authentication
  • Automatic DKIM signing

Authentication Module

Blockchain Authentication

go
type BlockchainAuth struct {
    networks map[string]RPCClient
    cache    *AuthCache
}

func (b *BlockchainAuth) Verify(address, signature, message string) bool {
    // 1. Recover signer address
    // 2. Verify address match
    // 3. Check timestamp validity
    return verified
}

LDAP Authentication

  • Support Active Directory
  • Organizational Unit (OU) mapping
  • Attribute synchronization

PAM Authentication

  • System account integration
  • Support various PAM modules

Message Processing Pipeline

Incoming Mail → Anti-Spam Check → Virus Scan → Filter Rules

Store to DB ← DKIM Signing ← Content Modification ← User Rules

Storage System

Database Layer

  • User Data: Account information, quotas, settings
  • Email Metadata: Sender, recipient, subject, timestamp
  • Indexes: Fast search and retrieval

File Storage

  • Maildir Format: One file per email
  • Compression: Automatic compression of old emails
  • S3-Compatible: Scalable to cloud storage

Data Flow

Sending Email Flow

1. Client connects (SMTP/Submission)

2. Authentication verification

3. Receive email content

4. Verify recipients

5. Apply filter rules

6. DKIM signing

7. Queue processing

8. Send to target server

Receiving Email Flow

1. External server connects

2. SPF/DKIM/DMARC checks

3. Anti-spam checks

4. Apply user rules (Sieve)

5. Store to database

6. Save email file

7. Notify clients (IMAP IDLE)

Module System

Core Modules

  • auth: Authentication providers
  • storage: Storage backends
  • filter: Email filtering
  • modify: Content modification
  • check: Validation checks

Extension Points

go
type Module interface {
    Name() string
    Init(config Config) error
    Process(ctx Context, msg *Message) error
}

Performance Optimization

Concurrency Model

  • Goroutine Pools: Handle concurrent connections
  • Async I/O: Non-blocking network operations
  • Batch Processing: Database batch operations

Caching Strategy

  • Authentication Cache: Reduce blockchain RPC calls
  • User Data Cache: Frequently used data in memory cache
  • DNS Cache: Reduce DNS queries

Connection Pooling

  • Database Connection Pool: Reuse database connections
  • RPC Connection Pool: Blockchain node connection reuse

Security Design

Multi-Layer Protection

  1. Network Layer: TLS encryption
  2. Authentication Layer: Multi-factor authentication support
  3. Application Layer: Input validation, SQL injection protection
  4. Data Layer: Encryption at rest

Rate Limiting

  • Connection Rate: Prevent connection abuse
  • Sending Rate: Prevent spam
  • Authentication Attempts: Prevent brute force attacks

Scalability

Horizontal Scaling

           ┌─────────────┐
           │Load Balancer│
           └──────┬──────┘

        ┌─────────┼─────────┐
        ▼         ▼         ▼
    ┌──────┐  ┌──────┐  ┌──────┐
    │ Node │  │ Node │  │ Node │
    │  1   │  │  2   │  │  3   │
    └───┬──┘  └───┬──┘  └───┬──┘
        │         │         │
        └─────────┼─────────┘

         ┌────────────────┐
         │  Shared Storage│
         │  (Database/S3) │
         └────────────────┘

Component Separation

  • Independent Deployment: SMTP, IMAP can be scaled separately
  • Shared Storage: Multiple instances share data
  • Load Balancing: Intelligent traffic distribution

Monitoring and Logging

Metrics Collection

  • System Metrics: CPU, memory, disk
  • Application Metrics: Email throughput, latency
  • Business Metrics: User activity, storage usage

Logging System

Application Logs → Structured Output → Log Aggregation → Analytics Platform
                                        (ELK/Loki)

High Availability

Failover

  • Master-Slave Replication: Database master-slave configuration
  • Automatic Switching: Health checks and automatic failover
  • Data Backup: Regular backups and recovery testing

Health Checks

go
type HealthCheck struct {
    Database  bool
    SMTP      bool
    IMAP      bool
    Storage   bool
}

For more technical details:

Released under the GPL 3.0 License.