[qmailadmin] allow aliases creation from non-postmaster accounts
Is there a way to get qmailadmin create alias accounts from normal users? My idea is that when our users are about to subscribe to some list, they create a quick throwaway alias so that if said list starts spamming the alias can be simply dropped. Thanks, Wallace
[qmailadmin] Invalid Login
Hi All I have installed qmailadmin-1.0.6 on RedHat Linux 9. When I try to login using Postmaster I get Invalid Login message in the browser screen. Can anybody guide me, as I have compiled and reinstalled vpopmail-5.2.2 and qmailadmin but with no luck. Can anybody guide me ... SOS If this query has been tackled earlier please guide me to the link ... I am sorry I am new over here. Regards Joel
Re: [qmailadmin] Invalid Login
On Jan 9, 2004, at 4:21 AM, Joel A Divekar wrote: I have installed qmailadmin-1.0.6 on RedHat Linux 9. When I try to login using Postmaster I get Invalid Login message in the browser screen. Can anybody guide me, as I have compiled and reinstalled vpopmail-5.2.2 and qmailadmin but with no luck. Can anybody guide me ... SOS If this query has been tackled earlier please guide me to the link ... I am sorry I am new over here. One way to test, is to run the vuserinfo program from the command line: ~vpopmail/bin/vuserinfo [EMAIL PROTECTED] See what password it reports, and then try to log in with it. I think that with RH9, you need to disable a cron job that screws up the users/assign file. Can someone who knows what I'm talking about post more info on this, so we can add it to the INSTALL document for vpopmail? -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [qmailadmin] Stupid C questions
On Jan 8, 2004, at 6:56 PM, Rick Widmer wrote:
1. Does switch/case work with strings?
No. Only with byte/int/long/word datatypes.
It might be possible to build some sort of table of the commands and
the functions to call:
typedef struct {
char*command,
void (*function)(),
} functableentry;
const functableentry functable[] = {
{ showusers, show_users },
{ showaliases, show_aliases }
}
notfound = 1;
for (i = 0; notfound i (sizeof(functable) / sizeof(functable[0]));
i++) {
if (strcmp (functable[i].command, command) == 0) {
notfound = 0;
functable[i].function();
}
}
if (notfound) {
printf (invalid command: %s\n, command);
}
Note that with this system, you need to come up with a standard
function call (identical parameters and return value) to use for each
function in the table. Something like this could really clean up
command.c.
2. How much trouble is it to add or remove .c source files? Say all
the code in alias.c is obsolete except for a function or two and I
want to move those functions to a different file and remove it.
Not much trouble at all. We can just add or remove it from CVS and
Makefile.am.
--
Tom Collins - [EMAIL PROTECTED]
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
[qmailadmin] unicode domain names in vpopmail and qmailadmin
On Jan 7, 2004, at 4:33 PM, Philipp Wagner wrote: Hi, today I thought about the new domain names with some country specific chars (IDN-Domains), like they are offered for com/net/org already and for some European domains (de etc.) from March 1st on. Is it right, that if I want to login into qmailadmin, that I would have to enter the punycode-encoded domain name? That is bad for customers, because they normally don't remember their punycode-domainname, but only their domain name with the special characters. For example, the domain schülerzeitung.net would be xn--schlerzeitung-yob.net Is it possible to integrate that conversion into qmailadmin like the webbrowser does it? On Jan 9, 2004, at 2:11 AM, huleboer wrote: From 18 feb if I remember correctly norwegian characters like øæå will be allowed to use on the internet. This included characters like øæå. Full list is available from http://www.norid.no/domeneregistrering/idn/idn_nyetegn.html. If I try to do a: ./vadddomain tyttebær.no I get Error: Invalid domain name Get the same problem with vaddaliasdomain. I don't know if this is a qmail issue or vpopmail issue. But any1 have a fix? Is this a problem just with vadddomain/vaddaliasdomain or will it require more changes inn qmail/vpopmail? It's obvious that this is going to be a significant issue for vpopmail and qmailadmin. On the backend, we'll be storing everything in 7-bit ASCII (xn--schlerzeitung-yob.net in the example given above), but allow for users to enter unicode names into the command-line programs for vpopmail, and display the properly formatted name in qmailadmin. Can someone with a more detailed knowledge of these systems point the developers to a concise description of how to add support for it to vpopmail and qmailadmin? Perhaps the relevant RFCs? Code libraries that we could simply integrate into our programs? This looks like a good summary: http://www.dns.pl/IDN/idn_intro_eng.html. It will take some time to go through the source and identify times when we need to output the unicode-formatted string (onscreen to the user, in error messages, etc.), versus the 7-bit ASCII version (when writing files). I also don't know if knowledge of the current character set (for example, when a user runs the command-line tools or qmailadmin outputs HTML pages) will be important or not. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
[qmailadmin] RE: [vchkpw] unicode domain names in vpopmail and qmailadmin
For Norway they're using the following RFC's for ACE converting: RFC 3490 ftp://ftp.ntnu.no/pub/rfc/rfc3490.txt RFC 3491 ftp://ftp.ntnu.no/pub/rfc/rfc3491.txt RFC 3492 ftp://ftp.ntnu.no/pub/rfc/rfc3492.txt -Original Message- From: Tom Collins [mailto:[EMAIL PROTECTED] Sent: 9. januar 2004 18:49 To: vpopmail list; [EMAIL PROTECTED] Subject: [vchkpw] unicode domain names in vpopmail and qmailadmin On Jan 7, 2004, at 4:33 PM, Philipp Wagner wrote: Hi, today I thought about the new domain names with some country specific chars (IDN-Domains), like they are offered for com/net/org already and for some European domains (de etc.) from March 1st on. Is it right, that if I want to login into qmailadmin, that I would have to enter the punycode-encoded domain name? That is bad for customers, because they normally don't remember their punycode-domainname, but only their domain name with the special characters. For example, the domain schülerzeitung.net would be xn--schlerzeitung-yob.net Is it possible to integrate that conversion into qmailadmin like the webbrowser does it? On Jan 9, 2004, at 2:11 AM, huleboer wrote: From 18 feb if I remember correctly norwegian characters like øæå will be allowed to use on the internet. This included characters like øæå. Full list is available from http://www.norid.no/domeneregistrering/idn/idn_nyetegn.html. If I try to do a: ./vadddomain tyttebær.no I get Error: Invalid domain name Get the same problem with vaddaliasdomain. I don't know if this is a qmail issue or vpopmail issue. But any1 have a fix? Is this a problem just with vadddomain/vaddaliasdomain or will it require more changes inn qmail/vpopmail? It's obvious that this is going to be a significant issue for vpopmail and qmailadmin. On the backend, we'll be storing everything in 7-bit ASCII (xn--schlerzeitung-yob.net in the example given above), but allow for users to enter unicode names into the command-line programs for vpopmail, and display the properly formatted name in qmailadmin. Can someone with a more detailed knowledge of these systems point the developers to a concise description of how to add support for it to vpopmail and qmailadmin? Perhaps the relevant RFCs? Code libraries that we could simply integrate into our programs? This looks like a good summary: http://www.dns.pl/IDN/idn_intro_eng.html. It will take some time to go through the source and identify times when we need to output the unicode-formatted string (onscreen to the user, in error messages, etc.), versus the 7-bit ASCII version (when writing files). I also don't know if knowledge of the current character set (for example, when a user runs the command-line tools or qmailadmin outputs HTML pages) will be important or not. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [qmailadmin] Stupid C questions
Yesterday I worked on template.c removing unused tags and moving large
blocks of code to separate functions, some to different files. There
are now 26 options with the form:
case '?' :
single line of code;
break;
4 like this, which I don't see any reason to mess with:
case '?' :
if(MaxSomething -1) {
printf( number / number );
} else {
printf( number / unlimited );
}
break;
and 9 others that are still farily long chunks of code that are very
likely to become functions today. I really like the way it looks with
all the single line actions in the switch.
I ran into some TmpBuf* variables which were declared in qmailadmin.c
and qmailadminx.h then used locally all over the program. I was worried
about interaction, so I went through each function in which they
appeared, and if they were initialized within the function I renamed
them from TmpBuf* to Buffer*, and declared them locally. It turns out
there were no interactions, now there is no question - they aren't
shared globals any more.
Tom Collins wrote:
On Jan 8, 2004, at 6:56 PM, Rick Widmer wrote:
1. Does switch/case work with strings?
No. Only with byte/int/long/word datatypes.
If we want to move from
/cgi-bin/qmailadmin/com/commandname?...
to
/qmailadmin/program.cgi?command=commandname
why not just go with single character commands that we can switch() on?
/qmailadmin/program.cgi?command=c
However, if I was doing this with PHP, a URL might look like:
http://server.x.com/qmailadmin/maildomain.com/name/edit.php
qmailadmin is a PHP program without the .php extension. I use the
following settings in httpd.com to make it execute:
Location /qmailadmin
ForceType applocation/x-httpd-php
/Location
/maildomain.com/username/edit.php would be available in PATH_INFO and
used to control operation of the program. This example would be editing
[EMAIL PROTECTED] The .php at the end is just there for show, I
never actually check the 'file extension'.
That works for PHP. It looks like ScriptAlias will allow something
similar for a c program. Are there any objections doing something like
this? Is there anyone who would have a hard time controlling the Apache
configuration on the mail server? Some web sites can not use the
ForceType trick because they can't change their Apache configuration,
but I'd be suprised if that was a problem on mail servers. Now is the
time to find out if this will be a big problem for someone...
Rick
Re: [qmailadmin] Stupid C questions
On Jan 9, 2004, at 4:33 PM, Rick Widmer wrote: Yesterday I worked on template.c removing unused tags and moving large blocks of code to separate functions, some to different files. There are now 26 options with the form: case '?' : single line of code; break; Note, that you could even do this: case '?': some_function_here(); break; You might want to put the break on a separate line, so you can be sure to see it. Missing breaks cause big problems. I ran into some TmpBuf* variables which were declared in qmailadmin.c and qmailadminx.h then used locally all over the program. I was worried about interaction, so I went through each function in which they appeared, and if they were initialized within the function I renamed them from TmpBuf* to Buffer*, and declared them locally. It turns out there were no interactions, now there is no question - they aren't shared globals any more. That's a good idea. Both qmailadmin and vpopmail use shared globals and it's just not a good idea. Upgrading some of the functions to pass values instead of relying on the global variables (like NewU) would be a good idea. If we want to move from /cgi-bin/qmailadmin/com/commandname?... to /qmailadmin/program.cgi?command=commandname why not just go with single character commands that we can switch() on? /qmailadmin/program.cgi?command=c I'd prefer to stick with cmd=commandname for readability. However, if I was doing this with PHP, a URL might look like: http://server.x.com/qmailadmin/maildomain.com/name/edit.php qmailadmin is a PHP program without the .php extension. I use the following settings in httpd.com to make it execute: Location /qmailadmin ForceType applocation/x-httpd-php /Location Not everyone uses Apache -- QmailAdmin works with other web servers. Keeping all parameters as values in the URL means that you can also move them to hidden fields in a POST. There's flexibility in being able to pass values in the URL (GET style) and/or form data (POST style). You could even store some values in a cookie (like the username and domain name) to make the URLs smaller. If the user isn't accepting cookies, just include them in the URL (from template.c). -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [qmailadmin] unicode domain names in vpopmail and qmailadmin
Tom Collins wrote: On Jan 7, 2004, at 4:33 PM, Philipp Wagner wrote: [questions if idn-domains are supported] It's obvious that this is going to be a significant issue for vpopmail and qmailadmin. On the backend, we'll be storing everything in 7-bit ASCII (xn--schlerzeitung-yob.net in the example given above), but allow for users to enter unicode names into the command-line programs for vpopmail, and display the properly formatted name in qmailadmin. [some interesting information and questions skipped :-)] The system is quite simple to understand. All conversion of IDN-Domainnames are done by the client. That means, that the internal used domainnames are still 7-bit ASCII, only they are displayed as UTF-8. That means further, that all on the Userinterface displayed domainnames have to be decoded from Punycode to UTF-8 (which also means, that we have to get UTF-8 as standard encoding for all pages), and all domainnames in the input-fields converted from UTF-8 to punycode-strings. That is done the easiest way by using the libidn-library, that is found under http://www.gnu.org/software/libidn/. It provides encoding and decoding of punycode strings and has an easy to use API. There are no mayor changes in the code, only a changes at the output- and input functions. I'm not a c-programmer and can't do the changes, but I'll help you as good as I can with information on this topic. All relevant RFCs (3490, 3491, 3492) are linked on the libidn-page. greetings, Philipp
