ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a very small number of received emails from the same sender that I am sure were not there a few days ago but dated prior to these few days.
Is this entirely my fault (my imagination) or is it possible for a sender to date an email and send it, for example, a week later?
Or is it possible that my paid email service failed to send those emails for a number of days?
Or is there any possible trick capable of giving that result?
There is nothing wrong with my email account I have with this email service, other emails sent or received do and did work as expected.
Yes to all of the above. It is possible to set a different date on the mail than it was actually sent.
However, there is a perennial problem with m$ products in regards to mail. Stuff that people try to send via or from Outlook / Exchange can get lost -- often -- but even if it does not get lost it can get delayed by days. Either incident is quite common.
Anything(!) about an "SMTP/POP e-mail" can be faked, because there is no "default" content-verification. (Unlike this, for example, "https: website!)
There are various "public standards," such as PGP®/GPG and S/MIME, as well as various commercial vendors. All of these provide "cryptographic wrappers" which properly secure and verify your transmissions, as well as the identity of the people you are talking to. Amazingly enough(!), these have never become "standard" for e-mail ... although GMail briefly offered it but then withdrew it. (Hmmmm....)
"MS-Exchange®" is an entirely-different and entirely-proprietary venue for exchanging "e-mail."
Last edited by sundialsvcs; 11-06-2023 at 08:51 AM.
Nonetheless the various "Received" headers should be examined (it is View+Source or View+Headers in any conventional mail-client (this doesn't include web-mail or Outlook)).
Yes. I suppose the Received: headers could be modified, but not by the originator of the message.
And there’s no reason for a mail server to mess with the Received: headers it adds to the message.
They will show the progress of the message from the originating server to the final server. Watch out for different time zones when checking times on them.
It all comes down to "a matter of trust." In other words, how suspicious are you – and, how suspicious should you be?
For example: in the case of "standard SMTP/POP email," the transfer of the message relies upon a network of so-called "mail transfer agents (MTAs)." Each of which handles your message (in plaintext form), and is supposed to do the right thing. This implies that you trust that each of the MTAs which handled your message "did the right thing." (And that none of them "singled out" your message.) Bear in mind also that every component in the MTA network implicitly "trusts" every other one, to the extent that they forward mail-headers to the next party "as tendered."
Other e-mail transfer protocols do exist, including proprietary ones such as Microsoft Exchange.® Which have an entirely different architecture and use cryptography.
Nonetheless: "if you send a sensitive message using any email," regardless of how it is sent, you(!) should secure its content via suitable cryptography, and you should not trust any "contextual information" such as headers. Nor the behavior or presumed-behavior of any "agent" which handled the message in transit. The only information which you should have any reason to "trust" is what is contained in the encrypted payload.
The original email standard definition did not require encryption, verification, or correctness of fields not required for routing. IT also allowed ONLY plain text payloads. The current standard is not far different, but everyone and their brother ignores the standard anyway. It is a testament to the rapid and widespread adoption of that standard that email as we know it is so pervasive. IT is really a testament to our complacency and stupidity that we have not adopted a more robust and secure standard or service for communication that requires proper and accurate data definitions and time-stamps (and encryption).
It continues to baffle me that I can use "southwest.com" and be certain that I am talking to the airline. But I cannot receive an email "from Southwest Airlines" and be certain that the message really is coming from them.
Briefly, Google's "gmail" service did support email encryption and message signing according to standards. But then, they took it out.
It should be "an entirely routine thing, by now," that every email message would routinely be "digitally signed." Both the S/MIME and the PGP®/GPG standards easily support this, and another standard could easily be invented. Any business's email messages are just as important as their web site.
Last edited by sundialsvcs; 11-18-2023 at 03:36 PM.
It continues to baffle me that I can use "southwest.com" and be certain that I am talking to the airline. But I cannot receive an email "from Southwest Airlines" and be certain that the message really is coming from them.
Briefly, Google's "gmail" service did support email encryption and message signing according to standards. But then, they took it out.
It should be "an entirely routine thing, by now," that every email message would routinely be "digitally signed." Both the S/MIME and the PGP®/GPG standards easily support this, and another standard could easily be invented. Any business's email messages are just as important as their web site.
For some tings I use tutanota.com (or now tuta.com if you go with a subscription plan) for that security. Alas, it really only works securely between totanota/tuta mail users. But between two tuta users all traffic is encrypted by default.
To put it succinctly: the short answer is yes. But emails also have headers that are available for you to look at.
HEader in the mail packets can also be smudged, but someone would have to know 1% more and have a 10% greater desire to muck you up. Also, you may have a mail log (depending on how you get your mail and if you run your own processes) that you can use to extract additional data. Including the Date-time stamp on the processing of that mail. That is something terribly you may not be able to get through a web interface to a remote server easily. OR at all!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.