Tonix (Antonio Nati) wrote:
Il 01/10/2010 20:32, Eric Shubert ha scritto:
Tonix (Antonio Nati) wrote:
Il 01/10/2010 18:24, Eric Shubert ha scritto:
David wrote:
On 10/01/2010 10:18 AM, Jake Vickers wrote:
On 10/01/2010 10:44 AM, David wrote:
How can a limit be set on a single account or all accounts in a
domain to limit the number of emails that can be sent in certain
time frame?
This may have been covered already but I am behind a little on
this.
--Dave
You can only really limit it on a server level with
concurrencyremote.
What are you trying to accomplish?
This spawned from a another list I was working on talking about
security on large networks.
I did have 2 accounts get compromised for weak passwords. I had
over 50,000 emails go out in 2 days and blacklisting me in few places.
I can usually resolve this quickly but I need a watchdog to either
alter me or limit my server from sending so much mail out at one
time. Which can raise red flags all over the place with RBLs and
other block lists.
--Dave
---------------------------------------------------------------------------------
That's indeed an interesting problem. I really like the way that
gmane.org handles it.
gmane.org handles the list submission side of things (as opposed to
the reading/delivery side) by throttling the frequency of sending,
per user. It will only send out one message per user every 5
minutes. If there are more messages than that, they remain in the
queue. It accomplishes this by processing the send queue every 5
minutes, and processing only one message per sender.
Perhaps qmail-send could (be modified to) do something similar for
remote deliveries (I don't see a point in doing this for messages
going to qmail-local). Any developers out there who would like to
look into this?
This is one feature I planned already to put inside chkuser, limiting
acceptance (for authenticated users) to both a user limit and a
domain limit.
I feel two basic limits should be placed both for domain and single
user: daily threshold and montly threshold. limits like 500 daily and
10000 montly for user are very large for single user and useless for
spammers.
But, honestly, I've no time to implement it in short period.
Regards,
Tonino
While this approach might be an attractive feature for ISPs, I don't
think it's the best solution for the problem of compromised passwords.
Messages should still be allowed to be queued, but there needs to be a
throttle/governor put on the rate at which they're sent/delivered (not
submitted). The limit should be something along the line of one
message every so many seconds, not so many messages per units of time.
There should be user, domain, and host values, in that order of
precedence. The default would be not to throttle, which is the present
behavior. I think this would be ideal.
In order to implement such a feature, the parameters for host, domain,
and users would need to be stored somewhere (MySQL, or filesystem in
the traditional qmail fashion). In addition, there would need to be a
timestamp stored for each account (same storage options). The
qmail-send program would need to access the 3 parameters, and each
account's timestamp of the last message sent. If the alloted time has
not elapsed since the last message was sent from a given account, then
all messages submitted from the same account would be bypassed, and
left in the queue for processing later.
The qmail-send program would need to identify the account name of the
submitter, which appears to be in the first Received header added to
the message (appears as the last Received header in the file). The
user/domain throttle values could only be applied to messages that
were submitted with authentication. The host value would be used for
unauthenticated submissions.
I think this be a worthwhile enhancement to the qmail-send program.
It'd be great if we could find a few folks who would sponsor its
development.
There are too many sides to examine.
I have a pretty clear picture of what I have in mind. Perhaps I haven't
communicated it well, or am not considering something.
Can you expound a bit?
I'd prefer to stop the user is he/she making pop/smtp from too many
different IPs, unless he/she declares to be a roaming user... in this
case, limits to acceptance are enought.
I don't see where that would do anything about compromised passwords.
I also don't see a point in somehow keeping track of roaming users.
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
