Re: Deprecated: white is better than black
plus one for terminating this thread, because On Thu, 2021-02-25 at 09:33 -0500, micah wrote: > If people don't like it, please do something productive about > it, rather than make hundreds of people have to hit their delete key. Impossible. The only thing I found to work is the opposite of productive: destruct myself before they find me. Back to playing chess with my rgb(0,0,0) and rgb(255,255,255) pieces, until the Ministry of Newspeak learns math. 255>0. Numeric privilege. You know the rest. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: CentOS Linux 8 is being practically abolished
On Wed, 2020-12-09 at 17:44 +0200, specktator wrote: > we need to be *aware of such actions on FOSS.* +1 this looks like history repeating itself: back in 1999-2000 Red Hat pulled the switch on their (whatever the name was) community edition, trying to coerce users into paid RHEL subscriptions. No thanks back then, no thanks today. Luckily, the universe of FOSS distros is varied and competitive. Fork them! Or better: join a distro with a better track record. Ultimately, the ethics of the organization is determined by the ethics of the individuals and it follows them wherever they go. This kind of conduct seems to be engrained in that strain of DNA for more than two decades, and you do not want to be anywhere near it. Bad apples. Me always happy to pay for valuable work/development/admin, but absolutely allergic to taxes, ransom, walled gardens, and other coercitive shenanigans. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: lost connection after STARTTLS
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
Re: Postfix restrictions
On Tue, 2020-06-09 at 01:16 -0600, @lbutlr wrote: > > On 08 Jun 2020, at 16:21, yuv wrote: > > > > Some of [the alternatives to internet email] will achieve scale as > > well. At some point, the cost/benefit analysis of maintaining > > internet email vs. using alternatives such as SMS will tilt > > obviously against email > > Sure it will. It hasn't happened yet, and I don't think it will > happen (SMS is garbage), but it is still irrelevant to the topic. It may be irrelevant to the topic, but your statement characterizes the troll perfectly well. The admins working for the fine companies on the list at the URL below may be of a different opinion on relevance and on occurence of the cost/benefit tipping point. https://en.wikipedia.org/wiki/List_of_mobile_network_operators Some of them may even opine that your internet email is garbage. I am personally agnostic regarding garbage... > > and that's where "most admins" will regret their narrow view. > > How do you figure? You think we run Mailservers because we are > emotionally invested in the idea of email as the ONE TRUE INFORMATION > EXCHANGE? Nope. We are mail admins because we and our users need > email. As soon as that is no longer the case I will gleefully switch > to the better thing. ... but I have zero tolerance for the arrogant attribution of your preconceived notions. My thoughts are far from your wishful dreaming. All things being equal, internet email is less interesting when it is less reliable and more spammy, both of which are direct consequences of your myopia. I care little whether my communication is carried by pigeons, by fax, or by internet email. The question is not "do you want to receive that email?" The question is "do you want your message delivered reliably according to protocol" and if email does not cut it, there are competing protocols that do. Here is one for you: https://siarchives.si.edu/history/featured-topics/postcard/postcard-history By the time "your" users will no longer need you, you may find that the competitive landscape has shifted under your feet. And they may gleefully leave you and your baggage behind. Abandonware. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: Postfix restrictions
On Sun, 2020-06-07 at 20:36 -0600, @lbutlr wrote: > On 07 Jun 2020, at 06:38, yuv wrote: > > Is there a valid reason for a sender not to fix something so > > essential as DNS configuration? > > That’s not the question. Oh, yes it is. Making room for degraded configurations is detrimental to the protocol and to the federation of internet email server operators if internet email is ever to mature into a reliable messaging system on par with snailmail. > The question is, do you want to receive the mail or not? If you do, > then don’t use reject_unknown_helo_hostname > > It’s a question only you can answer, but it seems most admins find > that this results in too much lost mail. The consequence of this narrow framing is that internet email is serving the interest of spammers more than the interest of recipients. Spammers pay admins better than recipients, so we get what we pay for. Meanwhile, alternative messaging systems with more rigid controls, some of which are proprietary, achieve maturity much faster. Some of them achieve scale as well. At some point, the cost/benefit analysis of maintaining internet email vs. using alternatives such as SMS will tilt obviously against email, and that's where "most admins" will regret their narrow view. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: Postfix -> Whatapp
You may be interested in this WhatsApp interface: https://developer.nexmo.com/messages/concepts/whatsapp can probably write a glue-script to access it, however it seems to only be open to "businesses that have been approved by WhatsApp." Why don't you simply skip WhatsApp which anyway requires a phone message, and send an SMS to the phone directly? https://developer.nexmo.com/messaging/sms/overview is easier and reaches a wider audience. WhatsApp is just a proprietary, exclusionary tool that serve the spyware economy, not the users. I personally do not need this FB subsidiary sucking the blood out of my digital life. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: The historical roots of our computer terms
May I offer to those who want to continue this off-topic discussion to do it at https://zoom.us/j/99433754361 ? up to 100 participants, no time limits, open for the next few days. It's on my firm. Enjoy. I will be there for the next little while. No reply to the ML, thanks. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: Postfix restrictions
On Sun, 2020-06-07 at 14:22 +0200, A. Schulze wrote: > using "reject_unknown_helo_hostname" may trigger some false > positives. Not every sender have such perfect setups. Is there a valid reason for a sender not to fix something so essential as DNS configuration? -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: The historical roots of our computer terms
On Sat, 2020-06-06 at 19:12 +0200, Jaroslaw Rafa wrote: > Black color is culturally associated with the devil (and also death), > and white with an angel (innocence, etc.) in your culture. have you tried checking other cultures? > Let's not get crazy. I agree with you. It applies to all sides of the debate. For the technical debate, which is relevant here, colors are/were a coded abstraction that is unnecessary. Using more precise, meaningful terms such as allow/deny reduces ambiguity, improves readability, does not make the text significantly longer and should be uncontroversial (other than the pain of migrating configuration files and the likes, which can be mitigated with appropriate deprecation periods). For the political debate... it's the twitterization of language. White is RGB(255,255,255) and Black is RGB(0,0,0). Or it can be expressed in photon's wavelength. White/Black is not race. Colours were used as an approximation of race, not the other way around. Imposing race as the definition of the words will make language worse, not better. I appreciate and support the intention, but in my view, putting people in boxes (white, black, whatever) only increases racisms, and detracts from the ability of a language to describe facts such as reflected wavelengths. But then, this is the twitterization of language, and soon there will be emojis only because of raising analphabetismus and the lazyness of imperfect definitions. 2c -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer
Re: easiest way to reject/process emails based on Return Path
On Tue, 2020-05-19 at 11:38 +0200, Jaroslaw Rafa wrote: > As a non-lawyer, it is hard for me to understand what you're trying > to debate about. The legal issue is NOTICE. NOTICE is the fact that the recipient knew or *should have known* the content of the message. Let me know if you want me to expand on the concept of notice. > Even physical postal mail service does not give any guarantee that > the recipient has actually READ your mail. That is not of concern, neither for snail-mail, nor for fax, nor for internet-email. The three of them have done their job when they have delivered. After delivery, the responsibility (and the legal liability) lies with the recipient. The general rule is that spam is in the eye of the recipient: if you find my message to be irrelevant to you, I must accept your judgment. Except for some specific situations. For example, a debtor cannot say that a request to pay from a creditor is spam. It is a direct consequence of the debtor accepting a loan. This is where the concept of notice kicks in: the debtor should have known that he owes money, ignoring the payment request does not absolve the debtor from the consequences of not paying the debt. I had clients who learned this the hard way: they ignored the snail-mail letters from the bank. the bank repossessed their home, evicted them, and sold it, at great expense/loss to the idiots who ignored the letters. > If you have your OWN SERVER, a 250 reply to SMTP transaction is an > equivalent of confirming that the message has arrived into your > "mailbox". This is a conflation of the general case, and irrelevant to my concern. In the OWN SERVER case, the law will find that the recipient has willfully ignored the message and knew or should have known the message. > What's ethically doubtful in this? If it were a third party > who discarded the message - yes, that would be unethical > (and probably against the law as well). But if the recipient does it > him/herself - I can see no ethical or legal issue at all. if the third party is Gmail or Hotmail (and many more, no intention to single out those two services), then it is not even against the law, as the contract between the unaware user and the sophisticated "free" email provider stipulates that the email provider has no responsibility for delivering the message. Let me first expand on the legal issue, and then touch on the soft / ethical issue. In a previous message on this thread, on Mon, 2020-05-18 at 13:50 -0400, Bill Cole wrote: | > The legal term is *misrepresentation* | | It is not misrepresentation. The SMTP protocol definitions have | NEVER required the 250 reply to end-of-data to indicate actual | (much less final) delivery and has ALWAYS explicitly cautioned | against reliance in any way on the optional text part of any | server reply. A *misrepresentation* occurs when a person lies. SMTP is not a person. An MTA is not a person. A fax is not a person. They are merely devices that a person use to make the misrepresentation. The *LEGAL ISSUE* with an MTA or with a fax is product liability. The manufacturer of a fax device (or the operator of a fax server -- I have not owned a fax device since 2003) represents that its device or service complies with the CCITT standards (or whatever has followed since, the last time I have looked in depth at the protocols around faxes during a 1989 summer job when I programmed a software-fax), and failure to comply with the standard attracts a product liability suit. Software publishers for MTAs (and in general) exclude product liability with the licensing term that disclaims "implied warranties or conditions of merchantability and fitness for a particular purpose" (quoted text from the terms under which Postfix is licensed). Which basically says to the user: here is a knife, use it at your own risk. If the OWN SERVER sends a 250 and discards the message, the user is both recipient and operator. The law will find sufficient notice and the sender is protected. In the general case, the user is the MTA operator and is not the recipient. The user has caused the MTA to send a 250 and *misrepresented* to the sender that the message was delivered. The user has caused the message to be silently discarded, preventing the recipient from noticing the message. The user is liable for the damage caused by the lack of notice, except if said damage is disclaimed in the general terms and conditions of the service (see reference to "free" email services above). Unsurprisingly, free email services invariably have such disclaimer, preventing the recipient from making a damages claim against the operator. I believe that paid email services (from the same providers) do not have such disclaimer, and if they do, why would one want to be customer of their service? The *ETHICAL ISSUE*, and the reason why I do not want to send a 250 and discard the message in the conflated scenario: when I am the sender, and I am told 250,
Re: easiest way to reject/process emails based on Return Path
On Mon, 2020-05-18 at 13:50 -0400, Bill Cole wrote: > In 30 years of working with Internet email, I have never seen any > fully > automated mechanism for making its delivery reliable in general, > non-contracted cases. ... > There is no virtual replacement for a physical process server. Maybe > someday that will mean robots of some sort (e.g. drones) but before I embark on an interesting conversation, can somebody confirm that I am not veering off-topic? I came here for a technical solution. Jerry gave an elegant one, although I am not ethically comfortable with it. The problem of Internet email is the problem of any federated standard. Embrace, Extend, Extinguish. Internet email is being replaced by text messaging, and I dare betting that fax will survive Internet email, because fax has a niche that Internet email has failed to create for itself. Fax niche is the communication with adverse interest. A minimum common denominator, that enable the less powerful of the parties to stay in the game. Internet email could have been even better. Could have... I am not expecting process serving standards (though I wish mechanical process serving could be replaced by something electronic). Just the same reliability of fax transmission (if the message gets lost after the 250, the fax operator is liable) would be good enough to give Internet email more purpose than the delivery of spam. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer https :// moneylaw.ca Tel: 1.844.234.5389 Fax: 1.888.900.5709
Re: easiest way to reject/process emails based on Return Path
On Fri, 2020-05-08 at 09:51 +0200, Gerald Galster wrote: > > > Below is the PCRE that I came up with to catch the offending > > > messages, > > > without blocking other correspondence (the contacts and their > > > organizations are likely to use Google's SMTP for their regular > > > emails): > > > > > > /^Return-Path:(.+)(calendar- > > > server.bounces.google.com)(.*)/ REJECT No > > > Google Calendar Spam Here > > > > If you reject mail from Google, Google will stop sending you mail. > > ALL mail. Can you afford that? > > You could use DISCARD instead of REJECT. > > #DISCARD optional text... > # Claim successful delivery and silently discard the > # message. Log the optional text if specified, oth- > # erwise log a generic message. > Thanks for the suggestion, Gerald. I was hoping for something more ... *honest*. To claim successful delivery and silently discard a message is a lie. The legal term is *misrepresentation* and I am eagerly waiting for the client coming through my door who has been damaged by an email service operator that replied with a 250 and then silently discarded the message. It is one of the main reasons why we lawyers continue to use fax transmission: the protocol is reliable, my fax device receives the equivalent of a 250, I can rely on the fact that something has been delivered. Not silently discarded. As for the other comments elicited by my post: is there any evidence that Google stops sending ALL mails on some very specific rejections? or is this just FUD? After all, Google is used by millions of senders, and some of them are most obvious spammer. Does anyone expect an email server to accept an email containing a request to send money by Western Union to some exotic country in exchange for the prospect of receiving an inheritance from an obscure prince or despot of said country? Thanks, Yuv
easiest way to reject/process emails based on Return Path
Hello List: I am operating a smallish postfix server for my law office. Many of our contacts use Google's calendar, and when they enter one of our email addresses into their calendar entries, we receive a flood of annoying emails. Invitations / reminders / updates / changes / cancellations of meetings. Initially, after receiving twelve emails for a single calendar entry repeated weekly for three months, I wanted to outright reject the Google spam. After the second change within 24 hours, I also wanted to fire the client. But maybe there is smarter way to deal with this annoyance, such as re-directing the emails to an auto-responder or some other form of automated processing (/dev/null comes to my mind too)? Below is the PCRE that I came up with to catch the offending messages, without blocking other correspondence (the contacts and their organizations are likely to use Google's SMTP for their regular emails): /^Return-Path:(.+)(calendar-server.bounces.google.com)(.*)/ REJECT No Google Calendar Spam Here where/how do I best add the restriction to Postfix? I was thinking to make it an smtpd_restriction_classes so that I can apply it to some recipients but not to others. But maybe rewriting the destination address, or sending an auto- responder right away? I just want to get that spam out of the way in the most elegant way possible. Thanks in advance for your help, Yuv
