At 20.31 06/02/2006, you wrote:
Thanks for your answer Tonino, i take that solution in account but i
would prefer another solution if possible, that smtp server is being
already used by lots of clients so running another server for them
would imply that they have to change their mail server (its a little
change, i know, but they are lots and the average user would need
assistance for doing that simple change) so i would try to another
solution first if someone has another idea.. or i get illuminated in
Simplest solution is to put another VARIABLE disabling this check.
Let me see how add something like what you ask.
I'm just wondering if other checks could be excluded for authenticathed users.
Any comment is welcome.
On 2/6/06, tonix (Antonio Nati) <[EMAIL PROTECTED]> wrote:
> At 18.36 06/02/2006, you wrote:
> >Hi, i have a working qmail installation from netqmail and recently
> >included chkuser (very nice!).
> >I want to use the CHKUSER_RCPTLIMIT and CHKUSER_WRONGRCPTLIMIT
> >variables to block spam because they work very nice in my system, but
> >the problem is that i don't want to apply these limits to the
> >authenticated clients, so they can send mail with lot of recipients
> >and even whit wrong recipient so they receive a bounced message. (if
> >they get an error when sending they just think, o! the server is not
> >working, lets call the provider). So, i tried whit #define
> >CHKUSER_SENDER_NOCHECK_VARIABLE "RELAYCLIENT" but it doesn't works. It
> >only disables sender checking or also the limits? how i can disable
> >the limits only for authenticated clients? any idea?
> Actually I'm using a separate qmail-smtpd server for authenticated
> users (i.e. relay.mydomain.com), on a dedicated IP address.
> This solves the most of my problems, as in this way I can make the
> deepest customization I can, and I keep separated normal MX traffic
> and relaying traffic.
> In this dedicated server for authenticated users I think it could be
> even better not to enable CHKUSER, so normal users with Outlook will
> receive normal error messages instead of short SMTP responses.
> >Thanks in advance