[vchkpw] Help with my Chkuser Installation Guide
Hi guys, I'm editing my Simscan + ClamAV + Chkuser installation guide at: http://www.qmailwiki.org/Simscan/Related_Docs/Simscan_ClamAV_Chkuser_Installation_Guide And I added a new part where I persuade the reader to enable some of chkuser's features that came disabled by default. To persuade the reader, I make some comments of the usefulness of each feature. I'd like you to read and criticize my comments to prevent me teaching bullshit to the others. The text is this bellow: --- Enable some nice Chkuser features [OPTIONAL] Chkuser has disabled by default some of it's nice features: a.. CHKUSER_SENDER_FORMAT: checks if the SENDER of each message has the username part matching [a-z0-9_-], and the domain part matching [a-z0-9-.] with not consecutive -., not leading or ending -. == Great for identifying spam. a.. CHKUSER_RCPT_FORMAT: Equals to the above checking, but for the RCPT of each message. Good to prevent your users to send crap to the net. a.. CHKUSER_SENDER_MX: Checks if the SENDER domain has a valid MX configured for it, thus, discovering fake domain names. Great for identifying spam. a.. CHKUSER_RCPT_MX: Checks if the RCPT domain has a valid MX configured for it. Good to discover typos your users do when sending e-mails. To enable these features, we have to edit the chkuser_setting.h file and uncomment them. vi chkuser_settings.h Search and uncomment the line for each feature: /* #define CHKUSER_RCPT_FORMAT */ #define CHKUSER_RCPT_FORMAT /* #define CHKUSER_RCPT_MX */ #define CHKUSER_RCPT_MX /* #define CHKUSER_SENDER_FORMAT */ #define CHKUSER_SENDER_FORMAT /* #define CHKUSER_SENDER_MX */ #define CHKUSER_SENDER_MX Save the chkuser_settings.h file with the above modifications. --- Regards, Bruno Negrao - Network Manager Engepel Teleinformtica. 55-31-34812311 Belo Horizonte, MG, Brazil
Re: [vchkpw] Help with my Chkuser Installation Guide
Hi Matt, thanks for answering. | a.. CHKUSER_SENDER_FORMAT: checks if the SENDER of each message has the | username part matching [a-z0-9_-], and the domain part matching | [a-z0-9-.] with not consecutive -., not leading or ending -. == | Great for identifying spam. This really doesn't do much to identify spam. In fact, the only purpose it would tend to serve, is to limit the users on your system to traditional email addresses, which could, ironically, make your system more easily spammed. When the SENDER is a local user, I have to agree with what you say. But when the SENDER is a remote user, specially a spammer, this check will block all those weird fake addresses the spammers like to use, that's why I told this feature was good to block spam. Can you comment on this? Would this case worth to enable this feature? But now I looking closely to this check I'm recalling some of my customers like to have e-mails of the format: [EMAIL PROTECTED] I't seems that this check would block my usernames with the 'user.lastname' syntax, since it doesn't accept a '.' character in the USER part. Is this customizable? If it's not, this feature does not work even for me!! | a.. CHKUSER_RCPT_FORMAT: Equals to the above checking, but for the RCPT | of each message. Good to prevent your users to send crap to the net. Same as CHKUSER_SENDER_FORMAT except here, if your users try to relay mail to a non-traditional email address, you will find yourself with a phone call from a curious customer :) Hmmm, oh no!! :-) So I see no utility at all to this feature. | a.. CHKUSER_SENDER_MX: Checks if the SENDER domain has a valid MX | configured for it, thus, discovering fake domain names. Great for | identifying spam. Unfortunately, while we'd all love to force everyone to have an MX record, the fact remains that some hosts just dont have them. Connecting directly to the host named should be left available, for now. I didn't understand what you said in Connecting directly to the host named should be left available, for now. Can you explain it better? Also, being dictionary attacked could leave you making a good deal of DNS lookups, which can sometimes be slow. Yes... I'm seeing there are some good reasons for these features being commented out... Regards, bnegrao
[vchkpw] REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Hi guys, As managers and directors of the companies are getting more acquainted about the Internet use (and abuse) inside their companies, they want to have more and more control over what employees can and cannot do on the Internet. Now, the director of one of the companies I give support asked me to set a bunch of e-mail accounts as internal-only, i.e., they can send e-mail internally but cannot send or receive external e-mails. As I reconized that his need probably will also be desired for a lot of other companies, I think it's worth to discuss here which would be the most appropriate manner to achieve this feature with Qmail and Vpopmail. THE IDEAL SCENE: The ideal scene for me would be if vpopmail could provide a means for doing this. To set the internal-only account I'd like to end up going to Qmailadmin, editing the properties of some user account, and just checking the new check-box: ( ) Internal-only account; I have no idea of how this could be implemented by vpopmail. Can someone out there imagine something? IDEAS: Until now, the only thing that occurs to me in order to accomplish this, is to edit (manually) the famous /var/vpopmail/tcp.smtp file and laboriously add a bunch of IP addresses, of each internal-only user, unsetting the RELAYCLIENT variable for each one of them. This would prevent the users from sending e-mails to external domains. But they could receive external e-mails (althouth they would not be able answer the e-mails). Or, suddenly, I could set the IPs of all internal-only user's machines inside a specified IP range, and I would disable RELAYCLIENT just for this range. I should explain this change to my customer, and they should follow the IP range specification. Still, I would be relying on tcp.smtp file to accomplish this. Further ideas? Regards, - Bruno Negrao - Support Analyst Engepel Teleinformática. 55-31-34812311 Belo Horizonte, MG, Brazil
