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

Reply via email to