It's called "reflection" versus "scattering". Smooth surfaces reflect. Rough surfaces scatter. And the difference between smooth and rough depends on the wavelength of the incoming wave.
My exact quote:
"The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header"
Yes. That's a function of the mail client and not the email itself.
For the third time, I'm referring to the fact that replies generally start with a different text style than the rest of the thread when reading an e-mail in a window which shows a message,
Perhaps in pieces of crap like Outlook that don't care about email standards, but they don't look any different in any real email client. Any email client that changes the body of the email based on read or unread status is broken, period.
Of course! But kindly tell that to the tens of millions of non-Firefox users when "clicking a link" works just fine now.
I don't have to tell them anything. This is a fact. Your excuse that we need enhanced email so that cutting and pasting a URL will work is wrong. We don't need that.
So, what's your preferred term for "e-mail with a binary attachment but which lacks formatting or markup"?
I don't know what semantic game you are trying to play here. Your claim that "non-plain-text email" means "isn't email" is patent bullshit.
Because in your haste to tell me to stop being stupid, you managed to prove my point. There is ambiguity in the term.
You seem to be the only person I've ever heard think that "non-plain-text email" means "not email". Most of the people with a brain understand that "non-plain-text email" means it is email that isn't plain text. There is no ambiguity.
Great! You should have no problem getting the millions of Outlook users to migrate over to your superior e-mail client..
Game over. Knowing that Outlook is a defective email client doesn't imply any need to convert nimrods who like defective email clients.
And yet, you've provided solutions to neither.
Of course I have. Don't paste a URL into a search box, for one. Simple. Do it once and you'll learn. I don't remember what your other example of necessity for HTML email was, but the simple alternative is to not use HTML email. Simple.
There are plenty of adults making more money than you who use Outlook every day at their desk.
And here we are at ad hominem, with a healthy dose of "forty million Frenchmen can't be wrong" logic.
I just know that if "quality of software", "adherence to standards" or even "effectiveness of support" were reasons why software is popular,
This isn't an argument about what software is popular, it is about the need for anything more than plain text. Every example you've presented as why you need more than plain text is trivially handled by using plain text. That's why you lose the argument -- you're reliance on popularity to define "right".
Telling them that plaintext e-mail is going to be unilaterally implemented in the name of security
And I've said that kind of thing exactly when? Argue about this with someone else. You lose this one.
Passive links; or at least what I'd consider "active" would be if the program were handling and opening them itself.
Any link that results in the question "do you want to open this link" when I hit C/R is active. Passive is if I have to copy/paste it into something else. Passive is if I have to determine it is a URL and do something with it. Alpine is the former. It does something other than sit there and look at me on the screen. It determines what the URLs are and will perform specific actions on them.
Server A contacts Server B with a mail notification, with a sender email address and message serial number.
There is no "serial number". The message id is part of the header. The "sender email address" appears in the From: header and may have no relation to server A at all.
Then, it contacts that server and requests the message by sender and message ID.
So you go all the way to getting the data from the message just to disconnect and then ask for it all again. And you may try to connect to a server that has not been involved in any part of the process.
If there is a match, server A responds to server B with the email.
Message ids are not authentication. Second, how does the server know to whom it has delivered the message? It is not sufficient to ask for "sender/id", you must also ask by recipient. Just one quick second of thought shows that this would be a great way for someone to DOS an email sent to multiple recipients. I get the email with the entire To: and CC: headers, then connect to Server A asking for the message -- and now Server A thinks it has delivered it to all recipients, not just me. Fun.
If there isn't, Server A knows somebody just failed to send it spam,
Server A is the sending server. It's already been sent the message. It was trying to send it on to B in your hypothetical situation. And I hate to point out that the "sender email address" may be from any domain at all, not just the domain associated with A's HELO (or IP address). It is quite possible that your Server B would be contacting a server that has already processed and delivered the email you are now asking it for, or may have no knowledge of that email because the sender used a different server to send the email to begin with. For example, I have several email accounts set up on my mobile device that use just a couple mail servers for outgoing email. They know I'm valid because I AUTH with them prior to sending. You will see a domain in my From header that has nothing to do with the server I sent it out through, or the server that is the last one to handle it prior to your Server B.
And in any case, it is quite possible that a domain uses one server for outgoing email and a different one for incoming. I.e., the fact that my server A connects to your server B on your port 25 does not mean I have a server listening for your connections on port 25. My MX may be a completely different system on the other side of the planet.
Bot nets would be unable to exploit that (assuming you use sufficiently long message IDs to avoid brute forcing),
The message id is generated by the sender of the message and is unchanged during transit. You, as the recipient, or Server A as an MTA, have no say in how the message id is formed.
and it would be much easier to blacklist spam domains.
Your proposed idea does nothing to help this, and it requires that a large part of the spam be delivered to the recipient server to start with. And then it fails for any number of reasons that have nothing to do with the email being spam.
Yet another over-zealous standard violating anti-spam systems.
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Diagrams, drawings and photograph are pretty vital in many day to day communications.
"If" was a critical word in what I wrote. I highlighted it in the quote.
You do realize that you can still have plain text email and include images, don't you? They don't have to be inlined to be useful.
for yours to be a reliable assumption.
You're right, for clearly the definition of "if" escapes many people.
And you're just clueless if you think everybody is, or even should be, technically proficient enough to know a "search bar" from a "URL bar,"
Show me where I said they needed to be. I said that it isn't an excuse to require crap in email more than plain text. The fact you paste a URL into a search bar instead of the address bar is your ignorance and not justification for new standards that you won't be any better capable of understanding.
There is zero probability that even a barely noticeable fraction of email users will suddenly decide to drop back to 1992 era email so there's little point even discussing it --
And yet here you are. Or is your participation just so you can jump down my throat for something I didn't say?
Not history at all. You said it yourself: it's showing you the text out of the HTML.
Which means it is no longer plain-text email only. I can remember when pine was.
And only the text, because Alpine is still text-only.
I get an amazing amount of email that Alpine shows me active links in.
but without the attack vectors that come with it.
Active links are attack vectors. It's bread and butter for most phishing attacks. "Your account will be disabled unless you click here" is not "plain text only". That it only shows text does not mean it is not processing things other than plain-text email.
Spoofed sender addresses won't work so well if my server can't look up the domain MX record,
MX records are not mandatory. The standards are quite clear on that, and how to deal with it. Any mail filter that blocks based on a missing MX record is violating the standards.
But zealots will be zealots. All kinds of standards-breaking goes on in the name of spam fighting. Empirical knowledge reigns. Things like the seemingly ubiquitous list of valid email address characters that was developed by some ignorant web programmer and ignores the existing explicit valid list. (And yes, I'm referring to the morons who ignore '+'.)
or if the listed mail server doesn't know anything about the email I think it has for me.
Not sure what you mean here, since the sending server obviously knows something about the email it has for you -- it's sending it. If you're saying that you should be able to connect back to the sending server to ask about email for you, then you've just created a huge security issue. How does the sending server validate your reverse access to know it really is you asking about email for you?
1. I was not referring to whether a new e-mail was bold or not, but how text is shown within an e-mail.
No, you were pretty specific as to "clearing" the new mail in the thread, and this has nothing to do with what the email itself looks like. If you have an email client that changes the email itself to show status, then you have a very very poor email client. But we already know that.
3. So the way *your* mail scanner functions is the baseline for how things should work?
I said nothing about how my "mail scanner" works. I told you of how at least one of them DOES work, and why that makes one-time reset links useless. There goes your excuse for non-plain-text email based on "password reset links", if they weren't already made meaningless by the ability to copy and paste the plain text URL representation.
4. Firefox handles them wonderfully.
Which is proof that there is no inherent problem with line breaks in a copy/paste URL. Sheesh, if you knew anything, you ought to at least realize that "\n" is not a valid character in a URL and EVERY web client should be able to ignore them.
The Google search bar / MSN search bar / WhateverBrowserHijacker search bar is a different story,
You don't paste a URL into a SEARCH BAR, you nimrod. It's a URL.
and the number of people who think that's an address bar vastly outnumber Firefox users.
Nimrods don't know how to use their browsers, film at 11.
5. I very much do know what I'm talking about.
Not when you try to debate if "attachments" are "plain text email" or not. Not when you bring up Outlook as the benchmark.
The point I was getting at, if you're going to be pedantic about it, is that "plain text e-mail" can mean "if it's not text, it's not e-mail",
Oh for Christ's sake, stop being stupid. "Plain text email" means it is plain text. If it isn't plain text it isn't plain text email, not 'it isn't email'.
6. Outlook is far from an exemplary piece of software, but I'm hard pressed to point to a locally-installed mail client with a greater marketshare.
Marketshare is not how one defines a good email client.
Now, we can certainly argue that Microsoft's way of extending it is far from ideal,
If you think there is any argument about that, then you truly are hopeless. Go back to Outlook and leave the discussion of email systems to the adults, ok?
but my entire point is that the original e-mail standards are insufficient for most modern uses.
Bullshit. Every "use case" you've made has been shown to be trivially done with plain text email using existing standards. Your biggest arguments are "Outlook yada yada" and "nimrods paste URLs in the wrong place", neither of which justify anything.
I can't say I "like" Outlook, but treating it like it's irrelevant is of no assistance, either.
Nobody it treating it like it is irrelevant, but by trying to use it as a baseline for good practice is simply ridiculous. As soon as you use "but Outlook does it this way" as an argument about how email should work, you've both lost that argument AND shown that you are a clueless Microsoft wanker.
At the same time, plaintext e-mail has its faults, too. The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header.
You have no clue what you're saying here. The "new message" flag is a function of the gui or text client, not the email itself. Alpine shows an "N" next to new messages, and that's pretty clear. Evolution uses bold to show new messages, in the message list.
Inline image embedding is abused by marketers, but it makes it far easier to send tutorials or support requests via screenshot sequences.
Images do not have to be inline to be useful.
Yes, clickable links are a security risk, but that's how password reset e-mails work now.
"Because some idiots who don't know good programming and security practices do it this way, it must be good."
News flash: there are mail systems that actually connect to anything in a message that looks like a URL as a way of testing for malmail. I sent someone an email with a link to a website I run and almost instantly I saw "them" access that link in the logs. Not them, the mail server that was scanning their incoming email. Any "one time reset" link sent to that user is not going to work, ever, because the server will have exhausted the "one time" access.
Do you really expect users to copy the complete URL into the address bar without an issue? If there's a line break in there, you're really screwed.
Yes, and of course not. I do it all the time. "Line breaks" in the URL are not a problem. Firefox handles them just fine.
All of that hasn't even begun to address attachments, because technically it is possible for mail attachments to count as both a part of plaintext e-mails and not.
If you don't know what you are talking about, please don't comment on technical things. Attachments are attachments. They are not part of the plain-text body.
The attachment file types themselves, however, are a mess. Outlook cries wolf at *every* attachment,
Say no more, I now understand why you think the way you do. Outlook is a piece of shit created by Microsoft that goes out of its way to avoid the existing standards for email, and is the source of the abomination known as "winmail.dat". If you think Outlook is some baseline to which good email practices should be compared, then you are... well, enough said. The rest of your rant is thus made moot.
Surprise! Alpine now renders HTML for you. Text-only Alpine is history. It may be limited to showing text because you're using it in an xterm, but it's showing the text from the HTML version.
The only time people run into issues is when a Microsoft Word document (.doc or.docx) is renamed to.rtf and loaded erroneously.
No, consider the wonderful "winmail.dat", which MS claims exists solely to protect RTF formatting for email. (It's actually what all poorly configured MS email clients send when they do attachments -- a tautology.)
And it's what poorly educated people send even after they've been told that their attachment is unreadable. It can't be THEIR fault, THEY can read it.
I've now officially given up on trying to get the information out of someone who sends winmail.dat attachments. I had one two days ago where I had to extract the attachment, copy it to a Linux system, install "tnef" (a package to deal with such crap), decode the winmail.dat, and then copy the resulting.doc file to another system where it could be read. And it turned out to be one page of text. A complete waste of time.
Myself I'd rather have the sender render and encode a highresolution bitmap file which compresses bilevel images very well allowing for high resolution (like DjVu format).
How about if you can't say it without red flashing italic large fonts you just don't bother saying it at all? Simple text conveys a lot of information simply. You don't need a.doc or.pdf to convey one page of text.
And tag the image with a plain-text section for screen readers, search and OCR to deal with.
Once you've devolved into drawing pictures instead of using words, it is very hard to convey in words what the picture does. A "plain text section" that says "a diagram of what I'm talking about" is pretty meaningless. I've had to deal with this kind of thing for years on a website that I run. It has tons of images, all generated automatically. The "alt text" links cannot be generated that way, so they are all "an image".
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Then I would slowly start to question 'what is wrong' with "your system".
Politics.
"Freedom" is why the government cannot order people to leave their homes. This is not a wrong in the system. "Politics" comes in when people exercise their freedom not to evacuate and then expect the government to make good their losses. That's the wrong part.
If anyone is lacking compassion, I have to agree that it would be the people who chose to stay behind despite ample warning, and who then demand to be rescued, needlessly endangering the lives of the rescuers. Putting other people in danger out of your own negligent behavior is not "being a decent human being".
Not everyone that rides out a hurricane is "stupid", some don't have the means to leave the area.
I emphasized the conditional part of the statement, which makes your response a nonsequitor. Everyone WHO CHOOSES TO STAY is stupid.
The drone has to be connected to a working cellphone to initialize. You can't do that without a battery.
That makes no sense at all. The drone talks to an app that run on Android (or iOS), and Android (or iOS) runs on a lot of things that don't have a "working cellphone", much less a cellphone number of any kind. You don't even need to have an internet connection.
And, of course, if you put the phone into airplane mode, it isn't being tracked, but it is "working", for a sufficient enough purpose for the DJI device.
But, registries and laws don't stop terrorists and other bad guys from doing their bad acts.
Actually, they do.
The laws against driving into a crowd of people did really well stopping the guy who drove into the crowd of people in Charlottesville with his registered vehicle, right?
When I received my Mavic Pro, I had to register it on-line and provide a trackable cell number before it would fly.
Terrorists have no idea how to buy a burner cell phone, or make up a realistic looking phone number, or just buy a different model. (The Mavic Pro is cute, but doesn't have a significant load capacity so is probably not going to be the UAS of choice anyway.) Not sure what you mean by "trackable", since a cell phone that has no battery in it can have a valid number but not be trackable by anyone. Even if you have to be trackable for just the couple of minutes that DJI needs to call you (?) on that phone (and can tell the difference between calling you on a cell phone and a landline), remove the battery and you're no longer trackable.
but most terrorists aren't very smart.
One per cell. That's all it takes. And it's not like the barriers are all that high to start with.
The reason this database is stupid is not because to won't stop anyone from doing stupid or illegal things, even though that is true. It's stupid because we already have history of seeing such things fail miserably. Yes, the database of aircraft registrations works, but that's because there aren't that many of them and they are pretty big. They're also typically operated out of places where there are other pilots who can/will rat out a violator. (Private airstrips don't have such people, and who knows how many aircraft are not registered that fly out of those?)
It's amazing to read some of the NTSB accident reports and see things like the pilot was five years out of currency with his BFR, had no medical, and the aircraft hadn't had an annual for ten years. Even with all of the registrations and laws, it still happens.
The FCC realized the problems of registering cheap, small things when it tried demanding that CB radio users get a CB radio license. They did that for a few years and then gave up. But they didn't give up requiring that commercial TV stations have licenses. That's kinda a good analogy to the difference between a 747 or even a C172 and a Mavic.
I think it is more appropriate to measure distances in "What's New Pussycats" than Danke Shoens. First of all, the latter is in a foreign language and therefore won't be immediately connected with Earth.
John Mulaney has an outstanding story about "What's New Pussycat" and the best dinner he's ever had.
when the automated driver gets confused or blinded it will always do the same thing: pull over and stop as soon as it's safe to do so.
If it is confused or blinded, it by definition cannot know when it is safe to move, even if that is just to pull over and stop. Woopsies, it didn't see that bike rider passing him on the right and now someone is dead.
Claiming special status as to safety because it will make some "known operation" when it gets confused is not supporting the claim that AV will be magically safe.
As if it were just luck, and I didn't understand that the laws differ from place to place. Sheesh.
Over here, you are required to stop at a pedestrian crossing if there are people close to it.
What an amazingly stupid law. Someone walking past a crosswalk forces cars to stop as if they were going to cross.
There are examples of driving ed teachers needing to get out of the car to ask people to hang out somewhere not right next to a pedestrian crossing.
How dare he! I mean the driving instructor. Doesn't he know that pedestrians are the only concern? But then, it is an amazingly stupid law for just such a reason. I could force all traffic to a complete halt by just standing on the corner with no intention of crossing. While I can stand IN the crosswalk on an Oregon street and force cars to stop for a bit, once they realize I have no intent to cross they can proceed. IN the crosswalk with the intent to cross. That's how we deal with stupid or malicious pedestrians.
Too bad they don't even try to improve it so that it's reasonable before it gets put on the market,
To quote someone else loosely: it is unconscionable that SDC technology is not already being adopted. There is no time for "reasonable" improvements or further study. Today is now.
Well we're talking about debris falling on the road sizable enough to cause an accident, not rock chips.
A common concept in aviation is that every accident begins as a sequence of events that aren't necessarily individually fatal. In this case, as I pointed out, that "rock chip" may be taking one of your sensors out of operation. That's the starting link in the chain.
They should absolutely be able to detect a kid on a bridge about to drop a rock.
"Hopeless optimism" is not a very good way to design safety systems. That you think an AV computer can detect a "kid on a bridge holding a rock" (when the kid may be on the downstream side of the bridge and completely hidden from the AV until he's in the rear-view mirror) AND that his intent is to drop that rock, is cute but, as the topic sentence alludes to, hopelessly optimistic.
I think the challenge stands, and that the AV will be the loser in any such confrontation. "Falling debris" is not a solved problem.
I didn't bother going back a couple of levels to figure out who said what. Doesn't matter.
I was facing with the direction of traffic, about 2' from the road at the crosswalk, then turned 180 degrees to face traffic.
So you weren't facing the street, you were facing against the flow of traffic. That's not an indication that you are intending to cross. It's an indication that you want to go back the way you came.
the car came to a stop, it had decided there was a good chance I was going to enter the crosswalk.
Unfortunately, the rules (as they exist in my state) say nothing about "a good chance" or a confusing description that has you facing parallel to the curb but somehow stepping towards it. You had not entered the crosswalk, the vehicle was stopping for no legally valid reason.
It predicted that I was going to enter the crosswalk and so it stopped, rather than risk running me over. How cool is that?
Not very, as I've already explained. Random stops for no reason are not conducive to safety to others, and will result in gridlock in situation where there is anyone standing on a sidewalk -- they MIGHT maybe guessing want to cross!
I'm sure after that event the engineers tweaked the predictive levels for stopping the car,
And for a production vehicle, I'm sure that there would be no engineers tweaking anything, it would continue down the street and then stop again for someone who wasn't crossing, and then again a bit further on...
but overall I feel extremely safe around them and trust them quite a bit more than humans at this point.
You are demonstrating the quite selfish attitude of a pedestrian who expects every vehicle within 100 feet of him to kowtow to his every whim, anticipating his every action, and doing nothing that might ever result in him being hurt no matter how stupidly he is behaving. I see this regularly, with the fool who steps into the crosswalk as a car is just a couple of feet from entering it, hoping that the laws of man (car must stop before entering the crosswalk) will supersede the laws of physics (coefficient of friction of rubber/asphalt sufficient to halt the vehicle prior to entering the crosswalk and creaming the ped).
There are other cars on the street, and their safety needs to be a concern, too. A car that stops unexpectedly for no reason in traffic is creating a hazard. It is less safe for others.
The drivers are generally pretty chilled out, attentive, but not having a bad time being driven about.
I really cannot figure out what drivers you are talking about here. The AVs have none; driversof non-AV are not "being driven about", they are being faced with AV that aren't following the rules of the road and are stopping for no reason. Yes, they should be defensive drivers and ready to deal with this stupidity just as they would for a human driver that slams on the brakes for no reason, but the hazard is there when it need not be.
Maybe. I see it largely going the other way where people care less about getting a few car lengths ahead because they are watching a movie or playing on their phone.
Nope. I watch movies and play on the phone now and I know it is much safer to do that when I am more car lengths ahead of someone else than following behind him.
People will hack the AI because it exists. Owners will do so because it will make their car cooler. Others will do it because it is a challenge and they can get their leet haxor creds by causing damage.
But automated cars are controlled by computers that make decisions in fractions of a second! They should absolutely be able to avoid debris falling on the road.
Let's test that hypothesis. You get your AV going down I5 at posted legal speed and I'll drop a rock on it from an overpass. I predict your AV will not avoid "debris falling on the road" when the laws of physics say your AV cannot stop in time to avoid hitting/being hit by it.
If they don't have the sensors for it, then that's a problem.
I have three significant chips in my windshield that came from small rocks being kicked up by trucks in front of me. I challenge you to have a camera with sufficient resolution, and computer with sufficient processing speed, to detect, much less avoid such damage. Then consider that the camera you may have trying to detect this stuff may be the target of that rock, and it becomes not so good for much.
Slashdot Mirror
It's called "reflection" versus "scattering". Smooth surfaces reflect. Rough surfaces scatter. And the difference between smooth and rough depends on the wavelength of the incoming wave.
My exact quote: "The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header"
Yes. That's a function of the mail client and not the email itself.
For the third time, I'm referring to the fact that replies generally start with a different text style than the rest of the thread when reading an e-mail in a window which shows a message,
Perhaps in pieces of crap like Outlook that don't care about email standards, but they don't look any different in any real email client. Any email client that changes the body of the email based on read or unread status is broken, period.
Of course! But kindly tell that to the tens of millions of non-Firefox users when "clicking a link" works just fine now.
I don't have to tell them anything. This is a fact. Your excuse that we need enhanced email so that cutting and pasting a URL will work is wrong. We don't need that.
So, what's your preferred term for "e-mail with a binary attachment but which lacks formatting or markup"?
I don't know what semantic game you are trying to play here. Your claim that "non-plain-text email" means "isn't email" is patent bullshit.
Because in your haste to tell me to stop being stupid, you managed to prove my point. There is ambiguity in the term.
You seem to be the only person I've ever heard think that "non-plain-text email" means "not email". Most of the people with a brain understand that "non-plain-text email" means it is email that isn't plain text. There is no ambiguity.
Great! You should have no problem getting the millions of Outlook users to migrate over to your superior e-mail client..
Game over. Knowing that Outlook is a defective email client doesn't imply any need to convert nimrods who like defective email clients.
And yet, you've provided solutions to neither.
Of course I have. Don't paste a URL into a search box, for one. Simple. Do it once and you'll learn. I don't remember what your other example of necessity for HTML email was, but the simple alternative is to not use HTML email. Simple.
There are plenty of adults making more money than you who use Outlook every day at their desk.
And here we are at ad hominem, with a healthy dose of "forty million Frenchmen can't be wrong" logic.
I just know that if "quality of software", "adherence to standards" or even "effectiveness of support" were reasons why software is popular,
This isn't an argument about what software is popular, it is about the need for anything more than plain text. Every example you've presented as why you need more than plain text is trivially handled by using plain text. That's why you lose the argument -- you're reliance on popularity to define "right".
Telling them that plaintext e-mail is going to be unilaterally implemented in the name of security
And I've said that kind of thing exactly when? Argue about this with someone else. You lose this one.
Passive links; or at least what I'd consider "active" would be if the program were handling and opening them itself.
Any link that results in the question "do you want to open this link" when I hit C/R is active. Passive is if I have to copy/paste it into something else. Passive is if I have to determine it is a URL and do something with it. Alpine is the former. It does something other than sit there and look at me on the screen. It determines what the URLs are and will perform specific actions on them.
Server A contacts Server B with a mail notification, with a sender email address and message serial number.
There is no "serial number". The message id is part of the header. The "sender email address" appears in the From: header and may have no relation to server A at all.
Then, it contacts that server and requests the message by sender and message ID.
So you go all the way to getting the data from the message just to disconnect and then ask for it all again. And you may try to connect to a server that has not been involved in any part of the process.
If there is a match, server A responds to server B with the email.
Message ids are not authentication. Second, how does the server know to whom it has delivered the message? It is not sufficient to ask for "sender/id", you must also ask by recipient. Just one quick second of thought shows that this would be a great way for someone to DOS an email sent to multiple recipients. I get the email with the entire To: and CC: headers, then connect to Server A asking for the message -- and now Server A thinks it has delivered it to all recipients, not just me. Fun.
If there isn't, Server A knows somebody just failed to send it spam,
Server A is the sending server. It's already been sent the message. It was trying to send it on to B in your hypothetical situation. And I hate to point out that the "sender email address" may be from any domain at all, not just the domain associated with A's HELO (or IP address). It is quite possible that your Server B would be contacting a server that has already processed and delivered the email you are now asking it for, or may have no knowledge of that email because the sender used a different server to send the email to begin with. For example, I have several email accounts set up on my mobile device that use just a couple mail servers for outgoing email. They know I'm valid because I AUTH with them prior to sending. You will see a domain in my From header that has nothing to do with the server I sent it out through, or the server that is the last one to handle it prior to your Server B.
And in any case, it is quite possible that a domain uses one server for outgoing email and a different one for incoming. I.e., the fact that my server A connects to your server B on your port 25 does not mean I have a server listening for your connections on port 25. My MX may be a completely different system on the other side of the planet.
Bot nets would be unable to exploit that (assuming you use sufficiently long message IDs to avoid brute forcing),
The message id is generated by the sender of the message and is unchanged during transit. You, as the recipient, or Server A as an MTA, have no say in how the message id is formed.
and it would be much easier to blacklist spam domains.
Your proposed idea does nothing to help this, and it requires that a large part of the spam be delivered to the recipient server to start with. And then it fails for any number of reasons that have nothing to do with the email being spam.
Yet another over-zealous standard violating anti-spam systems.
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Diagrams, drawings and photograph are pretty vital in many day to day communications.
"If" was a critical word in what I wrote. I highlighted it in the quote. You do realize that you can still have plain text email and include images, don't you? They don't have to be inlined to be useful.
for yours to be a reliable assumption.
You're right, for clearly the definition of "if" escapes many people.
And you're just clueless if you think everybody is, or even should be, technically proficient enough to know a "search bar" from a "URL bar,"
Show me where I said they needed to be. I said that it isn't an excuse to require crap in email more than plain text. The fact you paste a URL into a search bar instead of the address bar is your ignorance and not justification for new standards that you won't be any better capable of understanding.
There is zero probability that even a barely noticeable fraction of email users will suddenly decide to drop back to 1992 era email so there's little point even discussing it --
And yet here you are. Or is your participation just so you can jump down my throat for something I didn't say?
Not history at all. You said it yourself: it's showing you the text out of the HTML.
Which means it is no longer plain-text email only. I can remember when pine was.
And only the text, because Alpine is still text-only.
I get an amazing amount of email that Alpine shows me active links in.
but without the attack vectors that come with it.
Active links are attack vectors. It's bread and butter for most phishing attacks. "Your account will be disabled unless you click here" is not "plain text only". That it only shows text does not mean it is not processing things other than plain-text email.
Spoofed sender addresses won't work so well if my server can't look up the domain MX record,
MX records are not mandatory. The standards are quite clear on that, and how to deal with it. Any mail filter that blocks based on a missing MX record is violating the standards.
But zealots will be zealots. All kinds of standards-breaking goes on in the name of spam fighting. Empirical knowledge reigns. Things like the seemingly ubiquitous list of valid email address characters that was developed by some ignorant web programmer and ignores the existing explicit valid list. (And yes, I'm referring to the morons who ignore '+'.)
or if the listed mail server doesn't know anything about the email I think it has for me.
Not sure what you mean here, since the sending server obviously knows something about the email it has for you -- it's sending it. If you're saying that you should be able to connect back to the sending server to ask about email for you, then you've just created a huge security issue. How does the sending server validate your reverse access to know it really is you asking about email for you?
1. I was not referring to whether a new e-mail was bold or not, but how text is shown within an e-mail.
No, you were pretty specific as to "clearing" the new mail in the thread, and this has nothing to do with what the email itself looks like. If you have an email client that changes the email itself to show status, then you have a very very poor email client. But we already know that.
3. So the way *your* mail scanner functions is the baseline for how things should work?
I said nothing about how my "mail scanner" works. I told you of how at least one of them DOES work, and why that makes one-time reset links useless. There goes your excuse for non-plain-text email based on "password reset links", if they weren't already made meaningless by the ability to copy and paste the plain text URL representation.
4. Firefox handles them wonderfully.
Which is proof that there is no inherent problem with line breaks in a copy/paste URL. Sheesh, if you knew anything, you ought to at least realize that "\n" is not a valid character in a URL and EVERY web client should be able to ignore them.
The Google search bar / MSN search bar / WhateverBrowserHijacker search bar is a different story,
You don't paste a URL into a SEARCH BAR, you nimrod. It's a URL.
and the number of people who think that's an address bar vastly outnumber Firefox users.
Nimrods don't know how to use their browsers, film at 11.
5. I very much do know what I'm talking about.
Not when you try to debate if "attachments" are "plain text email" or not. Not when you bring up Outlook as the benchmark.
The point I was getting at, if you're going to be pedantic about it, is that "plain text e-mail" can mean "if it's not text, it's not e-mail",
Oh for Christ's sake, stop being stupid. "Plain text email" means it is plain text. If it isn't plain text it isn't plain text email, not 'it isn't email'.
6. Outlook is far from an exemplary piece of software, but I'm hard pressed to point to a locally-installed mail client with a greater marketshare.
Marketshare is not how one defines a good email client.
Now, we can certainly argue that Microsoft's way of extending it is far from ideal,
If you think there is any argument about that, then you truly are hopeless. Go back to Outlook and leave the discussion of email systems to the adults, ok?
but my entire point is that the original e-mail standards are insufficient for most modern uses.
Bullshit. Every "use case" you've made has been shown to be trivially done with plain text email using existing standards. Your biggest arguments are "Outlook yada yada" and "nimrods paste URLs in the wrong place", neither of which justify anything.
I can't say I "like" Outlook, but treating it like it's irrelevant is of no assistance, either.
Nobody it treating it like it is irrelevant, but by trying to use it as a baseline for good practice is simply ridiculous. As soon as you use "but Outlook does it this way" as an argument about how email should work, you've both lost that argument AND shown that you are a clueless Microsoft wanker.
At the same time, plaintext e-mail has its faults, too. The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header.
You have no clue what you're saying here. The "new message" flag is a function of the gui or text client, not the email itself. Alpine shows an "N" next to new messages, and that's pretty clear. Evolution uses bold to show new messages, in the message list.
Inline image embedding is abused by marketers, but it makes it far easier to send tutorials or support requests via screenshot sequences.
Images do not have to be inline to be useful.
Yes, clickable links are a security risk, but that's how password reset e-mails work now.
"Because some idiots who don't know good programming and security practices do it this way, it must be good."
News flash: there are mail systems that actually connect to anything in a message that looks like a URL as a way of testing for malmail. I sent someone an email with a link to a website I run and almost instantly I saw "them" access that link in the logs. Not them, the mail server that was scanning their incoming email. Any "one time reset" link sent to that user is not going to work, ever, because the server will have exhausted the "one time" access.
Do you really expect users to copy the complete URL into the address bar without an issue? If there's a line break in there, you're really screwed.
Yes, and of course not. I do it all the time. "Line breaks" in the URL are not a problem. Firefox handles them just fine.
All of that hasn't even begun to address attachments, because technically it is possible for mail attachments to count as both a part of plaintext e-mails and not.
If you don't know what you are talking about, please don't comment on technical things. Attachments are attachments. They are not part of the plain-text body.
The attachment file types themselves, however, are a mess. Outlook cries wolf at *every* attachment,
Say no more, I now understand why you think the way you do. Outlook is a piece of shit created by Microsoft that goes out of its way to avoid the existing standards for email, and is the source of the abomination known as "winmail.dat". If you think Outlook is some baseline to which good email practices should be compared, then you are ... well, enough said. The rest of your rant is thus made moot.
My email was text only Alpine.
Surprise! Alpine now renders HTML for you. Text-only Alpine is history. It may be limited to showing text because you're using it in an xterm, but it's showing the text from the HTML version.
The only time people run into issues is when a Microsoft Word document (.doc or .docx) is renamed to .rtf and loaded erroneously.
No, consider the wonderful "winmail.dat", which MS claims exists solely to protect RTF formatting for email. (It's actually what all poorly configured MS email clients send when they do attachments -- a tautology.)
And it's what poorly educated people send even after they've been told that their attachment is unreadable. It can't be THEIR fault, THEY can read it.
I've now officially given up on trying to get the information out of someone who sends winmail.dat attachments. I had one two days ago where I had to extract the attachment, copy it to a Linux system, install "tnef" (a package to deal with such crap), decode the winmail.dat, and then copy the resulting .doc file to another system where it could be read. And it turned out to be one page of text. A complete waste of time.
Myself I'd rather have the sender render and encode a highresolution bitmap file which compresses bilevel images very well allowing for high resolution (like DjVu format).
How about if you can't say it without red flashing italic large fonts you just don't bother saying it at all? Simple text conveys a lot of information simply. You don't need a .doc or .pdf to convey one page of text.
And tag the image with a plain-text section for screen readers, search and OCR to deal with.
Once you've devolved into drawing pictures instead of using words, it is very hard to convey in words what the picture does. A "plain text section" that says "a diagram of what I'm talking about" is pretty meaningless. I've had to deal with this kind of thing for years on a website that I run. It has tons of images, all generated automatically. The "alt text" links cannot be generated that way, so they are all "an image".
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Then I would slowly start to question 'what is wrong' with "your system".
Politics.
"Freedom" is why the government cannot order people to leave their homes. This is not a wrong in the system. "Politics" comes in when people exercise their freedom not to evacuate and then expect the government to make good their losses. That's the wrong part.
If anyone is lacking compassion, I have to agree that it would be the people who chose to stay behind despite ample warning, and who then demand to be rescued, needlessly endangering the lives of the rescuers. Putting other people in danger out of your own negligent behavior is not "being a decent human being".
Not everyone that rides out a hurricane is "stupid", some don't have the means to leave the area.
I emphasized the conditional part of the statement, which makes your response a nonsequitor. Everyone WHO CHOOSES TO STAY is stupid.
The drone has to be connected to a working cellphone to initialize. You can't do that without a battery.
That makes no sense at all. The drone talks to an app that run on Android (or iOS), and Android (or iOS) runs on a lot of things that don't have a "working cellphone", much less a cellphone number of any kind. You don't even need to have an internet connection.
And, of course, if you put the phone into airplane mode, it isn't being tracked, but it is "working", for a sufficient enough purpose for the DJI device.
But, registries and laws don't stop terrorists and other bad guys from doing their bad acts.
Actually, they do.
The laws against driving into a crowd of people did really well stopping the guy who drove into the crowd of people in Charlottesville with his registered vehicle, right?
When I received my Mavic Pro, I had to register it on-line and provide a trackable cell number before it would fly.
Terrorists have no idea how to buy a burner cell phone, or make up a realistic looking phone number, or just buy a different model. (The Mavic Pro is cute, but doesn't have a significant load capacity so is probably not going to be the UAS of choice anyway.) Not sure what you mean by "trackable", since a cell phone that has no battery in it can have a valid number but not be trackable by anyone. Even if you have to be trackable for just the couple of minutes that DJI needs to call you (?) on that phone (and can tell the difference between calling you on a cell phone and a landline), remove the battery and you're no longer trackable.
but most terrorists aren't very smart.
One per cell. That's all it takes. And it's not like the barriers are all that high to start with.
The reason this database is stupid is not because to won't stop anyone from doing stupid or illegal things, even though that is true. It's stupid because we already have history of seeing such things fail miserably. Yes, the database of aircraft registrations works, but that's because there aren't that many of them and they are pretty big. They're also typically operated out of places where there are other pilots who can/will rat out a violator. (Private airstrips don't have such people, and who knows how many aircraft are not registered that fly out of those?)
It's amazing to read some of the NTSB accident reports and see things like the pilot was five years out of currency with his BFR, had no medical, and the aircraft hadn't had an annual for ten years. Even with all of the registrations and laws, it still happens.
The FCC realized the problems of registering cheap, small things when it tried demanding that CB radio users get a CB radio license. They did that for a few years and then gave up. But they didn't give up requiring that commercial TV stations have licenses. That's kinda a good analogy to the difference between a 747 or even a C172 and a Mavic.
John Mulaney has an outstanding story about "What's New Pussycat" and the best dinner he's ever had.
It's cute that you can simplify the problem down to you
Whoosh.
And that would pretty much settle the question of where to start looking to 'apportion blame' in the event of an accident.
Oh, no! AV aren't GOING to have accidents. What blame is there to "apportion" (not sure why you used scare quotes on that) if there is no accident?
when the automated driver gets confused or blinded it will always do the same thing: pull over and stop as soon as it's safe to do so.
If it is confused or blinded, it by definition cannot know when it is safe to move, even if that is just to pull over and stop. Woopsies, it didn't see that bike rider passing him on the right and now someone is dead.
Claiming special status as to safety because it will make some "known operation" when it gets confused is not supporting the claim that AV will be magically safe.
Good thing you got the parenthesis in.
As if it were just luck, and I didn't understand that the laws differ from place to place. Sheesh.
Over here, you are required to stop at a pedestrian crossing if there are people close to it.
What an amazingly stupid law. Someone walking past a crosswalk forces cars to stop as if they were going to cross.
There are examples of driving ed teachers needing to get out of the car to ask people to hang out somewhere not right next to a pedestrian crossing.
How dare he! I mean the driving instructor. Doesn't he know that pedestrians are the only concern? But then, it is an amazingly stupid law for just such a reason. I could force all traffic to a complete halt by just standing on the corner with no intention of crossing. While I can stand IN the crosswalk on an Oregon street and force cars to stop for a bit, once they realize I have no intent to cross they can proceed. IN the crosswalk with the intent to cross. That's how we deal with stupid or malicious pedestrians.
Too bad they don't even try to improve it so that it's reasonable before it gets put on the market,
To quote someone else loosely: it is unconscionable that SDC technology is not already being adopted. There is no time for "reasonable" improvements or further study. Today is now.
Well we're talking about debris falling on the road sizable enough to cause an accident, not rock chips.
A common concept in aviation is that every accident begins as a sequence of events that aren't necessarily individually fatal. In this case, as I pointed out, that "rock chip" may be taking one of your sensors out of operation. That's the starting link in the chain.
They should absolutely be able to detect a kid on a bridge about to drop a rock.
"Hopeless optimism" is not a very good way to design safety systems. That you think an AV computer can detect a "kid on a bridge holding a rock" (when the kid may be on the downstream side of the bridge and completely hidden from the AV until he's in the rear-view mirror) AND that his intent is to drop that rock, is cute but, as the topic sentence alludes to, hopelessly optimistic.
I think the challenge stands, and that the AV will be the loser in any such confrontation. "Falling debris" is not a solved problem.
In the case you state ,that was me,
I didn't bother going back a couple of levels to figure out who said what. Doesn't matter.
I was facing with the direction of traffic, about 2' from the road at the crosswalk, then turned 180 degrees to face traffic.
So you weren't facing the street, you were facing against the flow of traffic. That's not an indication that you are intending to cross. It's an indication that you want to go back the way you came.
the car came to a stop, it had decided there was a good chance I was going to enter the crosswalk.
Unfortunately, the rules (as they exist in my state) say nothing about "a good chance" or a confusing description that has you facing parallel to the curb but somehow stepping towards it. You had not entered the crosswalk, the vehicle was stopping for no legally valid reason.
It predicted that I was going to enter the crosswalk and so it stopped, rather than risk running me over. How cool is that?
Not very, as I've already explained. Random stops for no reason are not conducive to safety to others, and will result in gridlock in situation where there is anyone standing on a sidewalk -- they MIGHT maybe guessing want to cross!
I'm sure after that event the engineers tweaked the predictive levels for stopping the car,
And for a production vehicle, I'm sure that there would be no engineers tweaking anything, it would continue down the street and then stop again for someone who wasn't crossing, and then again a bit further on...
but overall I feel extremely safe around them and trust them quite a bit more than humans at this point.
You are demonstrating the quite selfish attitude of a pedestrian who expects every vehicle within 100 feet of him to kowtow to his every whim, anticipating his every action, and doing nothing that might ever result in him being hurt no matter how stupidly he is behaving. I see this regularly, with the fool who steps into the crosswalk as a car is just a couple of feet from entering it, hoping that the laws of man (car must stop before entering the crosswalk) will supersede the laws of physics (coefficient of friction of rubber/asphalt sufficient to halt the vehicle prior to entering the crosswalk and creaming the ped).
There are other cars on the street, and their safety needs to be a concern, too. A car that stops unexpectedly for no reason in traffic is creating a hazard. It is less safe for others.
The drivers are generally pretty chilled out, attentive, but not having a bad time being driven about.
I really cannot figure out what drivers you are talking about here. The AVs have none; driversof non-AV are not "being driven about", they are being faced with AV that aren't following the rules of the road and are stopping for no reason. Yes, they should be defensive drivers and ready to deal with this stupidity just as they would for a human driver that slams on the brakes for no reason, but the hazard is there when it need not be.
Maybe. I see it largely going the other way where people care less about getting a few car lengths ahead because they are watching a movie or playing on their phone.
Nope. I watch movies and play on the phone now and I know it is much safer to do that when I am more car lengths ahead of someone else than following behind him.
People will hack the AI because it exists. Owners will do so because it will make their car cooler. Others will do it because it is a challenge and they can get their leet haxor creds by causing damage.
But automated cars are controlled by computers that make decisions in fractions of a second! They should absolutely be able to avoid debris falling on the road.
Let's test that hypothesis. You get your AV going down I5 at posted legal speed and I'll drop a rock on it from an overpass. I predict your AV will not avoid "debris falling on the road" when the laws of physics say your AV cannot stop in time to avoid hitting/being hit by it.
If they don't have the sensors for it, then that's a problem.
I have three significant chips in my windshield that came from small rocks being kicked up by trucks in front of me. I challenge you to have a camera with sufficient resolution, and computer with sufficient processing speed, to detect, much less avoid such damage. Then consider that the camera you may have trying to detect this stuff may be the target of that rock, and it becomes not so good for much.