Slashdot Mirror
ISPs Removing Their Customers' Email Encryption
Presto Vivace points out this troubling new report from the Electronic Frontier Foundation:
Recently, Verizon was caught tampering with its customer's web requests to inject a tracking super-cookie. Another network-tampering threat to user safety has come to light from other providers: email encryption downgrade attacks. In recent months, researchers have reported ISPs in the U.S. and Thailand intercepting their customers' data to strip a security flag — called STARTTLS — from email traffic. The STARTTLS flag is an essential security and privacy protection used by an email server to request encryption when talking to another server or client.
By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted. Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.
By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted. Some firewalls, including Cisco's PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.
This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.
Is it just my observation, or are there way too many stupid people in the world?
When does this shit start to count as criminal? Say a company encrypts all communications with their mailserver and this is part of their legal requirements to protect privacy. Can we sue the pants off them yet?
Please, someone (insert large company here), lose all your data because of this!
No DMCA but I can make a pretty good defamation case. ISP is claiming email provider doesn't support TLS to the ISP's customer.
I assume my email transits the internet in the clear regardless how I send it so I am having a hard time getting angry about this.
Not setting *require TLS* in your mail client. Anyone else could do the same, not just your ISP
... encryption should begin on YOUR computer and end on the recipient's. This is why your data should not be stored in the cloud. This is why people need to pull their heads out of their asses and learn how to protect themselves and not rely on others (companies) to do it for them.
It sounds a lot less like the summary in terms of transmitting unencrypted mail data; from TFA (which, naturally, I didn't read before commenting), it sounds like they just got a failed connection over TLS, which is a lot different than "faking" that your data is encrypted and transmitting it as plaintext.
Is it just my observation, or are there way too many stupid people in the world?
Okay.. I assume that's the reason. The people who believe in encryption will just have to encrypt their mail before it leaves the machine. That's just the way it is. How many times does it need to be said? If you want something done right...
How is it that anybody trusts their providers with the kind of history they have? I mean, can we tawk?
“He’s not deformed, he’s just drunk!”
The encryption is a method I use to keep others from reading said copyrited work, correct?
This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.
XDInd
So your solution is to just let everybody read your email then? Not to fix the problem, but to just give up?
XDInd
I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate. The IMAP server also requires encryption and won't accept unencrypted connections. If my ISP starts pulling anything that disables encryption, my e-mail will start failing with errors. I'd recommend all mail servers be configured this way.
It's disappointing that we're increasingly having to treat our ISPs as obstructions to be worked around or opponents that need to be defeated for things to work right. We're paying them that monthly subscription to carry our traffic, we oughtn't have to jump through hoops to get our traffic carried without interference.
nope, i just use the computer and cellphones for trivial low level communications, if i need to communicate securely i would rather meet in person where we wont be listened to or recorded
Politics is Treachery, Religion is Brainwashing
I believe the setting for postfix smtpd to smtpd is this:
smtpd_tls_security_level=encrypt
And for clients:
smtp_tls_security_level=encrypt
Any wizards with corrections or comments welcome!
I'm glad Yahoo uses a different port as you mentioned if you POP you mail down encrypted. This at least allowed me to to pull multiple years worth of email off of Yahoo's servers which obviously can't be trusted anymore.
When you say stop using STARTTLS are you advocating PGP as the alternative?
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
Maybe he's suggesting to just use plain SSL without the initial plaintext exchange and initiation.
Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.
Editor, A1-AAA AmeriCaptions
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
He's casting a wide net to cover all possibilities...
It should be.
"If any question why we died, Tell them because our fathers lied."
Obnoxious as their behavior is, I don't think the copyright violation holds. Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented. If the sending side agrees to send unencrypted, then it is effectively consenting to send in the clear. No matter what happens between your client and the server there is always a chance a server in the forwarding chain will not preserve the TLS connection, nor is there any guarantee in most cases that the message recipient will access the message over an encrypted channel. God help us all, because corporations sure can't help themselves.
This seems like it should be a violation of the DMCA. It probably isn't but it sure seems close.
Isn't this just hacking, in the criminal media-defined sense of the word.
With recent additions from patriot to fraud act, this smells a lot like "conspire to commit" at the very least. It certainly seems like unauthorized access, as you forced access to information you were not authorized to access.
Just because the internet protocols have lots of holes does not mean they can be legally exploited.
Is this a crazy thought?
1) Because SSL/TLS was so poorly supported for years, many email clients default to using security only if the server supports it. Email software should simply drop support for unencrypted SMTP, or report a big warning if the server doesn't support it. We would not tolerate such a proxy for the web, so we should not tolerate it for email either.
2) A recent Slashdot discussion revealed that the STARTTLS stripping was due to misconfigured proxy servers. I think this is a rehash of the same incident.
The only truly safe place is your mind, or whatever is left of it.
Sorry: http://www.scientificamerican....
It is very relevant. Roe versus Wade was decided base upon the constitutional right to privacy.
OK, so you've never had the need to communicate securely with someone who didn't live in your town. Lots of people do have that need, though, on a regular basis.
You are welcome on my lawn.
Look, most severs these days are configured in such a way that STARTTLS runs on a different port than the plain-text connection.
Wrong. STARTLS specifically allows for both plain text and TLS on the same port.
The server will reject login requests until the STARTTLS handshake is completed.
Partially correct. A well configured server will behave this way on the *submission* port (587) but if the MX port (25) were configured this way then you would be blocking a lot of legitimate email from old servers on the internet that do not support STARTTLS and as such is is not recommended to require STARTTLS for port 25 MX to MX communication. Also even when STARTTLS is used the connection is still plain text until STARTTLS is negotiated.
But take it from a guy who worked on an email client
Thanks for giving me a link to yet another piece of software written by someone who doesn't understand the technology behind it.
(Also: STOP USING STARTTLS!!!)
Wrong again. The only way to have an encrypted SMTP submission channel without STARTTLS (other than tunnelling through ssh or something like that) is via SMTPS (port 465). SMTPS is long ago deprecated and should not be used. Port 465 was *never* officially registered for this use and was essentially "hijacked" and there are only a very small number of old email clients that support SMTPS but do not support STARTTLS. You *should* be using STARTTLS over port 587 which is the submission port. Also STARTTLS is the only legitimate means of encryption between a submission server and an MX.
Of note (which I've also said elsewhere), the real reason the author of the original article had problems is because he is trying to use port 25 for submission. He should be using the submission port (587) and it is highly unlikely that his ISP would be blocking the STARTTLS flag on that port.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
That would be SMTPS which is deprecated.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?
Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.
That's still circumvention in my books. http://www.law.cornell.edu/uscode/text/17/1201
to “circumvent a technological measure” means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner;
One problem to the argument is that it's not actually decrypting your messages, which the topic makes the mistake on.. it's just telling the client that the server doesn't support Encryption, in which the client will then sent in the clear.
Encrypt it on your system before you send it. Expect the recipient to decrypt it on theirs after receipt. Everything traveling on teh Internets is subject to interception.
Have gnu, will travel.
But you don't have to actually decrypt something to violate the DMCA. Can't you just be in violation for making a system to bypass decryption, which is in effect, what they have done. They are bypassing the encryption you are attempting to put on your work.
XDInd
This is one of the most irritating thing in IT. People think they can figure out law, accounting, fiscality, politics, marketing or diplomacy by using what they perceive as "common sense".
Here is the thing. All those disciplines are a gray area by nature, and the right answer is largely a matter of professional interpretation. Can you put that number in that column? Can you consider that such or such situation has caused actual damage to someone? There's no compiler to tell you if this is right or not, there's just people navigating a fuzzy field armed with their experience and knowledge. They live in a world where two people can have opposite opinions and be both right at the same time.
Anyone with a background in applied disciplines like IT or engineering is trained to look at things with a problem-solving angle. That's a great attitude, but unfortunately it sometimes make people overestimate their grasp of concepts that are outside of their area of expertise. It's a lot like those artists who have it all figured out (war, terrorism, pollution, crime, poverty). Case in point: this "enlightened" feedback from Ben Affleck during Bill Maher show: http://www.youtube.com/watch?v...
Don't be that guy.
lucm, indeed.
It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.
The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.
Just being deprecated doesn't mean it's necessarily a bad idea. I still prefer IMAPS/POP3S/SMTPS over this silly STARTTLS nonsense. For one it can't be hijacked as easily as these ISPs are doing.
For one it can't be hijacked as easily as these ISPs are doing.
...which they're *not* doing. This article is a farce written by someone who can't even configure his email client to use the correct port for submission. He's trying to use port 25 which is only for MX to MX communication and not for submission, he should be using 587 and if he did there would very likely be no problems.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
Obnoxious as their behavior is, I don't think the copyright violation holds. Worst case they aren't decrypting it, they are just causing the option to encrypt not to be presented.
And this doublespeak legalese bullshit right here boys and girls, is exactly fucking why you use your own encryption.
Seriously, my ears are bleeding because common sense is trying to murder them. If this isn't circumvention, I don't know what is.
Here's another litmus test. If it were illegal, ANY ONE OF US would be behind bars. No questions asked.
Here's yet another litmus test. Why is it NOT illegal to tamper with email encryption. This would be akin to the postal service purposely using steam generators on snail mail processing lines and then us overhearing "whoops, I don't know how all this mail got opened accidentally..."
If we wouldn't stand for them doing such a thing in the physical world, I don't see why the hell we stand for it in the virtual one.
Check your contract, real careful like. You probably authorize it.
“He’s not deformed, he’s just drunk!”
...without the authority of the copyright owner...
Sure they don't have it?
“He’s not deformed, he’s just drunk!”
Hey, if I write an email, I own the copyright, correct?
What does it say in the ISP TOS?
I wasn't talking about the copyright. The first reply beat me to the punch(line)
“He’s not deformed, he’s just drunk!”
If the company is marketing itself as an Internet service provider and actively keeping its customers from the entire Internet then that's false advertising.
The ISP owes all of its customers who aren't getting the part of the Internet that they want to use a refund, and the company must either change its ways or change its marketing.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
For one it can't be hijacked as easily as these ISPs are doing.
...which they're *not* doing. This article is a farce written by someone who can't even configure his email client to use the correct port for submission. He's trying to use port 25 which is only for MX to MX communication and not for submission, he should be using 587 and if he did there would very likely be no problems.
Bell Sympatico in Canada uses port 25 for encrypted client to server connections Port 587 times out. Completely non-standard fuckery, I realize, but it's certainly possible that this guy's ISP does something similarly stupid.
"City hall" in German is "Rathaus" Kinda explains a few things......
Copyright refers to ownership and/or permission to copy.
Copywrite is the act of copying with a pen.
Copyrite is when you do it religiously.
I didn't see anything in the Cricket Wireless TOS that requires giving permission to circumvent encryption. I skimmed through it though, so if you find something I missed, feel free to point it out.
The sender of the email presumably owns the copyright of the email. The ISP would need the senders permission to circumvent the encryption if that was the case. As per my response to the first reply that mentioned TOS, I didn't see anything in there claiming such permission.
Yup. Nobody needed to reinvent traditional TLS/SSL secure sockets in order to send email.
What's wrong with STARTTLS? To quote the original RFC: "...a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error."
So in other words, if you're writing an SMTP stack you have to handle a severe security edge case by parsing a string instead of getting an exception from your secure socket library. What could possibly go wrong! Oh right... there's a reason this is on Slashdot.
There's no -1 for "I don't get it."
They are not removing encryption. Its more like you requested a secure https connection and they give you a plain http connection.
If you encrypted your email before sending it then it will remain encrypted.
This is transfer encryption when talking to an SMTP host. The server gets the full email in clear in this scenario, even if STARTTLS is left in.
Email encryption is what you do with PGP, there is not way to "strip that out", and the SMTP server cannot read the mail, just the headers.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
When does this shit start to count as criminal? Say a company encrypts all communications with their mailserver and this is part of their legal requirements to protect privacy. Can we sue the pants off them yet?
No. Because they are not removing *your* encryption. Think for a second, how could they do that, short of your ISP being the NSA. :-)
What they are failing to do is encrypt the channel between you and the ISP, its like you asked for secure https and they redirected you to plain http.
Its a non-issue for the legal and medical community since they will encrypt things as needed before it gets to the ISP.
And copywright is when you make your own airplane.
I'm pretty sure ISPs can't hijack people's copyrights just because they transmit the data.
Yeah, that would be like a photo sharing site saying they have permission to use your copyrighted photos for their own promotional purposes since you agreed to the TOS for their site.
Oh, wait...
The headline is wrong. The ISP is removing the mail server's announcement that it supports STARTTLS, and your mail client/server sends your email unencrypted.
The solution to that is using SMTPS on 465, where encryption is presumed, not negotiated. But that was deprecated soon after the RFC came out in favor of TLS. It's almost like someone was thinking ahead and wanted the internet to be less secure:
http://cr.yp.to/talks/2014.10....
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
http://yro.slashdot.org/story/01/07/18/1136244/sklyarov-arrest-follow-up
So even a code written about by Julius Caeser (ROT) is covered by it.
They're in violating of the DMCA
Wait, they're ISPs so it doesn't apply
I've got better things to do tonight than die.
So sue them for 12 billion dollars like they do for music downloaders. (or is it just for big corporations?)
I've got better things to do tonight than die.
Hey, if I write an email, I own the copyright, correct?
The encryption is a method I use to keep others from reading said copyrited work, correct?
This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.
No, you misunderstand what is going on here.
StartTLS is something that happens when your email client connects to the mail server with an insecure protocol on a non-ssl port, and then asks the server to switch to a secure connection. Its your clue that you are doing it wrong,
Connect on a secure port over ssl (usually 465) instead of 25. Set your client up right to use a secure port and they can't deny a secure connection. (Unless they don't support security at all, in which case run away from them like your hair is on fire).
WITHOUT doing it right, your email was never secure, never encrypted, so no DMCA violation.
They aren't denying you a secure connection, they are just putting the burden on you to do it properly instead of having their servers to the extra work of switching an insecure connection to a secure one, which usually entails a whole bunch of handshake-security dance.
Set your client up the right way on the right ports.
Sig Battery depleted. Reverting to safe mode.
Finally, some on who gets it,
Set your client up right and stop all this hand wringing. Its a tempest in a teapot.
Sig Battery depleted. Reverting to safe mode.
Yeah, pretty sure.
Hey, if I write an email, I own the copyright, correct?
Then you have your client set to require encryption, not merely prefer it. And thus your client never sends an email in the clear, and thus they have not violated the DMCA or your copyright.
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
He's casting a wide net to cover all possibilities...
Its a Mountweazel in case someone plagiarizes his wonderful post.
If you do that, your emails will simply fail to send as per these guys who discovered the issue. You're right though, at least it won't fall back to unencrypted transmission.
OK so what we need is an option on mail clients "presume TLS support". Surely this is an area where open source software can demonstrate its advantage with a quick work-around
That's what we do here on the big-gov't email servers. Filtering for non-auth'd relays curbs spam quite cheaply. We already have an answer for ISPs who'd complain about rejection: "Tough."
Maybe we deserve this world ?
No, what it is doing (to borrow the analogy from an eralier posting) is opening every letter in an evelope, putting the contents in a see-through bag and adding a new addres label.
So, it will be perfectly OK is I figure out how to convince Blu ray players not to encrypt their HDMI outputs and I sell a solution to the general public?
I wouldn't hang too much on the DMCA requirement that the protection method must be effective. In practice, the bar for effective isn't just low, it's buried under the sub-basement floor.
How can this work? Wouldn't the client notice that the STARTTLS command did not complete successfully and/or that the session is not encrypted?
I started using email!back!in!the!days!when!you!had!to!know!the!route, so I've never assumed emails are encrypted unless I use PGP or some equivalent tool.
I do not fail; I succeed at finding out what does not work.
Well, no no and no. See, by refusing to pass this header along to the next node, they're preventing encryption. They're not removing it. If you actually encrypted the message payload with PGP or similar, that stays encrypted.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Well played!
If I send clear text to the internet, it is because I don't give a damn who reads it.
However, when I wish my communications to remain private, I encrypt it myself before it ever leaves my local network.
If you don't care enough to encrypt things you wish to remain private, then you are the only one responsible for allowing _anyone_ to read your mail. Don't rely on some nebulous third party to provide _your_ protection against eavesdroppers. Take charge of your life dammit, and quite whining.
tl;dr: Encrypt it yourself and then it doesn't matter if the transport channel is encrypted or not. Stand up on your own and be responsible for yourself!
Surely it's an attempt at defamation by his ISP tampering with his traffic.
Ezekiel 23:20
I always assume that playwrights are toy RC plane makers.
Ezekiel 23:20
Hey, if I write an email, I own the copyright, correct?
The encryption is a method I use to keep others from reading said copyrited work, correct?
This means that removing the encryption is in effect, circumventing a copywrite protection, and illegal under the DMCA.
No it isn't, because they encrypt it, not you. STARTTLS is encryption implemented by the provider. The message is only encrypted during passage from your mail program to their server, and from their server to another STARTTLS server, but that's it. The end receiver gets the message unencrypted in his or her mail program. It can be worse. If the provider from the receiver does not use STARTTLS, the message is not delivered encrypted.
If you're worried about encryption, a protocol designed to be able to strip the encryption at any stage and pass it on to other servers, servers which may be out of your control, is not really encryption at all.
Email just isn't designed to do what you might want. Email encryption is either that of the message (which requires all recipients to have keys you can use and knowledge to use them) or merely securing transit to your first-hop email server. If anyone thinks that email you can read in your client without decrypting it is in any way secure, they have zero understanding of the system (which is the most dangerous security flaw you can have).
The problem is, as always, that we're forcing old protocols to do things they were never designed to, and relying on the goodwill of other people to follow our rules. Even if we published a policy "refuse any email server without STARTTLS en-route", it's easily ignored or bypassed in the case of a single malicious operator in the path of the message.
The solution is really for all domains to publish a public key via DNS, for the client or first-hop server to encrypt the message to the recipient's domain with their domain key, then it DOES NOT MATTER who you hand it off to. The data is encrypted so it cannot be revealed except to the proper desired recipient.
All we have is transit security to the first hop. We would still need that (otherwise I could easily still get an email server that sniff my credentials and uses them to spam people) but it's not the same as message encryption - not by a long shot.
Transit security to the first hop, so your login is protected, so you can authenticate that it's YOUR email server, etc. Then send an encrypted message. Then it doesn't matter what your email server chooses to do with it - either the desired recipient receives an email only they can open, or they receive nothing at all.
The problem is, email DOES NOT DO THIS. And backward compatibility with plain-text email means we can't do this without breaking half-the-world. The time will come, like SSH over telnet, or SFTP over FTP, when we decide that we do need to do this. But it's not happened yet.
Sadly, when it does happen, it makes mass-spam-filtering much more difficult, vastly increases load on mail-servers and still doesn't stop spam.
This is not as much of an issue when using PGP or something that encrypts the e-mail before it is sent to the server.
I like your point, but seriously... "copyright", "copyrited", AND "copywrite" all in one post?
Well at least one of them will be write.
blindly antisocialist = antisocial
Email is an insecure medium. Anybody that pretends it isn't is going to have a bad time. Sure we might have some tricks to secure messages along some of the paths it's going to traverse, but if you expect it to be secured end-to-end, you're naive. If you absolutely must send something via email that contains sensitive information, GPG-encrypt the message first and then send it, otherwise seek a more secure medium.
If it's been identified one time, it's likely been happening on a larger scale but as yet undetected. It's becoming very easy to be either paranoid or self censoring. I don't have anything to hide, but being sliced/diced/dissected/analyzed by the big data cloud does get a little bit old. It's easy to see the results of this overreaching data collection, just research a medical condition (especially one that has a name brand pharmaceutical treatment), research a popular consumer appliance, research a new vehicle, etc... then pay attention to the advertisements that appear on websites over the next couple days... do you notice anything... like ads for what you researched?
I occasionally poison my search results by just doing random searches. I pick a person/place/thing that I have no real interest in, and watch the ad world turn. It must really throw off the "kevin by the beach" bucket when I search for Vespa parts, the latest gay romance novel, women named ISIS, and the 10 day weather for geopolitical sites of interest. http://www.weather.com/weather...
I guess "deactivate" and "impair" would fit the case?
No, what it is doing (to borrow the analogy from an eralier posting) is opening every letter in an evelope, putting the contents in a see-through bag and adding a new addres label.
Except that's not what it's doing. You're handing the letter to them and asking them to put it in an envelope, preferably one of those fancy ones that make it harder to see the contents, and send it. They're pretending like they don't have any of those fancy envelopes and instead putting it in a clear plastic bag. If you want it in a fancy envelope, make sure you specify that it has to be rather than that's what you'd like it to be.
Or, better yet, mask the contents yourself at the application layer rather than relying on the transport layer. X.509 and PGP are both pains, but they do work and would make this a total non-issue.
Life has many choices. Eternity has two. What's yours?
Actually, that depends strongly on the jurisdiction, "tampering with email" is a crime e.g. in Germany.
Well, you have to sell it under a brand that sounds like "Cisco" ;)
You should see what happened at a previous job a decade ago when I showed the CTO we could cut our spam/filter budget by 95%, *AND* save bandwidth on the mailserver if I simply immediately rejected /all/ connections with connections geolocating to China with only 2 false positives a year going back in recorded history...
Admittedly, most spam isn't from there, and possibly never was... but at least for our corp, and hack/relay attempts... it actually cut op-ex. Hopefully they've turned that off by now...
I stand with you "old server? Guess they should have asked for a patch budget..."
Better safe than sorry.
Somewhere, something incredible is waiting to be known. -Carl Sagan
The encryption is a method I use to keep others from reading said copyrited work, correct?
Nope. In this case, the work is not itself encrypted, the communication channel to but one mail server is.
Apply GPG, GPG, or S/MIME encryption and your message body is still safe.
I like that argument and I hope it gets heard in front of a judge. I do wonder though since it is actually the packet from the upstream server that is modified and the sender is downgrading their security to accommodate, then sending an unmodified message is there a violation? Is their any legal protection that would stop an ISP from modifying the parameters, but not substance of the upstream mail server's packet? It seams like the upstream mail service provider is the one truly being wronged because the intent of their transmission has not been honored and has been modified without consent such as their ability to provide a secure service to their customer has been harmed.
So "copyrite" is when I see my neighbor sacrificing goats to a pagan god, and I do the same?
Modder didn't get the joke did they?
No it does not affect Fastmail. I also use it and in fact even if you use an email client instead of webmail, they support full encryption without upgrading through STARTTLS.
See: https://www.fastmail.com/help/...
If you encrypt your e-mail prior to sending, sure. But SSL and TLS aren't part of your e-mail. They components of the system for transmitting your email. Not part of the message you wrote.
Only boring people are ever bored.
AIUI, they are not tampering the client-to-MSA connection —where the client is often configured to require STARTTLS, port 465, or whatever— but the MSA-to-MX one. There are no guarantees that encription is available between eny two hops along the mail path, and there have never been.
Sorry, I was wrong. They intercept the client-to-MTA (or MUA-to-MTA) connection, the article says.
Port 25 is mainly used for relaying (which is what confused me). Malware doing direct-to-MX SMTP does in fact use port 25. Modern clients should be configured to use port 587 instead. Since port 587 (MSA) requires sender authentication, there would be no reason to block/intercept it.
I'm trying to get them to block-list all of Nigeria off the Webmail. With 120000 users we get about a couple compromised accounts each month, which I think is actually good. And 99% of the time it's from a 41.xxx address.
Maybe we deserve this world ?