Delete Logs - Emails Sent To Clients

[wfitg]

We need a way to clear the logs.

 

In paticular, the email log that can be viewed for each client.

 

 

 

  

[Michael]

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. 

[wfitg]

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.

[Michael]

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.

 

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]

[Blesta Addons]

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.

 

 

Good found , that should be encrypted or removed when loged to database .

[wfitg]

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.

[wfitg]

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.

[Michael]

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.

 

I'll +1 that password shouldn't be included by default however you can add it in if you wish. As for the email rotate I'm going to -1 that since a customer will probably go well you didn't email me that before... Yes we did!

[Blesta Addons]

I'll +1 that password shouldn't be included by default however you can add it in if you wish. As for the email rotate I'm going to -1 that since a customer will probably go well you didn't email me that before... Yes we did!

 

one day , when you have more clients, more services activated , you will revert the -1 to +1 .

[Michael]

one day , when you have more clients, more services activated , you will revert the -1 to +1 .

 

Nope I'll just expand the server space. I'm not a host and if you have more customers you'll be able to afford a little bit more to expand the diskspace.

[Blesta Addons]

that hs no relation to space , but to mysql imorouvement . a databse of 100MB is not a database with 1GB .

 

for me i will have internal plugin to do this task .

 

saving email copy that have 1 years or more have no sense for me . but is highly should be for emails in the last 6/12 mounths .

[Michael]

that hs no relation to space , but to mysql imorouvement . a databse of 100MB is not a database with 1GB .

 

for me i will have internal plugin to do this task .

 

saving email copy that have 1 years or more have no sense for me . but is highly should be for emails in the last 6/12 mounths .

A bigger database doesn't slow down anything though so not much of an improvement.

[Blesta Addons]

A bigger database doesn't slow down anything

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 ?

[wfitg]

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.

[wfitg]

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> ?

[flangefrog]

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.

[wfitg]

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.

[Paul]

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.

[Blesta Addons]

Hello Paul ,

 

the Account Registration email could not have a pssword , but what about the service email creation ? normmaly it has the pasword and we can't ignore it , on service creation nthe client recieve email about thier login password . that is my concern not the welcome email .

 

truncate log emails is a good option to enable/disable . i will delete just email that has more than 18 mounths .

[PauloV]

A bigger database doesn't slow down anything though so not much of an improvement.

 

 

If you have many as mySQL records as we have you will cry

 

I can tell you that we have optimised my.cnf to get some decent tme results, we got some big values in MySQL Cache and Buffering, for exemple 16GB (yes GibaBytes not Bites lol) and we have a server with 32GB to handle the MySQL data.

 

The best option you have to get decent time results wen MySQL database gets bigger is clustering and caching, and ofcourse cleaning logs

 

In EU we have to retain logs for at least 9 months, after that we can leagally delet logs. You can ofcouser make a Backup and then clean logs

[wfitg]

I like the clustering and the truncating ideas. However, I think I will first try a seperate database to store email.

[wfitg]

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 see the need for some businesses to keep emails on file. In some cases it is a legal requirement.

I like the idea of having the option to truncate.

[will]

We ran in to this problem and were confused for a couple days when we removed the password from the template but it kept showing up in the logs, despite it not appearing in the test emails we sent. It turns out there are two templates - one HTML, one text, and only the text template is saved in the logs. Perhaps something could be done to make this more obvious?

[Michael]

We ran in to this problem and were confused for a couple days when we removed the password from the template but it kept showing up in the logs, despite it not appearing in the test emails we sent. It turns out there are two templates - one HTML, one text, and only the text template is saved in the logs. Perhaps something could be done to make this more obvious?

 

Did you remove the {password} from the text template side. That's what is in the logs. The html is normally sent to the customer.

 

PS: Woops re-read it and you found it  There's two tabs for everything.

[Paul]

 The html is normally sent to the customer.

 

Both are sent in the email, the HTML *and* text versions. If the customers email client can display HTML, then it uses the HTML version. If it doesn't support HTML, then it uses the text version. Both should always be updated when editing an email template.