On Fri, 2020-06-12 at 09:11 +0200, Fourhundred Thecat wrote: > > On 2020-06-12 08:57, Jeroen Geilman wrote: > > - too many errors after .* from .* > > - warning: non-SMTP command from .* > > > > While these do indicate badly-behaved clients, there is no reason > > to assume evil intent.
The senior citizen that inadvertendly drove faster than the allowed speed limit had no evil intent, but they still got a speeding ticket. > - reject: RCPT from .* Recipient address rejected: User unknown in > > local recipient table; .*' > > > > This rejection is per-recipient; blocking this *client* because > > they mis-typed a single address means you /will/ reject valid email > > later on. > > OK, I see. But I am blocking for 1 hour only anyway. That is very reasonable. A civil society does not send all citizens that have driven a bit above limit to prison. For mild offenders the sentence is a small ticket. For more serious and repeat offenders, there are temporary license suspensions, and only for the worst offenders there are life-suspensions and sometimes jail. Intent is still not part of the equation, and this is by design: Proving intent (subjective!) is extremely difficult. In civil societies, we do not want to make the mistake of jailing innocent people, which is why to find intent (and thus criminal guilt), the standard of proof is "beyond reasonable doubt" (i.e. 100%), much higher than the standard to find strict liability (responsibility based on objective facts only, which is the case of the misconfigured client). Strict liability is easy to find at trial than criminal guilt, but carries much lighter sentences. Eventually, your one-hour blocked client will learn from the rejection, or will be rightfully excluded from the network. On the other hand, tolerating these bad-behaved clients is a slippery slope. If drivers get away with 10Km/h above limit, next week they will try 15Km/h and next month 20Km/h until there is no limit at all. But what was the purpose of the limit in the first place? Sadly, after the twitterization of language, we are witnessing also the twitterization of decision-making. Centuries of wisdom are lost to the analphabetism of incompetents-in-chief that condense accusation, trial, verdict and sentencing into one tweet. > And why can't legitimate client use reasonable ciphers? This is exactly the question to answer. Reasonable depends on context and evolves over time. Maybe 50 years ago it was reasonable to tolerate drinking and driving. Today we know better. Maybe 40 years ago encryption was difficult to implement, and even nowadays there may be reasons not to. Some banks are sending alerts unencrypted, for scalability reasons. > I think my settings are not so strict. I believe am using > recommendations from this mailing list: > > smtpd_tls_ciphers = medium > smtpd_tls_protocols = !SSLv2, !SSLv3 > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 Depends on the sensitivity of the transmitted/received information and your overall protection strategy. If the information is encrypted with PGP or S/MIME, the choice of TLS becomes much less critical. The test I recommend: if you are not comfortable putting the information on the back of a postcard, use PGP, and make sure that you are comfortable putting the PGP-chiphercode on the back of a postcard. With that out of the way, the choice of encryption is much less critical. Have a look at https://ssl-tools.net/mailservers Generally, weak encryption is better than no encryption. !SSLv2 is very sensible because SSLv2 is so bad that it can be used to attack RSA keys and sites with the same name even if they are on entirely different servers. https://drownattack.com/ If SSLv2 is used, An attacker could use a couple of seemingly innocent encrypted packets to/from the SMTP server to gain access to the private key and attack anything else that is protected by that key. What were those GET requests again? SSLv3 is "only" weak when used with SMTP. The POODLE vulnerability is specific to HTTP. May or may not have been applied against SMTP. https://en.wikipedia.org/wiki/POODLE You will have to balance your choice for compatibility with your correspondents, and there is no absolute right or wrong answer. Sometimes no encryption is better than bad encryption. HTH -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
