Another idea!
Set up another interface on the box specifically for that customer and
create a separate qmail installation for him there for different queue and
different services for him and the other customers that you are worried
about slowing down!
Slider
> 1) Is the user a)dialling up and gets a ramdom ip address or b)are you
> hosting him and has a constant ip address?
He's one of our dialup customers (random ip)
> 2) If (a) then get his Caller ID and ban him from dial up or filter his
> connection to a slower mail service!
> 3) If (b) ban his IP from smtp connections to your mail servers... for
> investigation in iether situation!
I don't want to scare the customer away, but I want him over on our mailing
list service. The customer is a company, and our relationship to this
customer is very good except for the huge mailing from them once a week and
sometimes more.
There is no performance problems on this server, but I just like a clean
mail queue. With huge recipients from a clients addressbook, there is always
some bounce candidates keeping the whole recipientslist in the queue. The
mails going out is product information/advertising to their
customers/contacts. In other words low priority mails that can use the time
it takes on a mailing list server to process.
Our international bandwith is a E3 line and domestic it's 100mbps, and the
mails is mainly domestic. I'm just tired of having this huge list of
recipients hanging in the queue until all mails are delivered or bounced.
This server is our main mailhub, and I think of our other customers when I
want to move obvious hunks of mail to where they belong. It takes time to
deliver mails to 1000+, making the other users mail wait on their turn. Just
don't see the point to let this customer use the main mail hub, when we have
dedicated servers for this. My customers are spoilt with instant delivery of
their 1/2/3/4 mails, and I intend to keep it this way :-)
> 4) Another suggestion editing the /etc/tcp.smtp file with
>
>
"ipaddressofconnection".:allow,RELAYCLIENT="",DATABYTES="sizeyouarewillingto
> send",TARPITCOUNT="100",TARPITDELAY="5"
> (of course you have to recreate the tcp.smtp.cdb)
And of course patch qmail-smtpd.c with the tarpit-path ;-)
> 4 cont) this will allow first "100" e-mails past from the ip range
selected
> at the size selected and there after will wait "5" seconds before
delivering
> the remaining (above 100) emails, this will seriously hang the users
client
> and probably will not be too interested in doing it again!
>
> Anyone have ideas or scripts as to getting notification when the
TARPITDELAY
> starts to count, or when the TARPITCOUNT has been reached? Advantage being
> that the administrator can catch red handed the user and make a decision
as
> to the best course of action...
Have patched my home mailserver with this patch, and will try it out here
first. Have'nt got any feedback on my question about experience with this
patch installed. Looks good so far.
--
--------------------------------------------
IDG New Media Einar Bordewich
Technical Manager Phone: +47 2336 1420
E-Mail: [EMAIL PROTECTED]
--------------------------------------------
----- Original Message -----
From: "Slider" <[EMAIL PROTECTED]>
To: "David Dyer-Bennet" <[EMAIL PROTECTED]>; "Qmail-mailing list"
<[EMAIL PROTECTED]>
Sent: Thursday, August 10, 2000 10:57 AM
Subject: RE: rcpt to|cc|bcc and To:|Cc:|Bcc: limitations
>
> Another couple of ideas;
>
> 1) Is the user a)dialling up and gets a ramdom ip address or b)are you
> hosting him and has a constant ip address?
> 2) If (a) then get his Caller ID and ban him from dial up or filter his
> connection to a slower mail service!
> 3) If (b) ban his IP from smtp connections to your mail servers... for
> investigation in iether situation!
> 4) Another suggestion editing the /etc/tcp.smtp file with
>
>
"ipaddressofconnection".:allow,RELAYCLIENT="",DATABYTES="sizeyouarewillingto
> send",TARPITCOUNT="100",TARPITDELAY="5"
> (of course you have to recreate the tcp.smtp.cdb)
>
> 4 cont) this will allow first "100" e-mails past from the ip range
selected
> at the size selected and there after will wait "5" seconds before
delivering
> the remaining (above 100) emails, this will seriously hang the users
client
> and probably will not be too interested in doing it again!
>
> Anyone have ideas or scripts as to getting notification when the
TARPITDELAY
> starts to count, or when the TARPITCOUNT has been reached? Advantage being
> that the administrator can catch red handed the user and make a decision
as
> to the best course of action...
>
> Slider
>
>
>
> Einar Bordewich <[EMAIL PROTECTED]> writes on 10 August 2000 at 00:40:06
> +0200
> > My tormentor is a customer and is allowed to relay through our
> mailserver.
> >
> > The problem is that I want him over on a mailinglist solution. He most
> likly
> > will switch to mailinglist eventually, but I think it's a little bit
> drastic
> > to block him out just to speed up the action ;-) I feel it would be
more
> > correct to implement some limitations on the mail server, affecting all
> the
> > users.
> >
> > This because we from time to time have users/customers that pops off a
> mail
> > with 100+ recipients. In my opinion beneath 100 is acceptable, over
this
> > number it's improper use. I might be out on a limb here, so please
> correct
> > if I'm wrong.
> >
> > And yes, if he's smart he can abuse the solution, but then again he's
> > deliberately have to do it, breaking our agreement and policy. I don't
> > belive in policy when there is no hardware or software limitations to
> back
> > that up.
>
> If he sets up a mailing list using ezmlm, the obvious thing to use
> with qmail, and sends to a mailing list of 1000 people through that
> setup, you'll get exactly the same thing you have now. If you
> implement a block on the submission, he'll be unable to use (that)
> mailing list. So I think you need to think this through more
> thoroughly.
> --
> Photos: http://dd-b.lighthunters.net/ Minicon:
http://www.mnstf.org/minicon
> Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
> David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
>
>
>
