The test helper's mock email server was missing the getRateLimiter() method
that was added during the rate limiting feature implementation. This caused
all SMTP tests to fail with "getRateLimiter is not a function" error.
Changes:
- Add getRateLimiter() method to mock email server that returns a mock rate limiter
- Update mock rate limiter method signatures to match actual implementation
- Fix TypeScript type issue with auth options by adding explicit casting
- Add test.dns-manager-creation.ts to verify DNS record creation
- Test MX, SPF, DMARC, and DKIM record registration
- Verify records are stored in StorageManager
- Update readme.hints.md with DNS architecture refactoring notes
- Rename DnsValidator to DnsManager to better reflect its expanded responsibilities
- Move DNS record creation logic from UnifiedEmailServer to DnsManager
- Add ensureDnsRecords() method that handles both validation and creation
- Consolidate internal DNS record creation (MX, SPF, DMARC) in one place
- Keep DKIM key generation in UnifiedEmailServer but move DNS registration to DnsManager
- Update all imports and tests to use DnsManager instead of DnsValidator
- Improve code organization and discoverability of DNS functionality
- Add StorageManager with filesystem, custom, and memory backends
- Update DKIMCreator and BounceManager to use StorageManager
- Remove component-level storage warnings (handled by StorageManager)
- Fix list() method for filesystem backend
- Add comprehensive storage and integration tests
- Implement DNS mode switching tests
- Complete Phase 4 testing tasks from plan
- Add unit tests for DNS route generation and socket handler creation
- Add unit tests for email route generation in both modes
- Add integration tests for combined DNS and email configuration
- Test TLS handling differences between email ports
- Verify socket-handler vs traditional forwarding mode behavior
- All tests pass without requiring actual port binding
- Mark implementation plan as complete with full test coverage
✅ All integration tests passing
- Route-based forwarding with priority: 5/5 scenarios
- CIDR IP matching: 4/4 test cases
- Authentication-based routing: 3/3 scenarios
- Pattern caching performance: Working
- Dynamic route updates: Working
The match/action pattern implementation is now complete and fully functional.
Replace legacy domain-rule based routing with flexible route-based system that supports:
- Multi-criteria matching (recipients, senders, IPs, authentication)
- Four action types (forward, process, deliver, reject)
- Moved DKIM signing to delivery phase for signature validity
- Connection pooling for efficient email forwarding
- Pattern caching for improved performance
This provides more granular control over email routing with priority-based matching and comprehensive test coverage.
