> > 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.
>
> It's your service, you define it. For some, 1000 is fine, for others 10
> may be unacceptable.
I agree.
> > 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.
>
> And what hardware/software do you propose to use to back up the
> policy that says he can't make multiple submissions?
That is what I'm looking for now. In this case software limitations is the
solution. The tarpitting idea from Chris Johnson on www.qmail.org is so far
the best choice, it seems.
> One solution that generally covers it is to charge them for the
> number of recipients or the total bytes sent or whatever. Naturally
> self regulating then. You can generate billing information for the
> mail logs.
Not a solution for us. We have other mailservers handling large (1000+ rcpt)
distribution of mail, both with ezmlm and majordomo. The bandwith is not the
issue here, but the mailserver is. No doubt that this mailserver can handle
his and others 1000+ rcpt, but my personal opinion is that this belongs on a
mailing list. The recipients is customers of him/his company. It's the same
recipients every week. Those two sentence together gives me: mailing list
service.
regards
--
--------------------------------------------
IDG New Media Einar Bordewich
Technical Manager Phone: +47 2336 1420
E-Mail: [EMAIL PROTECTED]
--------------------------------------------