And checking SPF is pretty useful as well. Once you have enforced strict compliance, however, the effect of SPF is negligible (less than 1/1000%).
DKIM/DMARC generally causes more trouble than it solves (it was designed by a committee of idiots after all) and should be mostly ignored other than for displaying a DKIM Signature Status in the mail reader interface. Most of the problem is the horribly broken e-mail clients, none of which display useful information. For those old enough to remember postal mail, it is like having a secretary that throws out the envelope and trims off most of the inside and signature information before giving you your mail. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >Strict RFC compliance is very simple: > >(1) When a remote MTA connects it MUST NOT speak until spoken to. >(2) A remote MTA MUST NOT violate the command/response protocol. >(3) The IP Address of the remote host MUST resolve (in the in- >addr.arpa domain) to a name that forward resolves to a set of IP >Addresses that includes the originating address. >(4) The name given by a remote host in its HELO or EHLO, if not an IP >Address, must be resolvable to an IP Address. >(5) The domain name given in the envelope-from must be resolvable to >an IP Address. > >Optional: > >(6) The IP Address determined by step 4 must accept SMTP connections. >(7) The IP Address determined by step 5 must accept SMTP connections. >(8) The MTA in step 7 must accept an envelope specifying envelope-to >the original envelope sender with an empty envelope-from > >Enforcing compliance with (1) eliminates >70% of all spam. >Enforcing compliance with (2) eliminates an additional 10% of all >spam. >Enforcing compliance with (3) eliminates an additional 10% of all >spam. >Enforcing compliance with (4) and (5) eliminates almost another 10% >of spam. >Enforcing (6), (7), and (8) (that is, requiring full RFC compliance) >eliminates 99.99% of spam. > >If you also can enforce the dropping of direct-to-mx connections >(that is, connections to higher numbered MX's should be rejected if a >lower number MX MTA is availkable), then you can increase the spam >rejection to about 99.999% > >And this is all without blacklists or other questionable whack-job >filtering ... > > >--- >The fact that there's a Highway to Hell but only a Stairway to Heaven >says a lot about anticipated traffic volume. > > >>-----Original Message----- >>From: sqlite-users [mailto:sqlite-users- >>boun...@mailinglists.sqlite.org] On Behalf Of Warren Young >>Sent: Tuesday, 21 November, 2017 12:43 >>To: SQLite mailing list >>Subject: Re: [sqlite] Many ML emails going to GMail's SPAM >> >>On Nov 21, 2017, at 10:24 AM, Peter Da Silva >><peter.dasi...@flightaware.com> wrote: >>> >>> But the mailers I use (Gmail’s web interface, Apple Mail and >(yuck) >>Outlook) all do basic threading. >> >>I’d describe what Apple Mail and Gmail do as “clumping” rather than >>“threading.” >> >>I think we can all agree that drh gets trees, so if he wants to make >>a threaded web forum, he certainly needs no advice from us on how to >>achieve it. >> >>The effort to implement Hacker News can’t have been all that great. >>It would suffice for our purposes. Do it atop Fossil and you get >>user authentication for free, which reduces spam. When (!) spam >gets >>through, it can be shunned using the normal Fossil mechanism, so >that >>later clones don’t contain it. >> >>As far as I can tell, the only really hard part is the email >>gatewaying problem, evidenced by the fact that Fossil still doesn’t >>have a feature to echo commits, ticket changes, etc. via email. >> >>The comment up-thread about RFC-complaint email handwaves the >>complexity of achieving that in 2017, even when using existing >tools, >>which is not a given where drh is concerned. >> >>If you start with Postfix’s RFC list: >> >> http://www.postfix.org/smtpd.8.html >> >>then chase all the “obsoleted by” and “updated by” links from those >>RFCs and add in completely missing RFCs that are also requirements >in >>2017, you get this list, which is probably also incomplete, because >I >>am no expert on MTA implementation: >> >> RFC 1123 (Host requirements) >> RFC 1870 (Message size declaration) >> RFC 1985 (ETRN command) >> RFC 2034 (SMTP enhanced status codes) >> RFC 2920 (SMTP pipelining) >> RFC 3207 (STARTTLS command) >> RFC 3461 (SMTP DSN extension) >> RFC 3463 (Enhanced status codes) >> RFC 3848 (ESMTP transmission types) >> RFC 3885 (SMTP Service Extension for Message Tracking) >> RFC 4954 (AUTH command) >> RFC 5321 (SMTP protocol) >> RFC 5322 (Internet Message Format) >> RFC 6152 (8bit-MIME transport) >> RFC 6409 (Message Submission for Mail) >> RFC 6531 (Internationalized SMTP) >> RFC 6532 (Internationalized Email Headers) >> RFC 6533 (Internationalized Delivery Status Notifications) >> RFC 7489 (DMARC) >> RFC 7504 (SMTP 521 and 556 Reply Codes) >> RFC 7505 ("Null MX" No Service Resource Record) >> RFC 7817 (STARTTLS updates) >> RFC 8098 (Message Disposition Notification) >> >>Those 23 standards print as 579 pages. Yes, that’s right, someone >>“just” has to implement 579 pages of standardese, which gets you >only >>SMTP, which we’d better hope is enough since IMAPv4 + POPv3 probably >>doubles that again. >>_______________________________________________ >>sqlite-users mailing list >>sqlite-users@mailinglists.sqlite.org >>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
