You seem to have some very strong contrary opinions. You can choose to believe that it's all a conspiracy that you have bravely seen through, or choose to consider why a bunch of fairly intelligent folks can have different opinions on these topics.
The advice you've been given is mostly correct. I'd also recommend reading the long thread from last Fall discussing the same issue with Jaroslaw. He also felt strongly that things should be different, and we can definitely wish that it was. It is unfortunate that the antispam fight has made life difficult for the small operators. I won't claim to know all the various rules and signals that Google uses, especially as I haven't worked on the system in years now, but encryption isn't a strong signal for spam detection. Our desires for higher encryption are completely orthogonal to the spam fight. Brandon On Sat, Jul 25, 2020, 2:54 AM Klaus Ethgen via mailop <mailop@mailop.org> wrote: > Hi Phil, > > many thanks for your very helpfull explanation. > > Just a few comments... > > Am Fr den 24. Jul 2020 um 20:40 schrieb Phil Pennock via mailop: > > 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). > > I will give it a try. Even that I am no fan either. ;-) > > > 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. > > I already implemented that. At least for my .ch domains, the .de domain > is registered with hetzner and even that my DNS is configured to add > DNSSEC to it, I am unable to configure the glue in hetzner GUI. > > Unfortunately the Lookaside Validation is not in use anymore so I have > no way to use DNSSEC with my .de domain. > > > At that point, CACert is not going to cut it. You'd need to > > try Let's Encrypt instead. > > I will never, never ever use Let's Encrypt! They did destroy every left > over of trust you could ever have in the whole CA system. > > The fact, that Let's Encrypt certificates are only valid for 3 months > makes it impossible to check the cert manually every time you use that > side. And I would not trust any CA, not Let's Encrypt, nor others. > CACert was the only one that has earned SOME trust but giving the nature > of the CA system that any rotten CA out there can issue a certificate > for your domain, I can not trust the CA system at all. > > DNSSEC is and was the answer that could ever solve the misery but it is > actively denied by the big players, all in front mozilla with firefox > making it even impossible for the tlsa check addon to still work. It > would in fact helps a lot if browsers would start using DNSSEC but I > think, mozilla (and the others) have high interest that this secure > solution will die. It would be the death of all that rotten CAs out > there. > > By the way, you not only find TLSA record for my mail server than also > for my web addresses. > > Finally, yea, I could install that tool to issue a new cert every month > with Let's Encrypt. But I don't like to give that company the control > over my working system. > > So, no, I will never, never ever use Let's Encrypt at all! > > > + 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; > > That is something that I do not understand. This is the only > legitimisation of SPF to have a -all at the end. Otherwise SPF has no > use at all. > > > + 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 `<>`). > > A good measurement is to never send bounces out of your system. If you > would need to send bounces, don't accept the mail in the begin. > > Every bouncing could be misused for bacscatters. And I seen a lot of > that shit. > > > * 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. > > Side note, I use the marketing tags there on the whitelist as blacklist. > I will never accept marketing mails so it is a pretty good measurement. > header RCVD_IN_DNSWL_SPAM > eval:check_rbl_sub('dnswl-firsttrusted', '^127\.0\.15\.\d+') > describe RCVD_IN_DNSWL_SPAM Selftagged Marketing mailer > score RCVD_IN_DNSWL_SPAM 10.00 > > > * 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. > > There is a different system to have the cert in DNS (secured with > DNSSEC): > host -t cert 4iwmtum663r8xnewtn7ugkdixws1d1n8._pka.ethgen.ch > > > * 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. > > That CAA record is broken from the begin and idiotic measurement at all. > If you don't implement DNSSEC, you cannot trust it and if you DO > implement DNSSEC, there is no need for it, just use TLSA. > > 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 > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
