On Nov 21, 2017, at 1:20 PM, Keith Medcalf <kmedc...@dessus.com> wrote:
> 
> Strict RFC compliance is very simple:

We await your patch, then. :)

> And checking SPF is pretty useful as well.

But not DKIM, which solves the same problem as SPF, but with strong crypto so 
it can’t be MITM’d?

DKIM effectively signs email from a given server.  It doesn’t tell you that a 
particular person sent it, but it does unambiguously prove that a given 
*server* sent it, assuming the server doesn’t lose control of its private key.

Some receivers may require only SPF, and some may require only DKIM, so if you 
don’t support both, you cut those receivers off.

Some receivers may support both but weigh a correct response to one higher than 
the other, so if you only support the lesser-ranked one, your messages are more 
likely to be seen as spam, which gets you right back onto the boat aboard which 
we sailed off into this thread.

> DMARC generally causes more trouble than it solves

That may well be, but some receivers may require it.  If this proposed 
MTA/forum/mailing list doesn’t support it, those sites will be cut off.

Which sites?  Let’s start with the US federal government:

    https://goo.gl/F7ahDg

…which employs a large fraction of the US workforce:

   https://goo.gl/nXDCc4

…all of which we’re willing to cut off from discussing SQLite and Fossil?

> And this is all without blacklists or other questionable whack-job filtering …

You’re only considering the inbound SMTP case, I think.  This MTA must also 
talk to all the other existing SMTP servers, since to a first approximation, 
all SMTP servers have a SQLite or Fossil user behind them.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to