Hi, I want to answer to this old mail.. :-)
First, thanks for that detailed mail. I will keep most of the quote for clearness. Am Fr den 24. Jul 2020 um 20:40 schrieb Phil Pennock via mailop: > 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. [...] > 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. So far so good. > 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). The problem of using DKIM is, that it changes the meaning of headers slightly. > 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. I do not trust any SSL-CA. But Cacert is the most trustworthy. With this Lets-Encrypt-stuff comes that the certificate needs to be replaced every 3 Months. I do not have all the time to replace them that often. Yea, I know, there are tools. But I wont trust that tools to modify my configuration every Month. > 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. All set in my domains. > * MX record, always. Set too. > * 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 `<>`). I have a very accurate SPF. But I refuse to use any other than `-all` as without it, it would make SPF useless! I never ever want any other host to send mails in my name! About the bounces. I never bounce mails. I refuse them or deliver them. Any bounce is bad habit current days. > * 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). As mentioned above, this block is not doable, not only for time resources I don't have, also for the reason that it changes the meaning of headers. > * 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. I did not had that on the radar. And I have no knowledge about it. However, when it comes to HTTPS with other certificate than cacert, it is a nogo for me. > * 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 That I support fully! DNSSEC and a TLSA/DANE record is a very robust way. All is fully deployed for years on my domains. (Except my .de one as my provider does not implement DNSSEC and the side band DNSSEC closed years ago.) > * _smtp._tls record so you can get reports of TLS failures sending to > you Good point. > * 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) That is only partly under my control. There are also blacklists out there that do not have any way to get delisted. However, my IP should not be on the ones I know. > * Don't do sender callout verification to SMTP servers which aren't > yours. Why not? > * 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. Yes. I can also support that point. > 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 Some good advises. > * 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! The CAA record is not worth using it. TLSA is the much better approach. CAA is just a patch on a broken system of CAs. It is a fully misconcept! > * <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 do not like or support if mail reading triggers a out-of-band connection to some cloud provider! Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <kl...@ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
signature.asc
Description: PGP signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
