Version 1.29.1
Released: 2007-02-25
CMD_API_SPAMASSASSIN new
CMD_API_SPAMASSASSIN
There are 3 main actions:
action=save
action=disable
no action at all
all 3 require a valid domain=domain.com
action=disable will do just that.
action=save has many values to pass.
Please see the html forms for information on what should be passed to the POST.
When viewed with no action, all tokens will be dumped.
Sample output:
high%5Fscore=%31%35&high%5Fscore%5Fblock=no&is%5Fon=yes&report%5Fsafe=%31&required%5Fhits=%35%2E%30&required%5Fscore=%35%2E%30&rewrite%5Fheader=subject%20%2A%2A%2A%2A%2ASPAM%2A%2A%2A%2A%2A&rewrite%5Fsubject=%30&subject%5Ftag=%2A%2A%2A%2A%2ASPAM%2A%2A%2A%2A%2A&where=userspamfolder
Actual values:
blacklist_from0 = *@*.ru
blacklist_from1 = no@thanks.com
etc..
score at which we delete the spam, no questions asked.
always an integer, no decimals.
high_score = 5
high_score_block = yes
is spamassassin even running?
is_on = yes
report_safe = 0|1|2
0: Don't use attachments (dangerous).
1: Use attachments.
2: Use text-only attachments.
Score at which spam is called spam.
required_hits = 2.3
Note that the following options vary based on the version of SA you're using (should be able to support 2.x and 3.x)
If you're using 2.x, you will get the rewrite_subject=1|0 .. but if you've go 3.x (like most servers) if rewrite_subject=0, then no rewrite_header will be present.
The rewrite_subeject should always be present in the API output (even though it's only for SA 2.x). If you have 2.x, rewrite_header will never show up. If you have 3.x and rewrite is turned on, rewrite_header will be present. If rewrite is off, you won't be able to determine which version of SA you have, but if rewrite_subject=0 and rewrite_header isn't present, then you'll know the subject rewrite is turned off anyway. You can most likely asssume that you're dealing with SA 3.x anyway as all new systems will have 3.x, only really old system will use 2.x.
rewrite_subject = 1|0 (for SA 2.x only)
subject_tag = *****SPAM***** (for SA 2.x only)
rewrite_header = subject *****SPAM***** (for SA 3.x only)
how should the spam be redirected
where = inbox|spamfolder|userspamfolder|delete
same as blacklist, except white.
whitelist_from0 = bob@somewhere.com
whitelist_from1 = fred@elsewhere.net
stat temp files during config file writing to ensure the disk isn't full new
Each time a config file is written, it's first written to a temp file, then moved overtop of the orignal. This is prevent a wiping the original if the disk is full. DirectAdmin currently counts the number of bytes written as returned by the "fwrite" function, but this isn't reliable due to system cacheing.
The more reliable method is to check the size of the temp file after fclose is called as the file should be flushed and fully on disk by then.
Lost password feature (SKINS) new
Option to allow a user to solve his own problems if he's lost his DirectAdmin password. The default is "off", but when enabled, a link will appear on the login page for "Lost Password?". DirectAdmin will email them a link to click with a confirmation code. That code will be send to DA when the link is clicked, which will send them a new random password to the same email address. There is also a "report false requests" link in the initial code email. If the user didn't initiate this request, he can click the "report" link an all admins will be notified of the false attempt, including the IP of the original initiator.
Password change requests expire after 2 hours with no confirmation, so the user must click it fairly quickly after initiating.
The default is OFF so you must turn this feature on if you want it.
Admin Level -> Admin Settings -> Enable Automatic Lost Password Recovery = Yes
If you use a custom data/templates/login.html add:
|*if LOST_PASSWORD="yes"|
<a href="/CMD_LOST_PASSWORD">Forgot your password?</a>
|*endif|
added 2 templates:
data/templates/lost_password_email.txt
data/templates/lost_password.html
The "code" file is stored in:
/usr/local/directadmin/data/admin/lost_password_request.txt
changes also made to:
admin/admin_settings.html
for the new option to turn this feature on/off.
You can use the API if you wish.. but there isn't much use for it.
Simply include "api=yes" with all your GET/POST requets and the output is parseable.
SKINS:
for enhanced skins:
<tr>
<td class=list>
|LANG_LOST_PASSWORD_RECOVERY|
</td>
<td class=list>
<input type=radio name=lost_password value="yes" |LOST_PW_YES|>|LANG_YES| <input type=radio name=lost_password value="no" |LOST_PW_NO|>|LANG_NO|
</td>
</tr>
with the additions of:
LANG_LOST_PASSWORD_RECOVERY=Enable Automatic Lost Password Recovery
LANG_YES=Yes
LANG_NO=No
in the admin_settigs.html lang file.
For regular skins, the admin_settings.html will have the additional:
<tr>
<td class=list>
Enable Automatic Lost Password Recovery
</td>
<td class=list>
<input type=radio name=lost_password value="yes" |LOST_PW_YES|>Yes <input type=radio name=lost_password value="no" |LOST_PW_NO|>No
</td>
</tr>
Right after the "demo document root" option.
add token to replace /squirrelmail with a variable (SKINS) new
ability to set whichever webmail program you wish to have.
webmail_link=squirrelmail
will be the default, but can be changed by adding webmail_link=other to the directadmin.conf file.
Token will be set to |WEBMAIL_LINK|
The webmail link only applies to the enhanced skin:
SKINS:
header_bar.html
header_wide.html
replace "squirrelmail" with "|WEBMAIL_LINK|"
Also add option to directadmin.conf to hide the 2 webmail links on the User/Email page. (webmail button is not affected)
hide_webmail_links=1
in the directadimin.conf, default is 0.
Token added
HIDE_WEBMAIL_LINKS=yes
or
HIDE_WEBMAIL_LINKS=no
SKINS:
user/show_domain.html (enhanced)
or
user/email/email.html (default and power_user)
eg:
|*if HIDE_WEBMAIL_LINKS!="yes"|
show the urls /squirrelmail /webmail
|*endif|
The enhanced skin is more complicated due to the check for a 0 email limit as well in combination with the fact that the if statments only support single booleans.
Here is the solution by creating a variable called SHOW_LINKS that default to yes:
|?SHOW_LINKS=yes|
|*if USEREMAILMAX!="0"|
show spam filters link.
|*else|
|?SHOW_LINKS=no|
|*endif|
|*if HIDE_WEBMAIL_LINKS="yes"|
|?SHOW_LINKS=no|
|*endif|
|*if SHOW_LINKS="yes"|
<a href="|HTTP|://|HOSTNAME|/squirrelmail" target="_blank">|LANG_WEBMAIL_SM|</a><br>
<a href="|HTTP|://|HOSTNAME|/webmail" target="_blank">|LANG_WEBMAIL_UEBI|</a><br>
|*endif|
CMD_API_USER_PASSWD new
CMD_API_USER_PASSWD
same as CMD_USER_PASSWD, but for the API
Can be called by Admin's or Reseller's.
Method: POST
username=bob
passwd=pass
passwd2=pass
CMD_API_FILE_MANAGER for uploading files without multipart form data new
Some upload languages dont have the ability to formulate the multipart form data POST format. This feature allows variables to be passed with GET and the file itself passed with POST.
eg:
/CMD_API_FILE_MANAGER?path=/upload/dir&action=upload
httpd headers:
X-DirectAdmin-File-Upload: yes
X-DirectAdmin-File-Name: readme.txt
don't forget the usual authentication data "Basic" and the Content-Length of the data.
add safemode/openbasedir to restore options in Admin Backup/Transfer new
add safemode/openbasedir to restore options in Admin Backup/Transfer.
Because they are admin only settings, they would only be able to be restored by an Admin.
The Reseller level backup, or User Site Restore would not have the ability to turn them off if needed.
The data is already saved into the backups, it's just not currently being looked at at restore time, which will be fixed once this item is implemented.
Admin Level Backup: "Invalid local path" fixed
Restore generates:
Error during Restore
Details
Invalid local path:
Caused by missing token |where| (was added as |WHERE| by mistake)
and missing form item:
<input type=hidden name=local_path value="|local_path|">
mbox to dovecot convert during user.tar.gz restore had wrong permissions fixed
The check for the existence of the next pop mbox file was failing because the permissions were dropped after the first pop inbox was converted.
This fix escalates them back up again so that the process can see, and work with the inbox.
wrong default email message for owned IPs fixed
When an owned IP account is created, it will send you this sentence:
Use |ip|/~|username| to access it until the domain resolves.
which isn't correct, as ~username isn't needed for owned IPs (nor does it even work). Just |ip| is all you need.
Fix is to add a new token called |OWNED| that will be yes or no, if the IP is owned.
The new message will be formatted like this:
Use |ip||*if OWNED!="yes"|/~|username||*endif| to access it until the domain resolves.
If you want this change an had an existing default message, you will need to update it to insert the special token if-statement.
limit on number of word spam filters fixed
can't add more spam word filters after a certain limit (duplicated, will investigate more). Upon further investigation, the issue didn't repeate itself. Was able to add 26 random blocks. If anyone is experiencing this issue, please send us more information.
user not removed from backup crons when deleted fixed
Remove the user from the list of backup crons at the reseller and admin level backups when he's deleted.
CMD_API_SITE_BACKUP action=restore returns no result fixed
When using the action=restore option for CMD_API_SITE_BACKUP, the defaut browser action was being used, which is to not give any text output, and only return a "Location:" header in the browser. The fix is to API-ize the return values for success and fail. Succecs was a regular template meaning it would be a pile of html with the text instead of a url encoded result.
HTTP/1.1 401 Unauthorized changed to HTTP/1.1 200 OK for login form fixed
The http return value for the login page was:
HTTP/1.1 401 Unauthorized
Which works fine for most browsers, but is actually incorrect as it would imply the server wants a httpd-auth authentication passed. Most browsers ignored this header and show the data anyway. Other browsers like cellphone (nokia's for example) do take it seriously, show a login popup and ignore the data.
Changing to:
HTTP/1.1 200 OK
should solve that, as most regular browsers really don't care anwyay.
Maildir for system account chgrp to user instead of mail after restore fixed
When a user account using Maildir is restored, the /home/user/Maildir folder has the group ownership of the user. This should be "mail". Virtual accounts are not affected and have the correct ownership after a restore.
Workaround until fix is released:
cd /usr/local/directadmin/scripts
./set_permissions.sh email
creator in user.conf not correct when restoring with Admin Level fixed
When restoring an account using the Admin Level -> Admin Backup/Transfer tool, the creator value in the user.conf will be set to the admin doing the restore instead of the reseller/admin name that is stored in the filename.