Re: [vchkpw] Re: chkuser parameters via tcp.smtp environment variables
Eric Shubert ha scritto: Tonix (Antonio Nati) wrote: Eric Shubert ha scritto: Tonino, I've wondered for a while about this but haven't had a chance to test it, so I'm going to ask the expert. ;) If /* #define CHKUSER_ALLOW_SENDER_CHAR_3 '' */ is commented out of the build, can it be added as an environment variable such as CHKUSER_ALLOW_SENDER_CHAR_3='/' (from the tcp.smtp file)? If #define CHKUSER_ALLOW_SENDER_CHAR_3 '?' is defined in the build, can its value be changed by an environment variable such as CHKUSER_ALLOW_SENDER_CHAR_3='/' (from the tcp.smtp file)? If CHKUSER_SENDER_FORMAT is left commented (the default) in the build, can it be activated by setting the environment variable CHKUSER_SENDER_FORMAT=1? Thanks for your great work on chkuser, and your superb support. Hello Eric, actually they cannot be defined as environment variable, but must be set in compiled executable. I'm wondering if these controls are still actual, as usage of email has extented a lot, and it is more easy to find strange addresses. I'm also starting to think to further chkuser improvements... but my biggest thought is towards qmail improvements... Anything to suggest? Tonino Hey Tonino, Thanks for your prompt reply, and your interest in improvements. As you probably know, I'm pretty active with the qmail-toaster community, and we've been using chkuser since before I came aboard in '06. We certainly appreciate your work with chkuser. Jake's the project owner presently and he's calling the shots regarding configuration, so I've cc'd him on this discussion. The 'stock' (std) QMT configuration includes a patch file for chkuser that includes the following non-default values in chkuser_settings.h: #define CHKUSER_ALLOW_SENDER_SRS #define CHKUSER_ALLOW_RCPT_SRS #define CHKUSER_SENDER_NOCHECK_VARIABLE SENDER_NOCHECK #define CHKUSER_ALLOW_SENDER_CHAR_1 '$' #define CHKUSER_ALLOW_SENDER_CHAR_2 '%' #define CHKUSER_ALLOW_SENDER_CHAR_4 '?' #define CHKUSER_ALLOW_SENDER_CHAR_5 '*' #define CHKUSER_ALLOW_RCPT_CHAR_1 '$' #define CHKUSER_ALLOW_RCPT_CHAR_2 '%' #define CHKUSER_ALLOW_RCPT_CHAR_4 '?' #define CHKUSER_ALLOW_RCPT_CHAR_5 '*' In addition, it appears that Jake has made the following changes manually (since v2.0.8): #define CHKUSER_RCPT_FORMAT #define CHKUSER_RCPT_MX #define CHKUSER_SENDER_FORMAT #define CHKUSER_SENDER_MX There is primarily one situation that comes to mind where users have been required to customize the stock chkuser settings. This is due to users with blackberry devices, which has recently become more frequent. The sender address with blackberrys sometimes contains the '/' character, so to circumvent the problem, we have added the following customization: #define CHKUSER_ALLOW_SENDER_CHAR_3 '/' #define CHKUSER_ALLOW_RCPT_CHAR_3 '/' This works well, with no ill effects noticed to date. This brings into question the purpose of these checks in chkuser. My understanding is that these special characters used to be thought of as a security risk, but I believe that rationale has become outdated. IMO, the best practice for chkuser would be to allow whatever digits are defined in the standard for email. See http://en.wikipedia.org/wiki/E-mail_address#RFC_specification for details. If there needs to be any customization of the allowed characters, it would be best to have CHKUSER_DISALLOW_RCPT_CHAR_1...n values that DISallow certain digits. I can't think of a good reason for these though, especially since the recipient address is verified with vpopmail. I can see no purpose at all in restricting sender address digits beyond what's allowed in the spec. Bottom line is that I would simply like chkuser to check for the digits as specified in the RFC, and leave it at that. I'm wondering, what is the reasoning behind changing the default to turn off the _FORMAT and _MX settings in v2.0.8? I'm thinking that this was a good choice, and that perhaps the stock QMT should follow suit making it the default. Doing so would eliminate this blackberry problem entirely (and permanently), as well as solving another less common problem regarding the SENDER_MX not found error. If Jake concurs, then the only settings different between the stock QMT and the default chkuser would be: #define CHKUSER_ALLOW_SENDER_SRS #define CHKUSER_ALLOW_RCPT_SRS #define CHKUSER_SENDER_NOCHECK_VARIABLE SENDER_NOCHECK Would it cause a problem to make these the default settings in chkuser? If not, could you make these the defaults in the next chkuser release? That would simplify things for Jake, as we would use the default chkuser settings across the board in the stock QMT. Bottom line to me is that I'd like to see the stock QMT include the default chkuser configuration. I think that would be a good thing for everyone involved, as there would be no 'exceptions' to document or worry about, no patch file, etc. Thanks for your time, effort, and attention to this. It's really a pretty
[vchkpw] Re: chkuser parameters via tcp.smtp environment variables
Tonix (Antonio Nati) wrote: Eric Shubert ha scritto: Tonix (Antonio Nati) wrote: Eric Shubert ha scritto: Tonino, I've wondered for a while about this but haven't had a chance to test it, so I'm going to ask the expert. ;) If /* #define CHKUSER_ALLOW_SENDER_CHAR_3 '' */ is commented out of the build, can it be added as an environment variable such as CHKUSER_ALLOW_SENDER_CHAR_3='/' (from the tcp.smtp file)? If #define CHKUSER_ALLOW_SENDER_CHAR_3 '?' is defined in the build, can its value be changed by an environment variable such as CHKUSER_ALLOW_SENDER_CHAR_3='/' (from the tcp.smtp file)? If CHKUSER_SENDER_FORMAT is left commented (the default) in the build, can it be activated by setting the environment variable CHKUSER_SENDER_FORMAT=1? Thanks for your great work on chkuser, and your superb support. Hello Eric, actually they cannot be defined as environment variable, but must be set in compiled executable. I'm wondering if these controls are still actual, as usage of email has extented a lot, and it is more easy to find strange addresses. I'm also starting to think to further chkuser improvements... but my biggest thought is towards qmail improvements... Anything to suggest? Tonino Hey Tonino, Thanks for your prompt reply, and your interest in improvements. As you probably know, I'm pretty active with the qmail-toaster community, and we've been using chkuser since before I came aboard in '06. We certainly appreciate your work with chkuser. Jake's the project owner presently and he's calling the shots regarding configuration, so I've cc'd him on this discussion. The 'stock' (std) QMT configuration includes a patch file for chkuser that includes the following non-default values in chkuser_settings.h: #define CHKUSER_ALLOW_SENDER_SRS #define CHKUSER_ALLOW_RCPT_SRS #define CHKUSER_SENDER_NOCHECK_VARIABLE SENDER_NOCHECK #define CHKUSER_ALLOW_SENDER_CHAR_1 '$' #define CHKUSER_ALLOW_SENDER_CHAR_2 '%' #define CHKUSER_ALLOW_SENDER_CHAR_4 '?' #define CHKUSER_ALLOW_SENDER_CHAR_5 '*' #define CHKUSER_ALLOW_RCPT_CHAR_1 '$' #define CHKUSER_ALLOW_RCPT_CHAR_2 '%' #define CHKUSER_ALLOW_RCPT_CHAR_4 '?' #define CHKUSER_ALLOW_RCPT_CHAR_5 '*' In addition, it appears that Jake has made the following changes manually (since v2.0.8): #define CHKUSER_RCPT_FORMAT #define CHKUSER_RCPT_MX #define CHKUSER_SENDER_FORMAT #define CHKUSER_SENDER_MX There is primarily one situation that comes to mind where users have been required to customize the stock chkuser settings. This is due to users with blackberry devices, which has recently become more frequent. The sender address with blackberrys sometimes contains the '/' character, so to circumvent the problem, we have added the following customization: #define CHKUSER_ALLOW_SENDER_CHAR_3 '/' #define CHKUSER_ALLOW_RCPT_CHAR_3 '/' This works well, with no ill effects noticed to date. This brings into question the purpose of these checks in chkuser. My understanding is that these special characters used to be thought of as a security risk, but I believe that rationale has become outdated. IMO, the best practice for chkuser would be to allow whatever digits are defined in the standard for email. See http://en.wikipedia.org/wiki/E-mail_address#RFC_specification for details. If there needs to be any customization of the allowed characters, it would be best to have CHKUSER_DISALLOW_RCPT_CHAR_1...n values that DISallow certain digits. I can't think of a good reason for these though, especially since the recipient address is verified with vpopmail. I can see no purpose at all in restricting sender address digits beyond what's allowed in the spec. Bottom line is that I would simply like chkuser to check for the digits as specified in the RFC, and leave it at that. I'm wondering, what is the reasoning behind changing the default to turn off the _FORMAT and _MX settings in v2.0.8? I'm thinking that this was a good choice, and that perhaps the stock QMT should follow suit making it the default. Doing so would eliminate this blackberry problem entirely (and permanently), as well as solving another less common problem regarding the SENDER_MX not found error. If Jake concurs, then the only settings different between the stock QMT and the default chkuser would be: #define CHKUSER_ALLOW_SENDER_SRS #define CHKUSER_ALLOW_RCPT_SRS #define CHKUSER_SENDER_NOCHECK_VARIABLE SENDER_NOCHECK Would it cause a problem to make these the default settings in chkuser? If not, could you make these the defaults in the next chkuser release? That would simplify things for Jake, as we would use the default chkuser settings across the board in the stock QMT. Bottom line to me is that I'd like to see the stock QMT include the default chkuser configuration. I think that would be a good thing for everyone involved, as there would be no 'exceptions' to document or worry about, no patch file, etc. Thanks for your time, effort, and attention
Re: [vchkpw] Re: chkuser parameters via tcp.smtp environment variables
Eric Shubert ha scritto: I agree with this as well, for the most part. This is why I think that the option(s) would be better suited as CHKUSER_DISALLOW. IOW, start with things wide open, and let admins specify which characters they choose not to allow. I did not consider it this way. It is reasonable. The problem I see with the present implementation is that there is nothing (optional or otherwise) which checks for RFC compliance. There does need to be some sort of sanity check. In situations where the system is configured with a catchall account, there would be no other mechanism for ensuring that the recipient address contained only RFC-compliant characters. There should also be a check on the sender address, as it's easily modified by end users. I would like to see chkuser check for RFC compliance of both sender and recipient addresses. I can see no reason why anyone would not want this feature enabled. If it is optional, I think the default should be enabled, as it's consistent with RFC rules. Is there a list of defined RFC permitted chars? In the past I looked for simple RFC rules to check, but probably i did not check very deeply. I remember all characters were permitted. So to sum this up, I'd like to see chkuser enforce RFC rules by default. Optional parameters would be to loosen things with CHKUSER_ALLOW characters, and to tighten things up with CHKUSER_DISALLOW characters. The default behavior would be strict RFC compliance (the starting point). I believe this would give the best flexibility, along with configuration simplicity. But, as said before, it is not easy to chose the right settings, so I'm open to discuss. I hear you on that. It takes discussion to arrive at the best solution. While one size won't fit all, I think we can come up a reasonable default which allows for easy tailoring for the exceptions. OK. Let me think on all again. What you say is a good starting point. Anyway, speaking in a wider way, I'm going to plan new changes on chkuser, but I'm having the impression qmail limits now are limiting me more than chkuser limits, so I'm thinking if it would be the case to start a wider project, integrating and extending qmail. I've registered openqmail.org, and thinking to what can be done in order to extend qmail in a simpler way. I've done small changes to qmail, besides chkuser,and I'm willing to make more changes, and I feel what I need (I'm an ISP) probably is what others need, and viceversa. What do you think? I'm happy to hear this. Rather than starting something on your own though, I'd really like to see you join with us on the qmail-toaster project. I believe that QMT has a promising future for qmail. There is a large (estimated 12k+ hosts) user base, many of which are ISPs. We have lists for users and development, both of which are fairly active and responsive. We can certainly use your expertise and abilities, and I'm sure your participation will be well received. See http://wiki.qmailtoaster.com/index.php/Main_Page for info about QMT. This is a good point for starting another thread... I like the idea, but I'd love to stop with patching. Now qmail is in public domain, so I don't see reasons why we should not have a decent Makefile, a complete source distribution, decent common libraries, mysql integration, and a rewrite/improvement of some (a lot) parts of code. A lot could be improved, but the horrible DJB coding makes it hard. Just for example: actually, you don't have a way to associate together all logs for a single message. So, I've changed a lot of coding for adding message and delivery numbers to logs, but internal qmail behaviour make it impossible to have it working as it should. Numbers associated to emails and deliveries are the i-node numbers of messages, so when you use again a file i-node just released, you use the same message and delivery numbers of previous messages! I'm going to improve and change internal logic for message and delivery numbers, but no more patches! :-) Ciao! Tonino /P.S. I have a dream / /./configure --enable-vpopmail --enable-chkuser --enable-mysql --enable-auth ... make make install/ -- in...@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it !DSPAM:4be3133d32711470415542!
[vchkpw] Re: chkuser parameters via tcp.smtp environment variables
Tonix (Antonio Nati) wrote: Eric Shubert ha scritto: I agree with this as well, for the most part. This is why I think that the option(s) would be better suited as CHKUSER_DISALLOW. IOW, start with things wide open, and let admins specify which characters they choose not to allow. I did not consider it this way. It is reasonable. The problem I see with the present implementation is that there is nothing (optional or otherwise) which checks for RFC compliance. There does need to be some sort of sanity check. In situations where the system is configured with a catchall account, there would be no other mechanism for ensuring that the recipient address contained only RFC-compliant characters. There should also be a check on the sender address, as it's easily modified by end users. I would like to see chkuser check for RFC compliance of both sender and recipient addresses. I can see no reason why anyone would not want this feature enabled. If it is optional, I think the default should be enabled, as it's consistent with RFC rules. Is there a list of defined RFC permitted chars? In the past I looked for simple RFC rules to check, but probably i did not check very deeply. I remember all characters were permitted. Yes, there is. A simple definition is at http://en.wikipedia.org/wiki/E-mail_address#RFC_specification I expect that this is correct, but would verify the values in RFC 5321 and RFC 5322, linked to at that page. So to sum this up, I'd like to see chkuser enforce RFC rules by default. Optional parameters would be to loosen things with CHKUSER_ALLOW characters, and to tighten things up with CHKUSER_DISALLOW characters. The default behavior would be strict RFC compliance (the starting point). I believe this would give the best flexibility, along with configuration simplicity. But, as said before, it is not easy to chose the right settings, so I'm open to discuss. I hear you on that. It takes discussion to arrive at the best solution. While one size won't fit all, I think we can come up a reasonable default which allows for easy tailoring for the exceptions. OK. Let me think on all again. What you say is a good starting point. Great. I'm happy to bounce ideas back and forth. Anyway, speaking in a wider way, I'm going to plan new changes on chkuser, but I'm having the impression qmail limits now are limiting me more than chkuser limits, so I'm thinking if it would be the case to start a wider project, integrating and extending qmail. I've registered openqmail.org, and thinking to what can be done in order to extend qmail in a simpler way. I've done small changes to qmail, besides chkuser,and I'm willing to make more changes, and I feel what I need (I'm an ISP) probably is what others need, and viceversa. What do you think? I'm happy to hear this. Rather than starting something on your own though, I'd really like to see you join with us on the qmail-toaster project. I believe that QMT has a promising future for qmail. There is a large (estimated 12k+ hosts) user base, many of which are ISPs. We have lists for users and development, both of which are fairly active and responsive. We can certainly use your expertise and abilities, and I'm sure your participation will be well received. See http://wiki.qmailtoaster.com/index.php/Main_Page for info about QMT. This is a good point for starting another thread... I agree. Can we take the discussion to the qmailtoaster-devel list? I'm there already, as are others interested in QMT development. I use gmane.org for list access - it's much simpler for subscribing, and there's no filtering required. The list names for QMT on gmane.org are gmane.mail.qmail.toaster.devel and gmane.mail.qmail.toaster (users list). If you'd rather do it the old fashioned way, see the list addresses are qmailtoaster-devel-subscr...@qmailtoaster.com and qmailtoaster-list-subscr...@qmailtoaster.com I like the idea, but I'd love to stop with patching. Now qmail is in public domain, so I don't see reasons why we should not have a decent Makefile, a complete source distribution, decent common libraries, mysql integration, and a rewrite/improvement of some (a lot) parts of code. A lot could be improved, but the horrible DJB coding makes it hard. Just for example: actually, you don't have a way to associate together all logs for a single message. So, I've changed a lot of coding for adding message and delivery numbers to logs, but internal qmail behaviour make it impossible to have it working as it should. Numbers associated to emails and deliveries are the i-node numbers of messages, so when you use again a file i-node just released, you use the same message and delivery numbers of previous messages! I'm going to improve and change internal logic for message and delivery numbers, but no more patches! :-) I agree whole heartedly on all counts. Can we pick up this discussion on the qmailtoaster-devel
[vchkpw] Re: chkuser parameters via tcp.smtp environment variables
Tonix (Antonio Nati) wrote: Eric Shubert ha scritto: Tonino, I've wondered for a while about this but haven't had a chance to test it, so I'm going to ask the expert. ;) If /* #define CHKUSER_ALLOW_SENDER_CHAR_3 '' */ is commented out of the build, can it be added as an environment variable such as CHKUSER_ALLOW_SENDER_CHAR_3='/' (from the tcp.smtp file)? If #define CHKUSER_ALLOW_SENDER_CHAR_3 '?' is defined in the build, can its value be changed by an environment variable such as CHKUSER_ALLOW_SENDER_CHAR_3='/' (from the tcp.smtp file)? If CHKUSER_SENDER_FORMAT is left commented (the default) in the build, can it be activated by setting the environment variable CHKUSER_SENDER_FORMAT=1? Thanks for your great work on chkuser, and your superb support. Hello Eric, actually they cannot be defined as environment variable, but must be set in compiled executable. I'm wondering if these controls are still actual, as usage of email has extented a lot, and it is more easy to find strange addresses. I'm also starting to think to further chkuser improvements... but my biggest thought is towards qmail improvements... Anything to suggest? Tonino Hey Tonino, Thanks for your prompt reply, and your interest in improvements. As you probably know, I'm pretty active with the qmail-toaster community, and we've been using chkuser since before I came aboard in '06. We certainly appreciate your work with chkuser. Jake's the project owner presently and he's calling the shots regarding configuration, so I've cc'd him on this discussion. The 'stock' (std) QMT configuration includes a patch file for chkuser that includes the following non-default values in chkuser_settings.h: #define CHKUSER_ALLOW_SENDER_SRS #define CHKUSER_ALLOW_RCPT_SRS #define CHKUSER_SENDER_NOCHECK_VARIABLE SENDER_NOCHECK #define CHKUSER_ALLOW_SENDER_CHAR_1 '$' #define CHKUSER_ALLOW_SENDER_CHAR_2 '%' #define CHKUSER_ALLOW_SENDER_CHAR_4 '?' #define CHKUSER_ALLOW_SENDER_CHAR_5 '*' #define CHKUSER_ALLOW_RCPT_CHAR_1 '$' #define CHKUSER_ALLOW_RCPT_CHAR_2 '%' #define CHKUSER_ALLOW_RCPT_CHAR_4 '?' #define CHKUSER_ALLOW_RCPT_CHAR_5 '*' In addition, it appears that Jake has made the following changes manually (since v2.0.8): #define CHKUSER_RCPT_FORMAT #define CHKUSER_RCPT_MX #define CHKUSER_SENDER_FORMAT #define CHKUSER_SENDER_MX There is primarily one situation that comes to mind where users have been required to customize the stock chkuser settings. This is due to users with blackberry devices, which has recently become more frequent. The sender address with blackberrys sometimes contains the '/' character, so to circumvent the problem, we have added the following customization: #define CHKUSER_ALLOW_SENDER_CHAR_3 '/' #define CHKUSER_ALLOW_RCPT_CHAR_3 '/' This works well, with no ill effects noticed to date. This brings into question the purpose of these checks in chkuser. My understanding is that these special characters used to be thought of as a security risk, but I believe that rationale has become outdated. IMO, the best practice for chkuser would be to allow whatever digits are defined in the standard for email. See http://en.wikipedia.org/wiki/E-mail_address#RFC_specification for details. If there needs to be any customization of the allowed characters, it would be best to have CHKUSER_DISALLOW_RCPT_CHAR_1...n values that DISallow certain digits. I can't think of a good reason for these though, especially since the recipient address is verified with vpopmail. I can see no purpose at all in restricting sender address digits beyond what's allowed in the spec. Bottom line is that I would simply like chkuser to check for the digits as specified in the RFC, and leave it at that. I'm wondering, what is the reasoning behind changing the default to turn off the _FORMAT and _MX settings in v2.0.8? I'm thinking that this was a good choice, and that perhaps the stock QMT should follow suit making it the default. Doing so would eliminate this blackberry problem entirely (and permanently), as well as solving another less common problem regarding the SENDER_MX not found error. If Jake concurs, then the only settings different between the stock QMT and the default chkuser would be: #define CHKUSER_ALLOW_SENDER_SRS #define CHKUSER_ALLOW_RCPT_SRS #define CHKUSER_SENDER_NOCHECK_VARIABLE SENDER_NOCHECK Would it cause a problem to make these the default settings in chkuser? If not, could you make these the defaults in the next chkuser release? That would simplify things for Jake, as we would use the default chkuser settings across the board in the stock QMT. Bottom line to me is that I'd like to see the stock QMT include the default chkuser configuration. I think that would be a good thing for everyone involved, as there would be no 'exceptions' to document or worry about, no patch file, etc. Thanks for your time, effort, and attention to this. It's really a pretty small item, but when we
