Il 01/10/2010 21:04, Eric Shubert ha scritto:
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'm speaking about different business behaviors, for which something
genial for one customer could be a damage for others.
I had customers with stolen password, and my attention was caught by
messages in queue, coming from authenticated relaying, and different IP
used from same sender for those messages.
99% of my customers works from office, so they use a fixed IP, and
sometimes work from home, sometimes they travel. But it is extremely
rare they send e-mail from three different IP in the same day, so it may
worth to "suspend" an account when such condition exists.
At the same time, I feel necessary to put a "filter" at acceptance phase
(like maximum numer of messages/recipinets for day) , because they work
with e-mail, and I cannot consider throttling or delaying their messages
due to huge queues... If I receive a message I must deliver it in the
shortest timeframe, otherwise it is better not to accept it.
I'n mu wishlist about qmail, I'd love to have a multi-queue mechanism,
where one queue would be used for users within thesholds, and another
queue for mailing lists and users outside thesholds. In this way normal
users would be never have penalties, while exceeding users would be
routed to "low priority queue".
But I'd love to extend this to other needs, as well. Stolen passwords
mean unauthorized access to pop and IMAP, so I need a wider approach to
that.
Actually POP do not make any kind of control over abuses,a nd most IMAP
applications do no let to approach it easily (example, for a webmail
using IMAP, IMAP application cannot check the "real" source IP, as it
know only the webmail IP).
Regards,
Tonino
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.
--
------------------------------------------------------------
in...@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
---------------------------------------------------------------------------------
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]
