pradeep sharma
Active Member
Hi @twisted1919,
I have thoroughly reviewed the existing tracking domain system within Mailwizz and have identified several areas that require enhancements to meet the evolving technological standards and usage scenarios that have changed significantly over the last 2-3 years.
Current Challenges:
We can have the application to be on the same server but we need to track the main application to be served using a different hostname so that we can configure low timeouts on Tracking and high timeouts on the main application.
From a practical standpoint, these contrasting scenarios (fast-tracking vs. slow application processes) need to be addressed to optimize both the user experience and system performance.
Proposed Solutions:
I hope these detailed insights and suggestions can be considered for future updates to enhance the efficiency, security, and scalability of the Mailwizz platform.
Best regards,
Pradeep Sharma
Skype: sexy_virus2
I have thoroughly reviewed the existing tracking domain system within Mailwizz and have identified several areas that require enhancements to meet the evolving technological standards and usage scenarios that have changed significantly over the last 2-3 years.
Current Challenges:
- HTTPS Adoption: The widespread adoption of HTTPS by browsers and its enforcement by search engines like Google (which penalizes non-SSL email links) underscore the need for SSL support in all tracking domains. Nearly all modern browsers default to HTTPS, making it critical for tracking links to also be secure to maintain email deliverability and reputation.
- SSL Implementation Difficulties: Many domains are hosted on shared IPs, making it challenging to implement wildcard SSL certificates through standard web panel systems like cPanel. While cPanel and similar platforms support wildcard subdomains, they do not facilitate wildcard SSL on shared IPs. This creates a barrier for users with moderate technical skills to achieve a secure setup.
- CNAME Verification Limitations: The current CNAME-based system does not effectively verify if the application is behind a proxy or load balancer, which is a common scenario given the prevalence of cloud services and CDNs. This can lead to misconfigurations and security vulnerabilities.
- Issues with Non-SSL Tracking Domains: Achieving a wildcard SSL on an IP typically restricts you to non-SSL tracking domains. In practice, this is insufficient as most applications and browsers enforce HTTPS, rendering non-SSL tracking ineffective and potentially harmful to user trust and email effectiveness.
- Integration with Cloudflare: Using Cloudflare for DNS management and proxy tracking offers excellent protection against spam and blacklisting. However, because Cloudflare masks real DNS records and shows proxy IPs instead, it complicates the traditional CNAME-based verification process.
- Tracking Server Configuration: Currently, Mailwizz supports a CDN across the application but lacks a similar, robust system for tracking. I strongly recommend the implementation of a dedicated tracking server configuration (e.g., tracking-server.application-domain.com). This domain should internally point to the same directory and handle all tracking operations, segregating it from other application traffic to optimize performance.
- Server Timeout Settings for Tracking Servers: The fastcgi and proxy timeout settings on the tracking server should be very short (preferably under 2 seconds). This setting is crucial because when sending volumes increase, the server needs to handle a significant number of email open requests efficiently—typically, an email open involves multiple HTTP requests for CDN assets and tracking. Keeping timeout settings low ensures that the server can manage these requests without overload.
- Application Server Settings: Contrastingly, the application server should have longer timeout settings (around 300 seconds) to accommodate time-intensive operations such as live list imports and large file transfers.
We can have the application to be on the same server but we need to track the main application to be served using a different hostname so that we can configure low timeouts on Tracking and high timeouts on the main application.
From a practical standpoint, these contrasting scenarios (fast-tracking vs. slow application processes) need to be addressed to optimize both the user experience and system performance.
Proposed Solutions:
- Backend-Approved Tracking Domain Verification: Introduce an option within customer groups for backend-approved tracking domain verification. While customers can request domain tracking, actual verification and configuration would be managed by the backend admin. This ensures that domains are properly configured and secure before activation.
- Public Key-Based Signature for Verification: Transition from CNAME to public key-based signatures for domain verification. Mailwizz could embed a unique signature meta tag across its pages, similar to Google's method for web domain verification. This would allow our scripts to verify the presence of this signature on the tracking domain’s server.
- Automating SSL Configuration and Domain Alias Setup: Implement outgoing webhooks for tracking domain requests, which would automate the configuration of domain aliases and SSL certifications on our servers. This is crucial because manual setups can be prone to errors and are inefficient for scaling.
- Separate Tracking Host: Establish a separate tracking host to facilitate server restarts and configurations without disrupting the main application’s operations, thereby enhancing uptime and reliability for everyday operations.
- Signature-Based Cron Job Verification: Modify the server’s cron job processes to verify tracking domains based on the signature method rather than CNAME, enhancing compatibility with Cloudflare-proxied domains.
I hope these detailed insights and suggestions can be considered for future updates to enhance the efficiency, security, and scalability of the Mailwizz platform.
Best regards,
Pradeep Sharma
Skype: sexy_virus2