wfitg
-
Posts
205 -
Joined
-
Last visited
-
Days Won
2
Posts posted by wfitg
-
-
How can I remobe the "Reset My Password" link on the staff login box?
-
That was funny!
-
I see the need for some businesses to keep emails on file. In some cases it is a legal requirement.I have created task CORE-1453 to address passwords in the Account Registration email. We personally do not include passwords in our account registration email. It's generally a bad idea to do this, and it should not be included by default. This will affect new installations only.
The separate issue about rotating the email log is open to further discussion. Personally, we prefer to keep an entire history of email with the customer. I personally check email logs often, especially if there is a dispute. But, we understand that the log could become quite large, so an option to truncate the log which is not enabled by default may be a good option.
I like the idea of having the option to truncate.
-
I like the clustering and the truncating ideas. However, I think I will first try a seperate database to store email.
-
Yeah it's possible to encrypt it, passwords should never be there in the first place though. There are built in ways in MySQL to compress the data, that might be a good idea although depending which method is used it could prevent full text search.
I have not found a way to encrypt only the emails. There is a way to encrypt specific lines of an database.
Why couldn't these emails be forked to a seperate "email database"? This way there would be no need to archive them. They could be kept on file forever.
-
are you sure ?
from my x-large years in administration is slow donw . and slow down more if you have more active users .
finnaly let the database subject as is not OP subject .
are logical for you saving welcome email for the last 2/3 last years ?
Saving the welcome email is good. Saving the welcome email with the password in plain text is not good. The welcome email should not include the variable {password} by default. It is too easy to overlook when doing the initial Blesta setup.
IMHO - It would be better to archive any emails older than 6 months or a year rather then have the database grow huge.
100 clients getting an average of 2 emails or more per month is 2400 or more emails in the database over the course of 1 year. The emails are stored in plain text. That personal information could be a gold mind if the database got hacked.
Time for some individual encryption, But, can only the mail be encrypted in the DB without having to encrypt the entire sql> ?
-
I certainly see the need to keep emails on file for 6 months or even a year. And you make a good point.
Personally, I would rather have the ability to archive them, or delete them after so many months.
-
So how is the new version? Anyone care to share likes and dislikes?
-
Good found , that should be encrypted or removed when loged to database .
Exactly. I went in and removed the pass from each of the emails. But if the emails do not rotate the database could get huge. We need a way to archive them or delete them.
The variable {password} should not be included in the welcome email by default. It should be an option that comes with a warning, or not available at all. I don't know anyone that sends the user name and pass in plain text email these days.
-
Yeah you'll have to remove it from the database, we always recommend users to change that when they've installed Blesta to something like
****** [Hidden for security]
My suggestion is having a delete button next to the email when we "view client email". Otherwise the log could get huge.
-
Not sure but I believe you need to keep records of all emails sent to customers. All other logs are deleted every month if set to rotate in the settings.
I found the rotation settings.
Here is my concern:
The "Welcome Email" sends the user name and password by default. {username} {password} variables.
I have changed that to say
password: "the password you used when signing up"
However, the old email with the user's name and password is being stored in the database in plain text. There is no way to delete it without manually changing the database.
-
We need a way to clear the logs.
In paticular, the email log that can be viewed for each client.
-
I have spaced out the time intervals under settings/automation. I had several settings running every 5 minuets.
I noticed there was a spike at around 3pm. This is when the load was the heaviest.
Deliver Reports
A/R, Invoice Generation, Tax Liability, and other reports will be delivered daily at the time specified.I set this to run overnight instead of 3pm.
Hopefully changing the settings for each task will reduce the memory being used
-
what about the time ?
if this procces in not taking a long time so is normal .
*LOAD* 5 minute load average is 7.65
-
for me is normal . you must increase the memory limit in CSF to 350 or 400Mb .
normal just for cronjob , if you have small database with small services/clients/ then this shouldbe some more invistigation .
Small database.
What to look for?
-
First the data:
LFD.log
I have a couple dozen of these in the lfd.log:
Kill:0 User:wfitg VM:285(MB) EXE:/home/virtfs/wfitg/usr/bin/php /home/wfitg/public_html/backend/index.php cron
And emails from lfd:
Resource: Virtual Memory Size
Exceeded: 285 > 200 (MB)
Executable: /home/virtfs/wfitg/usr/bin/php
Command Line: /usr/bin/php /home/wfitg/public_html/backend/index.php cron
PID: 28803 (Parent PID:28802)
Questions:
Is this memory use normal?
Could the warning threshold be too low?
Could this be brute force?
Is anyone else having high mem use + cron?
-
httpd.conf "includes" are the way to go. A good way to DENY iframes too
-
I don't think HSTS should be enabled by default. It's great and I use it myself but it's not something you can just disable if you don't want it.
If i understand the OP correctly, this could be used.
ini_set( 'session.cookie_httponly', 1 );
But it can be done using htaccess too
<IfModule php5_module>
php_value session.cookie_httponly true
</IfModule>
more
http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php
-
The thing is this wannabe hacker forgot if someone decoded it he's domain would be there, which then linked to the stupid tweet we know about and then linked to a visible who.is, and a team page which we could google their name...
Yeah, he is busted. What an idiot.
We have too many experienced webmasters, coders, and admins here for a scrpit kiddie to get away with much. An experienced spammer/hacker would not bother with such nonsense as this. They just want to send their spam.
It looks like a deliberate attempt to make the Blesta company look bad.
---------------------
here is an SPF generator if anyone needs it
Microsoft makes one too:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
-
It's per domain so every user can have their own one. If they use it and use a dedicated IP they can set a SPF record to accept emails from both eg:
v=spf1 a mx ptr ip4:216.220.167.249 mx:mail.licensecart.com ip4:216.220.167.248 -all
thats ours.The -all will reject everything that does not pass. I like to use ~all because I can still get the flagged email. I simply setup a rule to have those flagged emails go to thje flagged folder. Then I can scan through them for any mistaken failures (or someone who simply does not have the records set correctly) and also remember those that are frequent abusers. The frequent ones can be can be blocked on ACL or IP Tables.
I guess whatever works is the answer as long as something is in place to prevent domain spoofing. This will stop many of the script kiddies and wannabe hackers, but a determined spammer will try other methods than spoofing to hijack an email server.
-
DMARC is good for this you get a copy which failed sent to you.
This makes it a great solution.
-
Yeah I think however that only works for fake @domain.com not domain.com@gmail.com we have: DMARC which again like SPF works at ensuring the IP is correct of the sender.
v=DMARC1; p=quarantine; pct=50; adkim=strict;
but it quarantines fakes, but only 50% of it (This is to ensure real emails don't get effected whilst the inboxes are learning).
This looks great.
I may start using DMARK too. However, if the person is on a shared server, but they have a dedicated IP for an SSL this could cause a problem. Their mail is comes from the shared servers's IP address, notfrom their dedicated IP. They will have to add an A record with the shared mail server's IP. Not many users know how to add DNS records so their mail will be bounced.
-
Yeah I think however that only works for fake @domain.com not domain.com@gmail.com
Correct. Nothing can stop someone from using domain.com@gmail.com --except for being observant.
I know it does work if someone is trying to spoof the actual domain name. For example, the mail server would bounce an email from sales@blesta.com if: (1)the blesta zone file has an SPF record set and (2)the email is not originating from blesta's email server.
Of course, nothing in life is 100% but I can say that using this has cut down on my domain being spoofed and on the amount of spoofed emails that I receive.
If I had a complany like Blesta I would probaby use the "soft fail" [ "v=spf1 ~all" ] flag so I could still get the email but also be alerted that it may not be coming from the correct server.
The hard fail option is good for invividuals who do not want to get any spoofed mail at all.
-
Here is a good write up on setting DNS SPF record to prevent your domain name from being spoofed; It also stops spoofed email from coming to your box if the "hard fail" element is used.
Most cPanels create SFP with the hard fail. "v=spf1 -all"
But it is better to use the the soft fail. This way you get the spoofed email, but it is tagged as suspicious: "v=spf1 ~all"
Reset Password
in Support
Posted
thanks