Email: Difference between revisions
No edit summary |
|||
Line 78: | Line 78: | ||
* <code>include:_spf.example.com</code> tells receiving mail servers to consider the SPF record of <code>_spf.example.com</code> as part of this domain’s SPF record. Replace <code>_spf.example.com</code> with the SPF record of your email service provider or your own mail server. | * <code>include:_spf.example.com</code> tells receiving mail servers to consider the SPF record of <code>_spf.example.com</code> as part of this domain’s SPF record. Replace <code>_spf.example.com</code> with the SPF record of your email service provider or your own mail server. | ||
* <code>~all</code> is a soft fail for mechanisms not specified in the record. It advises recipients to accept mail whether it passes the SPF check or not but to mark it as suspicious. Use <code>-all</code> for a hard fail if you’re sure all legitimate sources are listed. | * <code>~all</code> is a soft fail for mechanisms not specified in the record. It advises recipients to accept mail whether it passes the SPF check or not but to mark it as suspicious. Use <code>-all</code> for a hard fail if you’re sure all legitimate sources are listed. | ||
<blockquote> | |||
For the HeatSync Labs wiki server, we know the entire domain (heatsynclabs.wiki) is dedicated to a single purpose, so we can go pretty hardcore. I could specify the only host to be even more extreme, but I'll just use the domain since it only has a single host. | |||
</blockquote> | |||
<pre> | |||
v=spf1 a:heatsynclabs.wiki -all | |||
</pre> | |||
=== DKIM (DomainKeys Identified Mail) === | === DKIM (DomainKeys Identified Mail) === |
Revision as of 17:17, 2 April 2024
Links
- Reverse DNS on Lightsail: https://docs.aws.amazon.com/lightsail/latest/userguide/amazon-lightsail-configuring-reverse-dns.html
GPT Recommendation
For a low-volume mail server setup on Debian 12 (Bookworm) that’s primarily used for sending outbound messages from a local instance of MediaWiki, you can opt for a simple yet reliable software stack. The primary goal here is to ensure that emails sent by MediaWiki (e.g., account creation confirmations, notifications) are delivered reliably without setting up a full-fledged mail receiving infrastructure.
Software Stack:
- Postfix: A widely used, open-source Mail Transfer Agent (MTA) that can handle sending outbound emails. It’s relatively straightforward to configure for sending emails and can be secured to prevent unauthorized use.
- Optional: Dovecot: If you ever decide to handle receiving emails (for bounces or administrative purposes), Dovecot is a secure IMAP and POP3 server that integrates well with Postfix. However, for your described use case, Dovecot may not be necessary.
- Certbot (Let’s Encrypt): For securing your connections with TLS, using Certbot to obtain a free SSL certificate from Let’s Encrypt is recommended, especially if you’ll be sending sensitive information.
Basic Setup Instructions:
1. Install Postfix
Update your package list:
sudo apt update
Install Postfix:
sudo apt install postfix
During installation, you’ll be prompted for some basic configuration:
- General type of mail configuration: Choose “Internet Site”.
- System mail name: This should be your domain name (e.g., example.com).
2. Basic Configuration
Edit the main Postfix configuration file
/etc/postfix/main.cf
to ensure it’s set up for sending mail correctly. For a basic setup, you might only need to adjust or verify a few lines:inet_interfaces = loopback-only myhostname = example.com mydestination = mynetworks = 127.0.0.0/8
inet_interfaces
set toloopback-only
ensures Postfix only listens on the localhost interface.myhostname
should be your server’s FQDN.- Clear
mydestination
to prevent Postfix from considering itself the final destination for mail. mynetworks
restricts which IPs can send mail through this server, set it to localhost only for security.
Reload or restart Postfix to apply the changes:
sudo systemctl restart postfix
3. Configure MediaWiki for Email
Ensure MediaWiki is configured to send email through your local Postfix installation. This is usually done in MediaWiki’s LocalSettings.php
:
$wgSMTP = [
'host' => 'localhost',
'IDHost' => 'example.com',
'port' => 25,
'auth' => false,
];
Adjust example.com
to match your domain.
Security and Sending Limits
- IP and Domain Reputation: Ensure your server’s IP and domain have a good reputation. A new IP or one previously used for spam can negatively affect deliverability.
- Reverse DNS: Set up reverse DNS for your server’s IP to match your domain. This is often done through your hosting provider’s control panel.
- SPF Record: Add an SPF record to your domain’s DNS to authorize your server to send email on behalf of your domain.
- DKIM and DMARC: For a low-volume server used as described, DKIM and DMARC are optional but recommended for improving email authenticity.
This setup is sufficient for sending outbound emails from a MediaWiki instance. Remember to monitor your server for any abuse and ensure that it’s not configured as an open relay. For more extensive email needs in the future, consider additional configurations and possibly using external SMTP services designed for high deliverability.
SPF, DKIM, DMARC
Sure, here’s a simplified overview of setting up SPF, DKIM, and DMARC through DNS records. Note that specific values can vary based on your email sending service (e.g., Google Workspace, Office 365, SendGrid, etc.) or if you’re sending emails directly from your own server.
SPF (Sender Policy Framework)
Purpose: SPF allows the owner of a domain to specify which mail servers are permitted to send email on behalf of that domain.
DNS Record Type: TXT
Example Value:
v=spf1 include:_spf.example.com ~all
v=spf1
specifies the SPF version.include:_spf.example.com
tells receiving mail servers to consider the SPF record of_spf.example.com
as part of this domain’s SPF record. Replace_spf.example.com
with the SPF record of your email service provider or your own mail server.~all
is a soft fail for mechanisms not specified in the record. It advises recipients to accept mail whether it passes the SPF check or not but to mark it as suspicious. Use-all
for a hard fail if you’re sure all legitimate sources are listed.
For the HeatSync Labs wiki server, we know the entire domain (heatsynclabs.wiki) is dedicated to a single purpose, so we can go pretty hardcore. I could specify the only host to be even more extreme, but I'll just use the domain since it only has a single host.
v=spf1 a:heatsynclabs.wiki -all
DKIM (DomainKeys Identified Mail)
Purpose: DKIM provides a way to validate a domain name identity that is associated with a message through cryptographic authentication.
Configuration: You’ll generate a public/private key pair. The public key goes into your DNS records, and the private key is used by your outgoing email server to sign messages.
DNS Record Type: TXT
Example Value:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3...[your_public_key]...
v=DKIM1
specifies the DKIM version.k=rsa
indicates the key type.p=[your_public_key]
is where you paste the actual public key generated by your mail server or email service.
The specific TXT
record name often includes a selector which is a prefix to _domainkey
, like selector1._domainkey.example.com
. The selector is specified by your email system when setting up DKIM.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Purpose: DMARC uses SPF and DKIM to determine the legitimacy of an email message, providing instructions to the receiving mail server on what to do if neither of those authentication methods passes. It also specifies how an email sender can receive feedback on messages that pass and/or fail DMARC evaluation.
DNS Record Type: TXT
Example Value:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
v=DMARC1
specifies the DMARC version.p=reject
is the policy, telling receiving servers to reject messages that fail DMARC checks. Other options includenone
(do nothing, only log the event) andquarantine
(mark as spam).rua=mailto:dmarc-reports@example.com
specifies an email address where aggregate reports should be sent.
For all three, replace example.com
with your domain and adjust values according to your specific setup or service provider’s guidelines. Setting up these records correctly can significantly improve your email deliverability and protect your domain against misuse. Always test your configuration using tools like Google’s Admin Toolbox or other DMARC, SPF, and DKIM validation tools available online.