Version 1.27.0
Released: 2006-05-10
CMD_API_EMAIL_FILTER new
API version of CMD_EMAIL_FILTER
All are GET or POST
List Filters and settings:
CMD_API_EMAIL_FILTER?domain=domain.com
Dumps the contents of /etc/virtual/domain.com/filter.conf
Add a filter:
domain=domain.com
action=add
type=email|domain|word|size
value=the value to filter
Flip adult filter on/off:
domain=domain.com
action=adult
Delete a filter:
domain=domain.com
action=delete
select0=1 #(the filter id from the filter.conf)
(select1=5, etc..)
Ability to disable reseller backup bandwidth new
Related here: https://forum.directadmin.com/showthread.php?t=11617
Add an option in the directadmin.conf to disable bandwidth logged done be the user backup transfers.
name is:
reseller_backup_bandwidth=1
the default is set to 1.
If it's changed to 0, the bandwidth from the Reseller level backups are not logged.
This does not affect the downloading of user backups to DA.
Bringing backups to the server via ftp will be logged.
Note: this also include Admin Level -> Admin Backup/Transfers, since it too uses the same ftp functions.
option to disable quota counting for pop accounts page new
When you get to have several thousand email accounts, the loading of the "pop accounts" page may start to slow down.
You can speed it back up by setting:
count_pop_usage=0
in your directadmin.conf
The default is 1 (with no entry).
email disk usage cache to speed up the pop page new
implement a pop email disk usage caching option (disabled by default) such that the pop emails page can have several thousand or more emails, and the disk usage calculations won't slow things down.
To enable this feature, add the following to your directadmin.conf.
pop_disk_usage_cache=1
Once added, restart DA.
Initially, no cache files will exist. A user will view his pop page, all pop accounts disk usage will show 0. DA will notice there is no cache file (/etc/virtual/domain.com/usage.cache) and add it's creation to the task.queue to be created within one minute. If the usage.cache does exist but is more than 10 minutes old, again, DA will issue an update to this file to the task.queue to be updated within one minute.
There are other means to update the usage.cache files on a regular basis. This can be done by creating cron jobs. The 2 commands you can use are:
echo "action=cache&type=popquota" >> /usr/local/directadmin/data/task.queue
echo "action=cache&type=popquota&value=domain.com" >> /usr/local/directadmin/data/task.queue
Without the "value=domain.com", all domains will be updated.
With value=domain.com, only that domain is updated.
You can add it to the /etc/cron.d/directadmin_cron (or /etc/crontab on freebsd) by adding the line:
*/15 * * * * root echo "action=cache&type=popquota" >> /usr/local/directadmin/data/task.queue
to the respective file, then restart crond. This will update everyones pop disk usage cache every 15 minutes.
Note that the cronjobs are not required due to the intelligent way DA checks the usage.cache file, but I would still recommend adding some sort of update interval (at least daily) so that your users are not confused why their pop account stats are 0 for 1 minute, then full the next (due to the task.queue cron delay)
The current known upper limit is roughly 32,000 emails. The only restriction is the file system limit on the number of directories it can have in once place. If you were to increase this limit and recompile your kernel you can greatly increase the number of potential email accounts per domain to a very high number.
CMD_API_POP - per account quotas && CMD_EMAIL_ACCOUNT_QUOTA new
adding a per-account quota report. Uses would be in things like squirrelmail so that the users can see their own usage.
CMD_API_POP
method: GET or POST
type=quota
domain=domain.com
user=bob (eg for bob@domain.com)
This will not use the new pop usage cache (feature in this release). Since only 1 user is being counted, there is no harm in doing a live tally of the 1 pop user.
================
CMD_EMAIL_ACCOUNT_QUOTA
Works for both system accounts, and virtual pop accounts.
Option to use login/password values as the email / email password, so that the DA login/pass is not required.
Similar to CMD_CHANGE_EMAIL_PASSWORD where it's accessible by email users without a da login/password.
GET or POST
domain=domain.com
user=bob
password=hispassword
You can pass "api=1" as well to get an API result (with error=1 or error=0).
If api, the output is something like (in bytes):
error=0&imap=6904871&inbox=288714&spam=6881&total=11807743&webmail=4614158
If not api:
imap=6904871
inbox=288714
spam=6881
total=11807743
webmail=4614158
It's separated with
characters. Note that api=0 is not valid. DA will assume you want the api output even if you have api=0. (api=anything means api in this case)
These values are also not taken from the cache, their computed in realtime.
move the spambox creation to the task.queue new
when you make change in your spamassassin settings, each time you click "Save" DA will recreate/set the ownership/permissions on each spambox file.
If you have a large number of pop accounts, this can take long enough that the timeout is reached. Moving this task to the task.queue file to be run in the background will allow things to run quicker in the foreground in DA.
task.queue command:
action=defaultspam&domain=domain.com&username=user
exim filter base template new
A base template for adding global items for any of the 4 spam redirection options.
(currently there is no template for the "let it go to the inbox" option, so no filters can be set in that case).
/usr/local/directadmin/data/templates/filter_base
This file is required (added by DA)
the standard templates/custom/* trick works as well.
restore old domain.com.db file with restore (SKINS) new
Restores previously created a new dns zone during a user restore.
This requires the old IP from the user.conf to be checked and swapped with the new IP being used for the user.
The process can't handle all cases, ie: IPs that are not the old IP, so manual changing is needed if there are any other IPs in the file.
There will be no option to do the backup of the db file, as it 's always backed up.
The only option is during the restore, to restore it or not.
Reseller level restore, it it always enabled.
The restore only copies over the A records and the MX records.
The A records are scanned for the old IP, if it exists, the new IP is entered.
A records with an IP that differs from the Users old IP will not be touched, and copied as is.
MX records are all copied no questions asked.
CNAME records are copied no questions asked.
PTR, NS and TXT records are not copied at all. They should be set locally already.
SKINS:
user/site_restore.html
add:
<tr><td class=list colspan=2><b>DNS</b></td></tr>
<tr><td class=list>DNS Zones: Includes all A records and MX records</td><td class=list><input type=checkbox name=select11 value="dns" |DNSON|></td></tr>
Bandwidth Details from the bandwidth.tally file (SKINS) new
A detailed report in a simple table showing the bandwidth breakdown from the bandwidth. Allows Users to track where their bandwidth is going.
Table has columns for apache, email, ftp, DA, and "other" (if unknown in bandwidth.tally), with a "total" column as well for that day.
Each row consists of the bandwidth for that day, starting with the date in 'y m d' format, eg "2006 05 08".
The last row of the table is a total for each column with the grand total for everything at the bottom right (should match what DA shows on the stats page).
There is a related API command:
CMD_API_BANDWIDTH_BREAKDOWN
A user can call this as is with no parameters and get a dump of the data.
If the "user=bob" is passed (GET or POST), a reseller or admin can view the bandwidth details for any of their users. There is one value in the returned data called "simpletotal". This is more of a parity check for debugging.. it should match exactly the "total=total=1234" value (simpletotal=1234). simpletotal adds every single bandwidth.tally entry, whereas the grand total value is calculated by adding bits and pieces from all over the bandwidth.tally file.
SKINS:
added
CMD_BANDWIDTH_BREAKDOWN=user/bandwidth_breakdown.html
to the files_user.conf.
Also created the user/bandwidth_breakdown.html file with a token called "TABLE" to handle the table.
change domain needs to update pop passwd contents with dovecot fixed
the /etc/virtual/domain.com/passwd file contains the path to the email acounts.
This path is not being updated when the domain name is being changed preventing pop login after a domain name change when dovecot is enabled.
Workaround after the domain name is changed:
cd /etc/virtual/newdomain.com
perl -pi -e 's/olddomain.com/newdomain.com/' passwd