On 2020-07-24 at 09:54 +0100, Klaus Ethgen via mailop wrote: > As my mails are always plain text, signed by PGP and coming from a mail > server that I can assure is never sending spam or even high amount of > mails, that is not in any blacklist, I wonder, what makes it google to > believe that my mails should be in spam? (On the other side, the left > clear spams sent by amavis, mailchimp or others in the inbox.) > > Is there any I can do to prevent google to hide the mails from my > friends? > > Ah yes, before you ask, I hav a strong SPF record, my mailserver forces > encryption (with a cacert certificate) but I didn't implement DKIM as I > see no use for it.
There's a PDF from Google from 2006 which is still worth reading: https://research.google.com/pubs/archive/45.pdf If you don't send much email, then the only IP-based reputation which Google can assess you on is the reputation of your address-block, so being in a "troublesome" hosting provider will score heavily against you. At that point, if not moving away, you need to try to balance out that negative score with enough positives that any of the large providers using reputation scoring will accept the mail. Working forward-and-reverse paired DNS is even more important for IPv6 than for IPv4; for better or worse, some of the large providers have decided that exemptions in old standards for old behavior should not apply when folks deploy standards which are far newer. So you absolutely need an MX, not just relying upon address-records. With a poor IP-based reputation, you need to see if you can score a better domain-based reputation. This is where DKIM comes into play: once you can provably link a message to really be from a given domain, then even if you don't send much mail you can benefit from stuff like "not on day-old-bread domain-lists". But having DKIM and then a DMARC record does help (and I'm no fan of DMARC). For the mail-server's TLS: for that to count in your favor instead of being a wash, I strongly suspect that it needs to be a certificate which senders can verify. For those people scoring up for "better TLS", those senders using DANE will be happy with a TLSA record in DNSSEC for your CACert anchor. But the large webmail providers are Resistant to having to deploy DNSSEC verification, so instead have pushed out an alternative called MTA-STS. With MTA-STS, you're tied into "whichever subset of CAs all the large senders you care about will trust", and then using that CA for the certificates both for the mta-sts webserver and for your mail-server. Note that you don't need to implement the client logic for MTA-STS (and I think it's antithetical to an open federated platform) but do need to just publish the static information for those senders who do use it. At that point, CACert is not going to cut it. You'd need to try Let's Encrypt instead. The ongoing natural tendency from larger providers is to favor supporting what the majority of their users want the majority of the time. With so many people using larger providers, they naturally tilt towards stuff which works with the larger senders, and requiring more hoops. Those additional hoops create more work for smaller providers and self-hosters doing thing manually. We need better automation tools around all of this. The below will make it clearer why. So, here is my current understanding of the best current practices here, in reality not IETF idealism. This includes making mandatory stuff which some folks insist must be optional, because realistically to send to some large providers it's not optional. This list includes features to make you compatible with ongoing trends in the EU (particularly Germany) to strongly disfavor allowing cleartext SMTP. This assumes that you are _not_ a large sender who should also be setting up feedback loops, learning how to "warm" IPs, considering BIMI, postmaster tooling domain verification, etc. * reverse DNS with matching forward DNS; the name used should not pattern-match anything generic and ideally would include a DNS label of `mail` or `mx` or the like in it. * MX record, always. * accurate SPF; + ideally not too broad; + avoid `-all` at the end because with the sole exception of "this domain never sends email" records, it tends to be a sign of over-enthusiasm and counts slightly against you; + remember to have an SPF record for your HELO hostname, because when you send a "bounce" rejection, this is the thing which will be looked up (since there's no domain in `<>`). * DKIM set up, RSA2048 key, with a selector. Note that for various good reasons you should design this to be something you routinely rotate. Some folks use yearly, some monthly; I rotate every three months. * DMARC record, but for domains which humans send from _don't_ use quarantine or reject; do consider setting up a receiver for reports, just so you can see how much of a privacy breach DMARC reporting is when you send to mailing-lists which don't re-sign. :-/ * TLS certificate from a CA in the main trust anchor bundles (just use Let's Encrypt). * MTA-STS webserver with HTTPS from the same CA, and the relevant MTA-STS txt file in place; add the DNS record when it's up and happy. * For the independent mail providers using the stuff broadly supported in open source MTAs, you should look at DNSSEC, because the patterns here are less susceptible to rent-seeking pressures: + DNSSEC-signed zone for your own domain + DNSSEC validating resolver for you to look up records of others (consider Unbound or Knot) + DANE records for your own domain (TLSA records in DNS) + Tell your mail-server to obey DANE stuff, so that if there's a TLSA record in DNSSEC-verified DNS then the mail-server can disable fallback to cleartext for delivery to MX (and ideally also then verify the TLS connection has a cert chain which is anchored in one of the TLSA records) + <https://dnsviz.net> is your friend * _smtp._tls record so you can get reports of TLS failures sending to you * Seeing if you can get your IP onto one of the open DNS-based allow-lists (also called "whitelists" but some folks are moving away from that term), such as <https://www.dnswl.org/> or Spamhaus's SWL. * Periodically check if you appear in any DNS-based deny-lists. * Make sure you're not sending from "ISP residential address-space"; if need be route your mail outbound via a host in better address-space (and update SPF etc to match) * Don't do sender callout verification to SMTP servers which aren't yours. * For your own sanity, do make sure you set up fail2ban, or something like it, scanning your mail-server logs, because SMTP AUTH online cracking is widespread. If they ever get in, your deliverability will be negatively impacted by their spam campaign through your mail-server. Outside of "Phil's BCP" above, additional non-deliverability but convenience options include: * DNS SRV records for submission(s)/imap(s)/pop3(s)/sieve, even if just to say with "0 0 0 ." that it's not supported * If your communications base includes people using OpenPGP with email, then set up WKD to publish PGP keys for your domain too. This is just a fixed schema for laying out keys for HTTPS retrieval. * If your communications base includes people using S/MIME then set up SMIMEA records in your DNSSEC-signed DNS (they look a lot like TLSA records); these are trust anchors * The moment you start specifying "must be TLS-secured" it's worth adding CAA records into DNS, so that CAs which are broadly trusted will refuse to issue for your domain unless you list them. + For domain-validation CAs such as Let's Encrypt, consider adding account information to those records to tie it to your specific account. + Beware that at time of writing, Let's Encrypt only honors the accounturi restriction in their staging environment, not their production setup; this will likely change. + Remember that DNS zonefiles support comments. You'll want them here! * <https://wiki.libravatar.org/api/> for Gravatar-style images in some MUAs (with caching for privacy reasons); this is a fixed schema HTTPS layout and a DNS record. I think almost nobody uses this but I don't have usage figures. If you have a Claws user, perhaps? I've written this as a reply so it's the stuff I can remember / spot now, so I might be missing something big or "too obvious to me". Other tech exists. -Phil _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
