Your best option would be to use the [Return receipt] or [Delivery status notification] options. The latter will be an automated notification from the mail server stating it accepted or deferred the e-mail.
I had to depart quickly so I had to cut it short. To elaborate further:
The temp offices usually work with day contracts, allowing them to 'fire' you when you get a bad review, they don't need you that day or they don't like you. This provides a very unstable income.
In my case, the company that was hiring me used the temp jobs as a kind of 'trial period' and easily disposable workforce. If somebody did not live up to expectations, that person does not come back, but every day, 50 of those workers were needed. It took me 1.5 year as a temp worker on day contracts to get a permanent contract from the employer. I was a lucky exception.
Looking back on the stress, the uncertainty, the misery and humiliation I had to undergo to keep the most basic job, I would never, ever go back to that industry again.
as an ex-temp worker: that's how it is. You want to work, you have to put up with the stuff they throw at you. No. It's not fair. No. It's not just. It's for the poor. It's for the uneducated. It's for the immigrants. It's for the vulnerable people, because they are easy to exploit. They don't know their own rights.
how about a solar panel on the back (or a transparant one on the front).
How about heat activated.
How about activated by radiation in the air (microwaves).
using certificates is getting advanced. Here you'll allow the server to request a client certificate from the visitor. The visitor will have to supply the certificate (which is 4096b if you take security serious).
It requires quite a bit of steps, but is as secure as it gets what web access is concerned.
You should not be surprised to see 15k+ failed login attempts on ssh with popular ISP's. As I said, a system is the most vulnerable when it has just been installed and a/the default root password has not yet been changed.
Simply disallow password login on ssh, change the port and only allow non-root users you need to allow.
I have on my systems only 1 user allowed to login, authenticated by a 4096b key. There is no way an attacker can use ssh if not using an ssh exploit. The system is updated automatically every hour. This way known exploits are very quickly taken care of.
For me, server security has been a practice over many years and it takes many years to perfect your 'secure server setup'. It's depressing how many companies do not adhere good security practices and just leave their systems unprotected.
Especially mail servers.
There are lots of possibilities.
For example: Only allow web connections through localhost and start an x session through ssh. This would require you to install a webbrowser though, so that's another security risk. Perhaps you could set up a VM with a dedi IP and only allow connections from there. (secure it well)
Another possibility would be to first pass a reverse proxy that will request a client-side certificate. That'd make it pretty secure.
A password protected directory is just asking for a brute force through a botnet. Your failtoban won't even block anything because the attacker would only let 1 host attempt a password once per 30 min or per hour. But if he has thousands of bots to his disposal, he can still bruteforce a couple times a second.
That's OK you say. I have a strong password. Don't forget: Each connection and failed login attempts is logged. Your logfile will quickly grow. If you did not set a seperate VAR partition on your disk, your root disk will quickly get full and server will crash. Additionally, it will fill up your bandwith and be as effective as a ddos attack.
Don't use passwords. Use certificates. easier for you, impossible to hack.
There are other methods of course, but these would be my preferred methods. Setting phpmyadmin publically is asking to get your data stolen. Do not assume there are not exploits in the latest phpmyadmin. But don't forget to update it within the first 10 minutes when a security patch comes along, otherwise your data may well already be compromised.
rkhunter does fim in a limited way. I hope OP is not talking about sites with sensitive data.
ossec is usually great for storing more sensitive data.
The above list will help you from most scriptkiddy attacks, which are 99% of the attacks I have experienced. It's a good idea not to piss off anybody on the net or do it with a sufficiently obscure account.
if you wanna go there. I use a custom script to make backups, encrypt them using gpg and store them on public ftp boxes.
Automated retrieval of said backup in case of problems and automated server recovery in case of disaster.
I don't use debian because I don't like apt.
The most vulnerable moment of my systems is when the ISP sends the password in plain text over e-mail. Until the password has been changed and the system has been sanitized(), I consider it compromised.