« first day (3392 days earlier)      last day (26 days later) » 

3:03 AM
@Isaac Thanks, but he does know English, of course. I was referring to a version of his CV that is in Portuguese.
@derobert Bug reporting time?
Turns out my correspondent is actually a TeX expert. Relative to me, anyway.
 
 
10 hours later…
1:07 PM
@terdon Me too. Or thereabouts. And only briefly.
 
 
2 hours later…
2:40 PM
Fetchmail suddenly started reporting errors just now.
OpenSSL reported: error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
servername: upgrade to TLS failed
nknown login or authentication error on emailaddress@servername
Does anyone have any idea what might be causing this? I guess the obvious thing to do is create a ticket with my mailing hosting provider.
 
3:24 PM
@FaheemMitha I would guess they turned off TLSv1
 
3:35 PM
@derobert They being the remote server?
Perhaps you could tell me what to do, in that case?
I see I have the following line in my ~/.fetchmailrc
 sslproto TLS1
Should I change that to something else?
 
@FaheemMitha sslproto auto, or drop the line altogether, depending on your ssl line (if you have one)
see man fetchmailrc for details
 
@FaheemMitha fetchmail.info/fetchmail-man.html suggests sslproto auto ..... ninja'd by Mr. Kitt
 
under Debian, stop the service, then run /etc/init.d/fetchmail debug to check changes
 
@StephenKitt The only other line I have which contains the string ssl is
  sslcertck
Ok, now fetchmail is refusing to start...
Jan 22 21:11:37 orwell fetchmail[30755]: Starting mail retriever agent: fetchmailfetchmail:/etc/fetchmailrc:26: syntax error at auto
Ok, just took that line out. Which got fetchmail working again. I don't know why it wasn't accepting auto.
 
3:51 PM
@FaheemMitha the web page I found says "Since v6.4.0" so maybe you have an earlier version?
 
@JeffSchaller Debian in its wisdom has me running version 6.4.0~beta4-3.
I guess I could try running the version in testing/unstable, 6.4.1-1.
But I'm generally nervous about altering system defaults.
 
@FaheemMitha perhaps omitting it implies a negotiation; are you able to fetch mail again?
 
@JeffSchaller Apparently yes. For the moment, anyway.
I just got a spam message. Yay.
 
4:46 PM
@FaheemMitha either that, or see if you can force TLS1.2 or better. Since anything less has security issues.
 
sslproto TLS1.2+
 
@derobert @StephenKitt Very well, trying that.
 
Dammit, I never remember. How do I sort things like `printf 'foo1\nfoo10\nfoo2\n' so that I get foo1, then foo2 and finally foo10? Basically, ignore the string and sort the numbers numerically?
Preferably without a schwartzian transform. I'm sure there's some sort option I'm forgetting.
Ah, GNU's sort -V will do it
 
@terdon In shell, or perl?
 
@derobert @StephenKitt It seems to have accepted that. Is there some way of checking that option is configured correctly?
 
4:50 PM
Wireshark should tell you what TLS version you're using, I think. Or probably you can turn on some sort of verbose or debug log.
 
1 hour ago, by Stephen Kitt
under Debian, stop the service, then run /etc/init.d/fetchmail debug to check changes
 
@derobert shell, and -V works!
 
@StephenKitt Yes, ok. debug-run starts up a very chatty transcript.
 
@FaheemMitha oops, yes, debug-run, and yes, it’s chatty!
 
@StephenKitt I'm looking for the TLS version?
Is any of this relevant?
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK STARTTLS completed
fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010101f, trying to continue.
fetchmail: SSL verify callback depth 2: preverify_ok == 1, err = 0, ok
Oh, probably this bit
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
 
4:57 PM
@FaheemMitha yes, that’s the relevant information
 
@StephenKitt Ok. According to Wikipedia, that's the latest version.
 
@FaheemMitha congratulations, you have the best widely available protection against the NSA* reading your email in transit between your ISP's server and you. (*pretty sure the CIA owns the wrenches, not the NSA)
 
@derobert I thought email was transmitted in plaintext.
 
@FaheemMitha Not between your ISP and fetchmail.
(And, actually, a lot of email traffic between servers is encrypted now, too. Without any good authentication, of course...)
 
@derobert Oh. But what about the rest of the Internet?
 
5:03 PM
Not sure what percent is encrypted. Probably pretty good, actually, if your ISP supports it. Because the big providers (e.g., gmail) do.
 
@derobert My ISP has the crappiest spam filtering ever. Which doesn't make me confident in the rest of their technical expertise.
 
Sometimes it gets recorded in Received: headers.
 
Though I suspect they may be doing subpar spam filtering deliberately, because they want customers to buy their "special" spam filtering plan.
 
Received: from mta1.schwab.com ([162.93.253.146])
	by Einstein.derobert.net with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.92)
	…
 
@derobert There are a lot of Received headers.
 
5:06 PM
That's my mail server recording how it got that message, so that one went encrypted...
 
received: from p2-239142.ncm14.com (p2-239142.ncm14.com [202.162.239.142])
    by rs301.luxsci.com (8.14.4/8.14.9) with ESMTP id 00MBnmxv000838
    (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
    for <faheem@faheem.info>; Wed, 22 Jan 2020 11:49:49 GMT
That's the one at the bottom, so that's the email hosting service receiving a message for me from outside, I guess.
@derobert You run directly net facing mail servers?
 
yep
 
Wow, ballsy. And you do your own spam filtering too?
 
yeah
SpamAssassin + clamav
 
@derobert Is it hard? I can't imagine I'd do worse than my hosting provider. Which is apparently a specialist.
 
5:19 PM
There is a fair bit of knowledge required to set all that up. Though if you just want to run spam filtering on your local mail, that's much less. Probably can find some howto on that somewhere...
 
Mail specialist, that is.
@derobert Would it be reasonable to try to run spam filtering on my local mail?
 
Yeah, you can do that with spamassassin. And train it, which is an important bit of getting it to work well
 
@derobert And shunt suspected spam to a separate folder?
Where I will probably never ever look.
 
Yeah, it's normally fairly easy to run it through whichever mail filter you're using (maildrop, procmail, etc.)
 
@derobert I wasn't aware I was using a mail filter.
 
5:24 PM
I have no idea how you've configured your incoming mail. Where does fetchmail send it to?
 
@derobert To my local Exim, as far as I know.
 
Debian default Exim setup will do both maildrop and procmail, I believe. Check your exim routers in e.g., /etc/exim4/conf.d/router/
 
MARTINS
 
@Jesse_b Google says you're looking for a grocery store. Try Wegmans instead, its probably better.
 
@derobert I think I pretty much went with the defaults there, so it's probably not doing anything. I don't know what either of those are. Is there any reason to prefer one over the other?
@derobert Oh, and have you ever consigned the description of a bunch of documents to a database, and then set up tagging within that database?
Or CDs, DVDs, or video files, even.
 
5:29 PM
@FaheemMitha router/600_exim4-config_userforward sounds like you can use Exim filters or Sieve as well as procmail and maildrop. I think it mainly depends on which one's syntax you like better.
(Sieve is standard, but not that widely deployed, so you might be able to find tools for it. Procmail has been around forever, so ditto.)
 
@derobert That's 4 different options?
 
@FaheemMitha yep
 
Hold on, 4 different mechanisms to do spam filtering? I thought these days it was all Bayesian. Which ones are Bayesian?
 
@FaheemMitha 4 different mechanisms to do mail filtering. They're general filtering things, not spam filtering. You'd use SpamAssassin on top one of of them.
 
@derobert Oh, I see.
 
5:32 PM
The filtering things are similar to the mail filters you'd find in a webmail ("if header X contains Y, put in mailbox Z")
 
@derobert I see. So probably quite similar.
 
I'm personally using Sieve currently.
 
Well, time to go to sleep, per my new, saner schedule.
For as long as it lasts...
Thanks for the tips, Anthony.
 
SpamAssassin will add a header with a spam score, which you then use to filter the message to your spam box
Sieve is a bit... verbose, but its reasonably powerful. Example:
require ["mailbox", "fileinto", "spamtestplus", "relational",
         "comparator-i;ascii-numeric"];

if spamtest :percent :value "ge" :comparator "i;ascii-numeric" "60" {
        fileinto :create "Junk/3 Very Likely";
        stop;
} elsif spamtest :percent :value "ge" :comparator "i;ascii-numeric" "41" {
        fileinto :create "Junk/2 Likely";
        stop;
} elsif spamtest :percent :value "ge" :comparator "i;ascii-numeric" "33" {
        fileinto :create "Junk/1 Maybe";
        stop;
}
 
Martins Licis (born September 28, 1990) is a Latvian-born American professional strongman, notable for winning the 2019 World’s Strongest Man competition and placing second in the Arnold Strongman Classic. == Career == === 2015-2018 === In 2015 Martins placed first in the Odd Haugen All-American Strength Classic. In 2016 Martins reached World's Strongest Man finals for the first time and placed sixth. He placed fourth in the World’s Strongest Man finals in 2017 and 2018. Besides Strongman, Martins Licis also competes in MAS Wrestling, a variation of stick wrestling. He won gold in the ...
 
5:52 PM
here I thought it was a typo for Martians
 
Probably safer to get in a bar fight with the Martians.
 
so either Elon had been wildly successful in going to and returning from Mars, or we have packets with bogus IP's
 
Martins won the Arnolds Santa Monica the other day, incredibly close contest
 
6:07 PM
@derobert About encrypted email: There are a lot of headers (at least one from each step the email took) And there is nothing preventing the last step (your ISP, or a MITM in your wifi, local net, or coffee shop) from adding, changing, in general lying about previous headers.

No, I wouldn't trust any simple e-mail for anything other than gossip.
 
6:19 PM
@Isaac Errr, I run my own mail server, so I'm pretty confident it doesn't lie in the headers. Other people's servers, of course, you can never be sure.
And if your email clients aren't screaming about MITM attacks... you need better email clients.
 
6:37 PM
Derobert (1) Is your server verifying the next MTA (next mail server in the chain)? How?
(2) Are all the mail servers the email traveled thru verified/encrypted/authenticated?
(3) Is there some mean to verify (authenticate) the message contained in the e-mail hasn't been tampered with?
(4) Are all MTA using https like verification for other MTA's IP's and/or DNS name?
@derobert The last header might be ok (as you control it), the rest of the chain may be tainted.
@derobert But even the server you control may be fooled if your DNS is not using DNS-sec, for example.
 
@Isaac TLS. Incoming, of course, it's the remote server that verifies mine. The authentication there isn't great (relies on DNS too much, and DNSsec isn't there yet). Outgoing, some of the bigger destinations, I have manual verification rules set up.
@Isaac That depends on the mail. But e.g., going to gmail, yes.
Email servers speak TLS to each other — or at least can, and the majority do. And even can verify certificates.
There isn't an end-to-end guarantee, as all the servers can (and do, if nothing else just adding received headers) modify the message. But it's so much better than it used to be.
checktls.com lets you test servers somewhat
 
7:45 PM
@derobert The point is: Without end-to-end encryption (gpg comes to mind) no email is even minimally secure. No MTA **must** encode or authenticate other MTA's. Most big ones **could** encrypt but there is no guarantee that they will do for any specific message.

You could verify or authenticate Gmail, but if the receiver gets its email from the ISP servers (and many ISP actively block port 25), the email chain would be broken. The weakest link ....
 
@Isaac If I'm sending an email to a gmail address, then there's a pretty high chance that it's going to stay encrypted. The recipients' ISP email servers are unlikely to enter into it (only if the recipient has set up forwarding from gmail).
So its contents will be private to me, the recipient, and a large advertising company :-/
Getting most anyone to use GPG is hopeless. There is some hope of getting them to install Signal, but even that can be a challenge.
And the GPG web-of-trust security model isn't really that strong, unless you've personally exchanged keys with someone. Otherwise... I'd assume three-letter agencies can get into a chain a few people long.
Residential ISPs blocking port 25 doesn't have anything to do with it (other than making it impossible to run you own mail server on a residential connection, at least without a tunnel of some sort).
 
8:50 PM
@derobert (1) Sending to Gmail from chrome (web page) doesn't need an MTA. Receiving from Gmail on a web page (using most web browsers) is reasonably secure and uses no MTA also. (2) That is assuming that Google is not open to three letters agency interference/action (3) most emails in Gmail are not encrypted, even if you attach an encrypted file, the body and headers are open to anyone to read (there is no way to hide the fact that the comunication took place).
(4) That some ISP blocks port 25 means that emails not sent thru a web page, that is, using Outlook, for example, will contact the ISP MTA. And you are talking about your own MTA, so MTA's chains is the channel to analyze. (5) GPG is very easy from the command line: gpg --encrypt --sign --armor -r mary-geek@protonmail.com.
(6) veryfiing keys is very easy, use some alternate channel, call the other person (that you already know) on the phone and read the fingerprint (gpg –fingerprint user_ID). Done, ID checked. The problem comes when you don't know the other user.
And you can not authenticate him(her) by the sound of their voice or by their face or by some private joke. Then you need hard ID: Passport or similar IN PERSON to verify.
 
 
2 hours later…
10:58 PM
@Isaac No, they shouldn't be. That's a configuration error. If you want to send outgoing email through your gmail accoumt, you use port 587 or 465, not 25. Both of those should be using TLS (and I believe it's required with gmail, and also is required with 465), so are immune to ISP interception. Google of course has the plain text, but it's no different than using the web interface (over https)
When that email leaves Google, and heads to my mail server, Google uses a TLS connection to my mail server (the same happens when mail leaves my mail server and heads to Google). Certificates are checked (there are some issues there with which domain is checked).
Apparently 83% of the mail going out of gmail and 95% of the mail coming in is encrypted (see transparencyreport.google.com/safer-email/overview)
... and GPG is not easy. I mean, "from the command line" already lost the vast majority. It works for very technical communities like Debian. Other than that... I can't even imagine trying to, for example, get other members of my HOA to use it (I tried once, just to encrypt some backups — result is, I'm the only one who can deal with the backups... and two of the other people I tried with are computer programmers.)
(Side note, GnuPG/PGP has a ton of extra complexity—a clear enemy of security—for all the web of trust stuff, interoperability going back 20 years, and its own version of CAs too. If you're going to verify directly, just use Signal or similar.)
 
11:27 PM
@derobert I understand that you believe your email is secure. I don't.
 
I wouldn't go that far. But it's much more secure than it used to be (when it was 100% plaintext, compared to now over 4/5 of it encrypted). And as far as things people actually use...
There's no telling what Google does with its access to all the plain text once it gets into their system, for example. (Which is where a good chunk of the world's email goes.)
Again.... I think if you need secure communication, Signal is a good choice. Even non-technical folks can use that. Or OMEMO over XMPP.
But against non-government adversaries, email between reasonably configured servers (which includes gmail) ... the weak point is no longer the transit. It's the end-user computer or the user.
 

« first day (3392 days earlier)      last day (26 days later) »